Мы — долго запрягаем, быстро ездим, и сильно тормозим.

RFC
  RFC1180 (TCP/IP)
  RFC791 (IP)
  RFC792 (ICMP)
  RFC793 (TCP)
  RFC768 (UDP)
  RFC1459 (IRC)
  RFC1521 (MIME)
  RFC1951 (DEFLATE)
  RFC2839 (IKS)
Программирование
FreeBSD
man
EXIM


www.lissyara.su —> документация —> RFC —> RFC791 (IP)

RFC 791 Internet протокол


RFC 791 Internet протокол
Проект Darpa Internet
Спецификация протокола
сентябрь 1981

приготовлено для
Агенства расширенных оборонных исследовательских проектов
Офис технологий обработки информации
1400 Wilson Boulevard
Arlington, Virginia 22209
Институтом Информатики
Университета Южной Каролины
4676 Admiralty Way    
Marina del Rey, California 90291
(перевод Радика Усманова сентябрь 1994)

Содержание
 Предисловие
1. Введение
 1.1 Обоснование
 1.2 Цель
 1.3 Интерфейсы
 1.4 Действие
2. Обзор
 2.1 Связь с другими протоколами
 2.2 Сценарий работы
 2.3 Описание функций
 2.4 Шлюзы
3. Спецификация
 3.1 Формат заголовка Internet
 3.2 Обсуждение
 3.3 Интерфейсы
Приложение А: Примеры и сценарии
Приложение Б: Порядок передачи данных
Толковый словарь
Ссылки

Предисловие
Данный документ устанавливает Internet протокол в стандарте DOD. Он основан на шести предыдущих версиях спецификации протокола ARPA Internet, и из них в значительной степени заимствован его текст. Вместе с тем в эту работу внесены многие изменения, касающиеся как терминологии, так и собственно изложения материала. Это издание освещает адресацию, обработку ошибок, коды опций, а также безапасность, историю и поддержку свойств протокола Internet.
Джон Постел (Jon Postel)
Редактор

Протокол Internet
Программа DARPA Internet
Спецификация протокола


1. Введение
1.1 Обоснование
  Протокол Internet создан для использования в объединенных системах компьютерных коммуникационных сетей с коммутацией пакетов. Такие системы были названы "catenet" [1]. Протокол Internet обеспечивает передачу блоков данных, называемых датаграммами, от отправителя к получателям, где отправители и получатели являются хост-компьютерами, идентифицируемыми адресами фиксированной длины. Протокол Internet обеспечивает при необходимости также фрагментацию и сборку датаграмм для передачи данных через сети с малым размером пакетов.

1.2 Цель
  Протокол Internet специально ограничен задачами обеспечения функций, необходимых для передачи битового пакета (датаграммы Internet) от отправителя к получателю через объединенную систему компьютерных сетей. Нет механизмов для увеличения достоверности конечных данных, управления протоколом, синхронизации или других услуг, обычно приненяемых в протоколах передачи от хоста к хосту. Протокол Ineternet может обобщить услуги поддерживающих его сетей с целью предоставления услуг различных типов и качеств.

1.3 Интерфейсы
  Данный протокол получил название в соответствии с протоколами передачи информации между хост-компьютерами в межсетевой среде. Протокол вызывает в локальной сети протоколы для передачи датаграммы Internet на следующий шлюз или хост-получатель.
  Например, модуль TCP вызывал бы модуль Internet с тем, чтобы получить сегмент TCP (включая заголовок TCP и данные пользователя) как информационную часть Internet пакета. Модуль TCP обеспечил бы адреса и другие параметры в заголовке модуля Internet в качестве параметров рассматриваемого вызова. Модуль Internet в этом случае создал бы датаграмму Internet и прибегнул бы к услугам локальной сети для передачи датаграммы Internet.
  Например, в случае сети ARPANET модуль Ineternet вызывал бы локальный сетевой модуль, который бы добавлял к датаграмме Internet проводник типа 1822 [2], создавая сообщение ARPANET для передачи на IMP. Адрес ARPANET получился бы из адреса Intenet с помощью интерфейса локальной сети и относился бы к некоторому хост-компьютеру в сети ARPANET, который мог бы быть шлюзом в другие сети.

1.4 Действие
  Протокол Internet выполняет две главные функции: адресацию и фрагментацию.
  Модули Internet используют адреса, помещенные в заголовок Internet, для передачи Internet датаграмм их получателям. Выбор пути передачи называется маршрутизацией.
  Модули Internet используют поля в заголовке Internet для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
  Сценарий действия состоит в том, что модуль Internet меняет размер на каждом из хостов, задействованных в internet-коммуникации и на каждом из шлюзов, обеспечивающих взаимодействие между сетями. Эти модули придерживаются общих правил для интерпретации полей адресов, для фрагментации и сборки Internet датаграмм. Кроме этого, данные модули (и особенно шлюзы) имеют процедуры для принятия решений о маршрутизации, а также другие функции.
  Протокол Internet обрабатывает каждую Internet датаграмму как независимую единицу, не имеющую связи ни с какими другими датаграммами Internet. Протокол не имеет дело ни с соединениями, ни с логическими цепочками (виртуальными или какими-либо другими).
  Протокол Internet использует четыре ключевых механизма для формирования своих услуг: задание типа сервиса, времени жизни, опций и контрольной суммы заголовка.
  Тип обслуживания используется для обозначения требуемой услуги. Тип обслуживания - это абстрактный или обобщенный набор параметров, который характеризует набор услуг, предоставляемых сетями, и составляющих собственно протокол Internet. Этот способ обозначения услуг должен использоваться шлюзами для выбора рабочих параметров передачи в конкретной сети, для выбора сети, используемой при следующем переходе датаграммы, для выбора следующего шлюза при маршрутизации сетевой Internet датаграммы.
  Механизм времени жизни служит для указания верхнего предела времени жизни Internet датаграммы. Этот параметр устанавливается отправителем датаграммы и уменьшается в каждой точке на проходимом датаграммой маршруте. Если параметр времени жизни станет нулевым до того, как Internet датаграмма достигнет получателя, эта датаграмма будет уничтожена. Время жизни можно рассматривать как часовой механизм самоуничтожения.
  Механизм опций предоставляет функции управления, которые являются необходимыми или просто полезными при определенных ситуациях, однако он ненужен при обычных комминикациях. Механизм опций предоставляет такие возможности, как временные штампы, безопасность, специальная маршрутизация.
  Контрольная сумма заголовка обеспечивает проверку того, что информация, используемая для обработки датаграмм Internet, передана правильно. Данные могут содержать ошибки. Если контрольная сумма неверна, то Internet датаграмма будет разрушена, как только ошибка будет обнаружена.
  Протокол Internet не обеспечивает надежности коммуникации. Не имеется механизма подтверждений ни между отправителем и получателем, ни между хост-компьютерами. Не имеется контроля ошибок для поля данных, только контрольная сумма для заголовка. Не поддерживается повторная передача, нет управления потоком.
  Обнаруженные ошибки могут быть оглашены посредством протокола ICMP (Internet Control Message Protocol) [3], который поддерживается модулем Internet протокола.


2. Обзор
2.1 Связь с другими протоколами
  Следующая диаграмма иллюстрирует место протокола Internet в иерархии протоколов.
           +------+ +-----+ +------+       +-----+
           |Telnet| | FTP | | TFTP |  ...  | ... |
           +------+ +-----+ +------+       +-----+
                 |   |         |              |
                +-----+     +-----+        +-----+
                | TCP |     | UDP |   ...  | ... |
                +-----+     +-----+        +-----+
                    |          |             |
                   +--------------------------+
                   | Internet Protocol & ICMP |
                   +--------------------------+
                                 |
                    +------------------------+
                    | Local Network Protocol |
                    +------------------------+

Рис. 1 Взаимодействие протоколов
  Протокол Internet взаимодействует с одной стороны с протоколами передачи информации между хост-компьютерами, а с другой - с протоколами локальной компьютерной сети. При этом локальная сеть может являться малой компьютерной сетью, участвующей в создании большой сети, такой как ARPANET.

2.2 Сценарий работы
  Схему действий для передачи датаграммы от одной прикладной программы к другой можно проиллюстрировать следующим образом:
  Предположим, что перенос будет включать прохождение одного промежуточного шлюза. Отправляющая прикладная программа готовит свои данные и вызывает свой локальный Internet модуль для отправки этих данных в качестве датаграммы, а в качестве аргументов этого вызова передает адрес получателя и другие параметры.
  Модуль Internet готовит заголовок датаграммы и стыкует с ним данные. Модуль Internet определяет локальный сетевой адрес, соответствующий данному адресу Internet. В данном случае это адрес шлюза.
  Модуль передает данную датаграмму и адрес в локальной сети в распоряжение интерфейса локальной сети.
  Интерфейс локальной сети создает соответствующий этой сети заголовок и соединяет с ним датаграмму. Затем он передает по локальной сети полученный таким образом результат.
  Датаграмма достигает хост-компьютер, играющий роль шлюза и расположенный в вершине сети. Интерфейс локальной сети отделяет этот заголовок и передает датаграмму на модуль Internet. Модуль Internet определяет из Internet адреса, что датаграмма должна быть направлена на хост-компьютер во второй сети. Модуль Internet определяет адрес хоста-получателя в локальной сети. Он обращается к интерфейсу локальной сети с тем, чтобы она переслала данную датаграмму по назначению.
  Интерфейс создает заголовок локальной сети и соединяет с ним датаграмму, а затем результат на правляет на хост-получатель.
  На хосте-получателе интерфейс локальной сети удалает заголовок локальной сети и передает оставшееся на Internet модуль.
  Модуль Internet определяет, что рассматриваемая выше датаграмма предназначена для прикладной программы на этот хосте. Модуль передает данные прикладной программе в ответ на системный вызов. В качестве результата этого вызова передаются адрес получателя и другие параметры.
прикладная программа                               прикладная программа
           \                                            /
      модуль Internet       модуль Internet      модуль Internet
              \                /        \            /
             LNI-1         LNI-1        LNI-2     LNI2
                 \          /              \      /
                локальная сеть 1        локальная сеть 2

Рис. 2 Путь передачи датаграммы

2.3 Описание функций
  Функция или цель протокола Internet состоит в передаче датаграммы через набор объединенных компьютерных сетей. Это осуществляется посредством передачи датаграмм от одного модуля Internet к другому до тех пор, пока не будет достигнут получатель. Модули Internet находятся на хостах и шлюзах системы Internet. Датаграммы направляются с одного модуля Internet на другой через конкретные компьютерные сети, основанные на интерпретации Internet адресов. Таким образом, одним из важных механизмов протокола Internet является Internet адрес.
  При передаче сообщений с одного Internet модуля на другой датаграммы могут нуждаться в прохождении через сети, для которых максимальный размер пакета меньше, чем размер датаграммы. Чтобы преодолеть эту сложность, в протокол Internet включен механизм фрагментации.
  Адресация. В протоколе сделано разграничение между именами, адресами и маршрутами [4]. Имя показывает искомый нами объект. Адрес показывает его местонахождение. Internet имеет дело с адресами. Перевод имен в адреса является задачей протоколов более высокого уровня (прикладных программ или протоколов передачи синхронизации с хоста на хост). Собственно модуль Internet осуществляет отображение адресов Internet на адреса локальной сети. Создание карты адресов локальной сети для получения маршрутов - задача процедур более низкого уровня (процедур локальной сети или шлюзов).
  Адреса имеют фиксированную длину четыре октета (32 бита). Адрес начинается с сетевого номера, за которым следует локальный адрес (называемый полем остатка "rest"). Существуют три формата или класса адресов Internet. В классе a самый старший бит нулевой. Следующие 7 бит определяют сеть. а последние 24 бита - локальный адрес. В классе b самые старшие два бита равны соответственно 1 и 0, следующие 14 бит определяют сеть, а последние 16 бит - локальный адрес. В классе c три самых старших бита равны соответственно 1,1 и 0, следующие 21 бит определяют сеть, а последние 8 бит - локальный адрес.
  При отображении карты Internet адресов на адреса локальной сети следует соблюдать осторожность. Единичный хост-компьютер должен уметь работать так, как если бы на его месте существовало несколько отдельных хост-компьютеров для использования нескольких адресов Internet. Некоторые хост-компьютеры будут также иметь несколько физических
интерфейсов (multi-homing).
  Таким образом, следует обеспечить каждый хост-компьютер несколькими физическими сетевыми интерфейсами, имеющими по несколько логических адресов Internet.
  Примеры построения карты адресов можно найти в документе "Address Mapping" [5].
  Фрагментация. Фрагментация Internet датаграммы необходима, когда эта датаграмма возникает в локальной сети, позволяющей работать с пакетами большого размера, и затем должна пройти к получателю через другую локальную сеть, которая ограничивает пакеты меньшим размером.
  Internet датаграмма может быть помечена как нефрагментируемая. Любая Internet датаграмма, помеченная таким образом, не может быть фрагментирована модулем Internet ни при каких условиях. Если же Internet датаграмма, помеченная как нефрагментируемая, тем не менее не может достигнуть получателя без фрагментации, то вместо этого она будет разрушена.
  Фрагментация, перенос и сборка в локальной сети, невидимые для модуля Internet протокола, называются внутрисетевой фрагментацией и могут быть всегда использованы [6].
  Необходимо, чтобы Internet процедуры фрагментации и сборки могли разбивать датаграмму на почти любое количество частей, которые впоследствии могли бы быть вновь собраны. Получатель фрагмента использует поле идентификации для того, чтобы быть убежденным в том, что фрагменты различных датаграмм не будут перепутаны. Поле смещения фрагмента сообщает получателю положение фрагмента в исходной датаграмме. Смещение фрагмента и длина определяют кусок исходной датаграммы, принесенный этим фрагментом. Флаг "more fragments" показывает (посредством перезагрузки) появление последнего фрагмента. Эти поля дают достаточное количество информации для сборки датаграмм.
  Поле идентификации позволяет отличить фрагменты одной датаграммы от фрагментов другой. Модуль Internet, отправляющий Internet датаграмму, устанавливает в поле идентификации значение, которое должно быть уникальным для данной пары отправитель - получатель, а также время, в течении которого датаграмма будет активна в системе Internet. Модуль протокола, отправляющий нерасчлененную датаграмму, устанавливает в нуль флаг "more fragments" и смещение во фрагменте.
  Чтобы расчленить большую Internet датаграмму, модуль протокола Internet (например, шлюз), создает две новые Intenet датаграммы и копирует содержимое полей Internet заголовка из большой датаграммы в оба новых Internet заголовка. Данные из старой датаграммы делятся на две части по границе на очередном восьмом октете (64 бита). Полученная таким образом вторая часть может быть кратна 8 октетам, а может и не быть, но первая часть кратна всегда. Заказывается количество блоков первой части NFB (количество блоков фрагмента). Первая часть данных помещается в первую новую Internet датаграмму, в поле общей длины помещается длина первой датаграммы. Флаг "more fragments" устанавливается в единицу. Вторая часть данных помещается во вторую новообразованную Internet датаграмму, в поле общей длины заносится длина второй датаграммы. В поле смещения фрагмента во второй Internet датаграмме устанавливается значение такого же поля в исходной большой датаграмме, увеличенное на NFB.
  Эта процедура может быть обобщена на случай многократного расщепления исходной датаграммы.
  Чтобы собрать фрагменты Internet датаграммы, модуль протокола Internet (например, модуль на хост-компьютере) объединяет Internet датаграммы, имеющие одинаковые значения в полях идентификатора, отправителя, получателя и протокола. Собственно объединение заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке Internet пакета в поле "fragment offset". Первый фрагмент будет иметь в поле "fragment offset" нулевое значение, а последний фрагмент будет иметь флаг "more fragments", вновь установленный в нуль.

2.4 Шлюзы
  С помощью шлюзов протокол Internet осуществляет передачу датаграмм между сетями. Шлюзы также поддерживают протокол шлюз-шлюз (GGR) [7] для координации маршрутизации и передачи другой управляющей информации для протокола Internet.
  Нет нужды держать на шлюзе протоколы более высокого уровня, а функции GGP добавляются к возможностям IP модуля.
                   +--------------------------------+
                   | Internet протокол & ICMP & GGP |
                   +--------------------------------+
                           |                |
                 +----------------+  +----------------+
                 | локальная сеть |  | локальная сеть |
                 +----------------+  +----------------+

Рис. 3   Протоколы шлюзов


3. Специфиация                            
3.1 Формат заголовка Internet
  Ниже приведена полная схема полей заголовка Internet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рис. 4 Пример заголовка Internet датаграммы
Заметим, что каждая позиция соответствует одному биту.

Version (версия) 4 бита
  Поле версии показывает формат заголовка Internet. Данный документ описывает версию 4.
IHL (длина Internet заголовка) 4 бита
  Длина Internet заголовка измеряется в словах по 32 бита каждый и указывает на начало поля данных. Заметим, что корректный заголовок может иметь минимальный размер 5 слов.
Type of Service (тип сервиса) 8 бит
  Тип сервиса определяет с помощью неких абстрактных параметров тип требуемого обслуживания. Эти параметры должны использоваться для управления выбором реальных рабочих характеристик при передаче датаграммы через конкретную сеть. Некоторые сети осуществляют обслуживание с приоритетом, которое неким образом дает преимущество для продвижения данной датаграммы по сравнению со всеми остальными. Реально выбор осуществляется между тремя альтернативами: малой задержкой, высокой достоверностью и высокой пропускной способностью.
  биты 0-2  приоритет
  бит 3     0 - нормальная задержка, 1 - малая задержка
  бит 4     0 - нормальная пропускная способность, 1 - высокая пропускная способность
  бит 5     0 -  обычная достоверность, 1 - высокая достоверность
  биты 6-7 зарезервированы
      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |     приоритет   |  D  |  T  |  R  |  0  |  0  |
   +-----+-----+-----+-----+-----+-----+-----+-----+

  Приоритет
  111 - управление сетью
  110 - межсетевое управление
  101 - CRITIC/ECP
  100 - более, чем мгновенно
  011 - мгновенно
  010 - немедленно
  001 - приоритетно
  000 - обычный маршрут

  Использование индикации задержки, пропускной способности и достоверности может, в некотором смысле, увеличить стоимость обслуживания. Во многих сетях улучшение одного из этих параметров связано с ухудшением другого. Исключения, когда имело бы смысл устанавливать два из этих трех параметров, очень редки.
     Тип обслуживания используется для указания типа обработки датаграммы при ее прохождении через систему Internet. Примеры отображения типа обслуживания в протоколе Internet на реальные услуги, предоставляемые такими сетями, как AUTODIN II, ARPANET, SATNET и PRNET даны в документе "Service Mapping" [8]. Значение "управление сетью" следует присваивать приоритету только для использования внутри локальной сети. Управление и реальное использование этого аргумента должно находиться в согласии с каждой применяющей его сетью. Аргумент "межсетевое управление" предназначен только для использования шлюзами, берущими на себя управление. Если вышеописанные аргументы приоритета находят применение в какой-либо сети, то это означает, что данная сеть может управлять приемом и использованием этих аргументов.
Total Length (общая длина) 16 бит
  Общая длина - это длина датаграммы, измеренная в октетах, включая Internet заголовок и поле данных. Это поле может задавать длину датаграммы вплоть до 65535 октетов. В большинстве хост-компьютеров и сетей столь большие датаграммы не используются. Все хосты должны быть готовы принимать датаграммы вплоть до 576 октетов длиной (приходят ли они целиком или по фрагментам). Хостам рекомендуется отправлять датаграммы размером более чем 576 октетов, только если они уверены, что принимающий хост готов обслуживать датаграммы повышенного размера.
     Значение 576 выбрано с тем, чтобы соответсвующим образом ограниченный блок данных передавался вместе с требуемой информацией в заголовке. Например, этот размер позволяет заполнять датаграмму полем данных размером в 512 октетов и заголовком в 64 октета. Наибольший Internet заголовок занимает 60 октетов, а его типичный размер составляет всего 20 октетов, что оставляет место под заголовки протоколов более высокого уровня.
Identification (идентификатор) 16 бит
  Идентификатор устанавливается отправителеим для сборки фрагментов какой-либо датаграммы.
Flags (различные управляющие флаги) 16 бит
  бит 0      зарезервирован, должен быть нуль
  бит 1 (DF) 0 - возможно фрагментирование, 1 - запрет фрагментации
  бит 2 (MF) 0 - последний фрагмент, 1 - будут еще фрагменты
   +----+----+----+
   |  0 | DF | MF |
   +----+----+----+

Fragment Offset (смещение фрагмента) 13 бит
  Это поле показывает, где в датаграмме находится этот фрагмент. Смещение фрагмента изменяется порциями по 8 октет (64 бита). Первый фрагмент имеет смещение нуль.
Time to Live (Время жизни) 8 бит
  Это поле показывает максимальное время, в течении которого датаграмме позволено находиться в системе Internet. Если это поле имеет значение нуль, то датаграмма должна быть разрушена. Значение этого поля изменяется при обработке заголовка Internet. Время измеряется в секундах. Однако, поскольку каждый модуль, обрабатывающий датаграмму, должен уменьшать значение поля TTL по крайней мере на единицу, даже если он обрабатываетт эту датаграмму менне, чем за секунду, то поле TTL следует понимать как максимальный интервал времени, в течении которого датаграмма может сущенствовать. Внимание следует обратить на разрушение датаграмм, не могущих достигнуть получателя, а также на ограничение времени жизни датаграммы.
Protocol (Протокол) 8 бит
  Это поле показывает, какой протокол следующего уровня использует данные из Internet датаграммы. Значения для различных протоколов приводятся в документе "Assigned Numbers" [9].
Header Checksum (Контрольная сумма заголовка) 16 бит
  Поскольку некоторые поля заголовка меняют свое значение (например, время жизни), это значение проверяется и повторно рассчитывается при каждой обработке Internet заголовка.
  Алгоритм контрольной суммы следующий:
    Поле контрольной суммы - это 16 бит, дополняющие биты в сумме всех 16 битовых слов заголовка. Для вычисления контрольной суммы значение этого поля устанавливается в нуль.
  Контрольную сумму легко рассчитать и опытным путем доказать ее адекватность, однако это временная мера и должна быть заменена CRC процедурой в зависимости от дальнейшего опыта.
Source Address (адрес отправителя) 32 бита (см. часть 3.2)
Destination Address (адрес получателя) 32 бита (см. часть 3.2)
Options (опции)    поле переменной длины
  Опции могут появиться в датаграммах, а могут и не появляться. Они должны поддерживаться всеми Internet модулями (хостами и шлюзами). Не обязательно каждая конкретная датаграмма несет опции, но нести их все же может.
  В некоторых приложениях опция секретности должна присутствовать во всех датаграммах.
  Поле опций не имеет постояннойц длины. Опций может не быть, а может быть несколько. Существуют два формата опции:
 

  • единичный октет с указанием типа опции
     
  • единичный октет с указанием типа опции, октет для указания длины опции, и, наконец, октеты собственно данных.
      Октет длины поля учитывает октет типа опции, сам себя и октеты с данными для опции.
      Считается, что октет типа опции состоит из трех полей:
         1 бит   флаг копирования
         2 бита  класс опции
         5 бит   номер опции
      Флаг копирования показывает, что эта опция копируется во все фрагменты при фрагментации.
         0 - не копируется
         1 - копируется
      Классы опции
         0 - управление
         1 - резервировано
         2 - отладка и измерения
         3 - резервировано
    Определены следующие опции Internet
    класс
    номер
    длина
    описание
    0 0 - Конец списка опций. Эта опция занимает лишь один октет; октет длины отсутствует.
    0 1 - Нет операции. Эта опция занимает лишь один октет. Не имеет октета длины.
    0 2 11 Безопасность. Используется для поддержания безопасности; изоляции; разделения на группы пользователей (TCC); обработки кодов ограничения; соответсвующих DOD требованиям.
    0 3 перем Потеря маршрута отправителя. Используется для передачи Internet датаграммы; основанной на имеющейся у отправителя информации
    0 9 перем Определение маршрута отправителя. Используется для передачи Internet датаграммы; основанной на имеющейся у отправителя информации
    0 7 перем Запись маршрута. Используется для отслеживания проходимого Internet датаграммой маршрута.
    0 8 4 Идентификатор маршрута. Используется для поддержки идентификации потока.
    2 4 перем Временной штамп Internet.

      Отдельные описания опций
               +--------+
       Тип 0   |00000000| End of Option List   (конец списка опций)
               +--------+
    

         Эта опция обозначает конец списка опций. Он может не совпадать с окончанием Internet заголовка, обозначаемым полем Internet header length. Эта опция используется после всех опций, но не после каждой. Она необходима только в том случае, если конец списка опций не совпал с окончанием Internet заголовка.
         Может быть скопирован, внесен или удален при фрагментации, или по какой-либо другой причине.
               +--------+
       Тип 1   |00000001| No operation  (нет действий)
               +--------+
    

         Эта опция может быть использована между другими опциями. Ее целью может служить, к примеру, выравнивание очередной опции по 32-битной границе. Может быть скопирована, внесена или удалена при фрагментации и по любой другой причине.
      Тип 130            Security  (безопасность)
         Эта опция дает способ хост-компьютерам отправлять параметры, связанные с безопасностью, закрытостью, введением ограничений и параметрами TCC (закрытой группой пользователей). Формат этой опции следующий:  (длина 11 октетов)
          +--------+--------+---///---+---///---+---///---+---///----+
          |10000010|00001011|SSS...SSS|CCC...CCC|HHH...HHH|   TCC    |
          +--------+--------+---///---+---///---+---///---+---///----+
    

         Поле S (security) 16 бит
            Указывает один из 16 уровней безопасности (восемь из которых зарезервировано).
            00000000 00000000 - неклассифицировано
            11110001 00110101 - конфиденциальный
            01111000 10011010 - EFTO
            10111100 01001101 - MMMM
            01011110 00100110 - PROG
            10101111 00010011 - ограниченный
            11010111 10001000 - секретный
            01101011 11000101 - особо секретный
            00110101 11100010 - резервировано
            10011010 11110001 - резервировано
            01001101 01111000 - резервировано
            00100100 10111101 - резервировано
            00010011 01011110 - резервировано
            10001001 10101111 - резервировано
            11000100 11010110 - резервировано
            11100010 01101011 - резервировано
         Поле C (compartments) 16 бит
            Нулевое значение во всех позициях используется когда передача информации не ограничена. Остальные значения для этого поля можно получить от Секретного Оборонного Агенства.
         Поле H (введение ограничений) 16 бит
            Значения для управления и внесения меток являются буквенно-цифровыми диграммами и опредены в документе DIAM 65-19 "Standard Security Markings".
         Поле TCC (поле управления переносом) 24 бита
            Дает средства для отслеживания процесса отделения, его значения контролируются группами заинтересованных подписчиков. Значения TCC имеют три поля для записей и могут быть получены из документа HQ DCA Code 530.
         Рассматриваемый тип должен копироваться при фрагментации. Эта опция появляется в датаграмме не более одного раза.
      Тип 131  Loose Source and Record Route (Потеря отправителя и запись маршрута)
          +--------+--------+---------+------- // ------+
          |10000011| длина  |указатель|данные о маршруте|
          +--------+--------+---------+------- // ------+
    

         Опция потери отправителя и записи маршрута (LSRR) обеспечивает средства, позволяющие отправителю Internet датаграммы передавать информацию, используемую шлюзами при передаче датаграмм по назначению, а также записывать информацию о маршруте. Опция начинается с кода типа. Второй октет - октет длины, которая учитывает код типа опции и сам себя, а также октет указателя. Третий октет является указателем на данные о маршруте, он определяет октет, с которого начинается следующий адрес отправителя, подлежащий обработке. Указатель отсчитывается от начала рассматриваемой опции, а его наименьшее допустимое значение - 4.
         Данные о маршруте состоят из ряда Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (поле с записями маршрута заполнено), а маршрутизация должна основываться на значениях поля с адресом получателя.
         Если адрес, записанный в поле адреса получателя, был достигнут, а указатель не превысил длину, то следующий адрес в маршруте отправителя замещает адрес в поле с адресом получателя. Записанный адрес маршрута заменяет только что использованный адрес отправителя, а указатель увеличивается на 4.
         Записанный адрес маршрута является собственным Internet адресом Internet модуля, известным во внешнем окружении, куда эта датаграмма направляется.
         Эта процедура замещения исходного маршрута записанным маршрутом (хотя при обратном порядке он должен использоваться как маршрут отправителя) означает, что данная опция (а также и весь IP заголовок) сохраняет постоянный размер при прохождении датаграммы по Internet системе.
         Эта опция называется потерей маршрута отправителя (loose source route), поскольку шлюз или IP хост могут использовать любые маршруты через любое количество других промежуточных шлюзов для достижения следующего адреса в рассматриваемом маршруте. При фрагментации опция должна копироваться. В датаграмме она должна появляться не более одного раза.
      Тип 137  Strict Source and Record Route (Уточнить отправитель и записать маршрут)
          +--------+--------+---------+------- // --------+
          |10001001| длина  |указатель| данные о маршруте |
          +--------+--------+---------+------- // --------+
    

         Опция "уточнить отправитель и записать маршрут" (SSRR) дает средства отправителю Internet датаграммы для поддержания информации о маршрутизации, которая должна использоваться шлюзами при передаче датаграммы по назначению, а также для записи этой информации.
            Опция начинается с кода типа. Второй октет - длина опции, которая учитывает код типа опции и октет длины, октет указателя (3 октета с данными о маршруте). Третий октет является указателем на данные маршрута, определяющим октет, с которого начинается следующий адрес отправителя, подлежащий обработке. Указатель отсчитывается с начала этой опции, а наименьшее допустимое значение указателя - 4.
            Данные о маршруте состоят из серии Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель превышает длину, то маршрут отправителя пуст (записываемый маршрут полон), а маршрутизация основывается на значении поля с адресом получателя.
            Если адрес в поле адреса получателя был достигнут, а указатель не превышает длины, то следующий адрес в маршруте отправителя замещает адрес в поле с адресом получателя, а записанный адрес маршрута замещает только что использованный адоес отправителя, указатель увеличивается на 4.
            Записанный адрес маршрута - это собственный Internet - адрес Internet - модуля, как он был бы распознан во внешней среде, куда эта датаграмма направляется.
            Эта процедура замещения маршрута отправителя записанным маршрутом (хотя в обратном порядке он должен использоваться как маршрут отправителя) означает, что опция (и весь IP заголовок) сохраняет постоянный размер при прохождении датаграммы через Internet систему.
            Эта опция является точным маршрутом отправителя, поскольку шлюз или IP хост должен посылать данную датаграмму непосредственно на следующий адрес в маршруте отправителя через напрямую соединенную сеть, на адрес, показывающий следующий шлюз или хост, указанный в маршруте.
            Опция должна копироваться при фрагментации. Появляется не более одного раза в датаграмме.
    Тип 7  Record Route        (Записать маршрут)
          +--------+--------+---------+------- // --------+
          |00000111| длина  |указатель| данные о маршруте |
          +--------+--------+---------+------- // --------+
    

            Опция записи маршрута дает средства для записи маршрута Internet датаграммы.
            Опция начинается с кода типа. Второй октет определяет длину опции, которая учитывает код типа опции, сам себя, октет указателя и длину трех октетов с данными о маршруте. Третий октет является указателем на данные маршрута. Указатель определяет октет, с которого начинается следующее поле для размещения адреса маршрута. Указатель отсчитывается от начала рассматриваемой опции, а его наименьшее допустимое значение - 4.
            Записываемый маршрут состоит из серии Internet адресов. Каждый Internet адрес - это 32 бита или 4 октета. Если указатель больше, чем длина опции, то поле с записываемым маршрутом заполнено. Хост - компьютер, создающий эту опцию, должен зарезервировать поле с данными о маршруте и достаточным размером, с тем, чтобы оно вместило все ожидаемые адреса. Размер этой опции не изменяется при добавлении адресов. Первоначальное содержимое поля под данные о маршруте должно быть нулевым.
            Когда Internet модуль направляет датаграмму, он проверяет ее на присутствие рассматриваемой опции с записываемым маршрутом. Если она присутствует, то он вставляет свой собственный Internet адрес в качестве распознанного во внешней среде, куда эта датаграмма направлена. Вставка осуществляется в опцию записи маршрута, в то место, на которое указывает октет указателя. Указатель затем увеличивается на 4.
            Если поле с данными о маршруте уже заполнено (указатель превышает длину), то датаграмма направляется без вставки адреса в опцию заполняемого маршрута. Если имеется некоторое пространство, но недостаточное для вставки полного адреса, то исходная датаграмма считается ошибочной и разрушается. И в том, и в другом случае на хост-отправитель напрвляется сообщение о проблеме с ICMP параметром [3].
            При фрагментации не копируется, присутствует лишь в первом фрагменте. В датаграмме присутствует не более одного раза.
    Тип 136 (длина 4) Stream Identifier (Идентификатор потока)
          +--------+--------+--------------------+
          |10001000|00000010|идентификатор потока|
          +--------+--------+--------------------+
    

            Эта опция дает средства для поддержания 16-битовой SATNET идентифткации потока в сетях, которые первоначально не поддерживали потоковую концепцию.
            Опцтя должна копироваться при фрагментации. В датаграмме появляется не более одного раза.
    Тип 68  Internet timestamp (Временной штамп Internet)
          +--------+--------+---------+-----+-----+
          |01000100| длина  |указатель|oflw | flg |
          +--------+--------+---------+-----+-----+
          |           Internet адрес              |
          +---------------------------------------+
          |              Timestamp                |
          +---------------------------------------+
          |                                       |
    

            Длина - это количество октетов в опции, которое учитывает октеты типа, длины, указателя и overflow/flag (максимальная длина 40 октетов).
            Указатель - это количество октетов от начала этой опции до конца временных штампов, плюс единица (т.е. он указывает на октет, с которого начинается свободное место для следующего временного штампа). Наименьшее допустимое значение - 5. Поле временного штампа считается заполненным, когда указатель превышает длину опции.
            Overflow (oflw, переполнение  4 бита) - это количество IP модулей, которые не могут произвести регистрацию временных штампов по причине отсутствия свободного места.
            Flag (flg, флаги  4 бита) - это
         0 - оставлять лишь временные штампы, размещенные в следующих друг за другом 32-битных словах
         1 - каждому временному штампу предшествует Internet адрес регистрируемого объекта
         3 - поля Internet адресов определены заранее. IP модуль лишь регистрирует свой временной штамп, если его собственный адрес совпадает со следующим указанным Inernet адресом.
         Timestamp - это выровненный по правой границе 32-битный временной штамп в миллисекундах (относительно полуночи по Единому Времени). Если время в миллисекундах неопределимо или не может быть отсчитано относительно полуночи по Единому Времени, то может быть внесено любое другое время в качестве временного штампа при условии, что самый старший бит в поле временного штампа будет установлен в единицу (что указавает на использование нестандартного значения).
            Хост-отправитель должен создавать эту опцию так, чтобы поля для временных штампов были достаточны для размещения всей ожидаемой информации. Размер опции не изменяется при добавлении временных штампов. Первоначально содержимое поля под временные штампы должно быть заполнено нулями, либо Internet адреса должны чередоваться с нулями.
            Если поле с временными штампами уже заполнено (указатель превышает длину опции), то датаграмма передается без вставки временного штампа, а счетчик переполнения увеличивается на единицу.
            Если имеется место, но оно недостаточно для вставки полного временного штампа, или же счетчик переполнения сам переполнен, то исходная датаграмма рассматривается как ошибочная и уничтожается. И в том, и в другом случае на хост-отправитель должно посылаться сообщение о проблеме с ICMP параметром [3].
            Опция временного штампа не копируется при фрагментации, а сохраняется в первом фрагменте. В датаграмме появляется не более одного раза.
    Padding (Выравнивание)
         Выравнивание Internet заголовка используется для того, чтобы убедиться в том, Internet заголовок заканчивается на 32-битной границе. Варавнивание осуществляется нулями.

    3.2 Обсуждение
      Реализация протокола должна быть ясной. Каждая реализация должна предвидеть работу с другими реализациями, созданными другими людьми. Хотя цель этой спецификации - уточнение данного протокола, тем не менее существует различие интерпретаций. В общем случае реализация должна сохранять консерватизм в манере отправления, а свобода существует лишь в манере получения информации. А именно, реализация должна быть аккуратной в посылке хорошо определенных датаграмм и должна принимать любую датаграмму, которую она могла бы интерпретировать (т.е. нет среды для технических ошибок).
      Основные Internet службы ориентированы на датаграммы и обеспечивают фрагментацию датаграмм на шлюзах, сборку на модуле Internet протокола на хосте-получателе. Конечно, фрагментация и сборка датаграмм в сети или по предварительному согласованию между шлюзами также разрешена, поскольку это очевидно для Internet протоколов и протоколов более высокого уровня. Этот очевидный тип фрагментации и сборки называется фрагментацией, зависящей от сети (или Internet), и далее здесь не обсуждается.
      Отправителей и получателей на уровне хост-компьютера позволяют отличать Internet адреса, а также поле протокола. Предполагается, что каждый протокол будет определять, есть ли нужда в мультиплексировании на хосте.

    Адресация
      Чтобы обеспечить гибкость в присвоении адресов комптьютерным сетям и позволить применение большого количества малых и средних сетей, поле адреса кодируется таким образом, чтобы определять малое количество сетей с большим количеством хостов, среднее количество сетей со средним количеством хостов и большое количество сетей с малым количеством хостов. Дополнительно имеется escape код для расширенного режима адресации.
    Форматы адресации
    Старшие биты
    Формат
    Класс
    0 7 бит в сети; 24 бита для хостов А
    10 14 бит в сети; 16 бит для хостов В
    110 21 бит для сети; 8 бит для хостов С
    111 переход в расширенный режим адресации

      Нулевое значение в поле сети означает данную сеть. Этот режим используется только в определенных ICMP сообщениях. Расширенный режим адресации неопределен. Обе эти возможности зарезервированы для будущих реализаций. Реальные значения, присваиваемые сетевым адресам, даны в документе "Assigned Numbers" [9].
      Локальный адрес, присвоенный локальной сети, должен позволять одиночному физическому хосту работать как несколько отдельных Internet хостов. А именно, должен существовать промежуток между адресами Internet хостов и должны присутствовать интерфейсы между сетью и хостом, которые позволили бы нескольким Internet адресам соответствовать одному интерфейсу. Хост должен иметь возможность для поддержки нескольких физических интерфейсов и для обработки датаграмм с любого из них, как если бы они были адресованы к единственному хосту.
      Карта соответствия между Internet адресами и адресами таких сетей, как ARPANET, SATNET, PRNET и др. описаны в документе "Address Mapping" [5].

    Фрагментация и сборка
      Поле Internet идентификации (ID) используется вместе с адресамиотправителя и получателя, полями протокола для идентификации фрагментов датаграммы при сборке.
      Бит флага More Fragments (MF) устанавливается, если датаграмма не является последним фрагментом. Поле Fragment Offset идентифицирует расположение фрагмента относительно начала в первоначальной нефрагментированной датаграмме. Единица измерения - 8 октетов. Стратегия фрагментации разработана так, чтобы нефрагментированная датаграмма имела нули во всех полях с информацией о фрагментации (MF=0, Fragment Offset=0). Если же Internet датаграмма фрагментируется, то выделение информации производится кусками и по границе 8 октет.
      Данный формат позволяет использовать 2**32=8192 фрагментов по 8 октетов каждый, а в целом 65536 октетов. Заметим, что это совпадает со значением поля общей длины для датаграммы (конечно, заголовок учитывается в общей длине датаграммы, но не фрагментов).
      Когда происходит фрагментация, то некоторые опции копируются, а другие остаются лишь в первом фрагменте.
      Каждый Internet модуль должен быть способен передать датаграмму из 68 октетов без дальнейшей фрагментации. Это происходит потому, что Internet заголовок может включать до 60 октетов, а минимальный фрагмент - 8 октетов. Каждый Internet - получатель должен быть в состоянии принять датаграмму из 576 октетов в качестве единого куска, либо в виде фрагментов, подлежащих сборке.
      Процесс фрагментации может повлиять на предыдущие поля
    1
    поле опций
    2 флаг "more fragments"
    3 смещение фрагмента
    4 поле длины Internet заголовка
    5 поле общей длины
    6 контрольная сумма заголовка

      Если бит флага запрета фрагментации (Don't Fragment - DF) установлен, то Internet фрагментация данной датаграммы запрещена, даже если она может быть разрушена. Данное средство может использоваться для предотвращения фрагментации в тех случаях, когда хост-получатель не имеет достаточных ресурсов для сборки Internet фрагментов.
      Одним из примеров использования средства запрета фрагментации должна служить линия, ведущая к малому хосту. Маленький хост может иметь фмксированную загрузочную программу, которая принимает датаграмму, помещает в памяти, а затем исполныет ее.
      Процедуры фрагментации и сборки наиболее просто описываются примерами. Следующие процедуры являются учебными реализациями.
      В следующих псевдопрограммах принимается следующая нотация: "=<" означает "меньше или равно", "#" означает "не равно", "=" означает "равно", "<-" означает "устанавливается в". Кроме этого, "с x по y" означает включительно по x, но не включая y. К примеру, выражение "с 4 по 7" означало бы включение 4,5 и 6, но не включало бы 7.

    Пример процедуры фрагментации
       Датаграмма наибольшего размера, которая еще может быть передана через очередную локальную сеть, называется наибольшей передаваемой единицей (maximum transmission unit - MTU).
      Если общая длина датаграммы меньше или равна максимальной
    передаваемой единице, то датаграмма передается следующим процедурам обработки. В противном случае прежде она разбивается на два фрагмента, причем первый из них будет иметь максимальный размер, соотвественно во второй фрагмент будет помещен остаток исходной датаграммы. Первый фрагмент отправляется на дальнейшую обработку, а второй повторно подвергается только что рассмотренной процедуре, если и его размер окажется слишком большим.
      Обозначения:
    FO
    смещение фрагмента
    IHL длина Internet заголовка
    DF флаг запрета фрагментации
    MF флаг появления дополнительных фрагментов
    TL общая длина
    OFO старое смещение фрагмента
    OIHL старая длина Internet заголовка
    OMF старое значение флага появление дополнительных фрагментов
    OTL старое значение общей длины
    NFB количество блоков фрагментации
    MTU максимальная длина переноса

    Процедура
    IF TL =< MTU THEN отправить датаграмму на следующие процедуры обработки
    ELSE
    IF DF =1 THEN разрушить датаграмму
    ELSE
    создать первый фрагмент
    (1) скопировать исходный Internet заголовок;
    (2) OIHL <- IHL; OTL <- TL; OMF <- MF;
    (3) NFB <- (MTU - IHL*4)/8;
    (4) взять первые NFB*8 октетов данных;
    (5) скорректировать заголовок:
    MF <- 1; TL <- (IHL*4)+(NFB*8);
    пересчитать контрольную сумму;
    (6) направить данный фрагмент на последующие процедуры обработки создать второй фрагмент:
    (7) выборочно скопировать Internet заголовок (некоторые опции не копируются, см. определение опций)
    (8) добавить оставшиеся данные
    (9) скорректировать заголовок
    IHL <- (((OIHL*4)-(длина нескопированных опций))+3)/4;
    TL <- OTL - NFB*8 - (OIHL-IHL)*4;
    FO <- OFO + NFB; MF <- OMF;
    пересчитать контрольную сумму;
    (10) Приготовить этот фрагмент к повторному тесту на необходимость фрагментации. Выполнить.

      В предыдущей процедуре каждый фрагмент (за исключением последнего) получает максимально разрешенную длину. Альтернатива может заключаться в создании датаграмм, не достигающих максимального размера. Для примера, она может включать процедуру фрагментации, которая повторно делит большие датаграммы пополам до тех пор, пока получающиеся фрагменты не станут короче, чем максимальный допустимый размер передаваемой единицы.

    Пример процедуры сборки
      Для каждой датаграммы идентификатор буфера определяется как объединение полей адреса отправителя, адреса получателя, протокола и идентификации. Если это целая датаграмма (поля fragment offset и more fragments нулевые), то все ресурсы, связанные с этим идентификатором буфера, освобождаются, а сама датаграмма направляется на следующие процедуры обработки.
      Если следующий фрагмент не связан с этим идентификатором буфера, то выделяются ресурсы для сборки. Они включают буфер данных, буфер заголовка, битовую таблицу фрагментации, поле общей длины данных, а также таймер. Данные из фрагмента помещаются в буфер данных в соответствии со значением полей fragment offset и длины, а также устанавливаются биты в битовой таблице фрагментации согласно полученным блокам фрагментов.
      Если это первый фрагмент (поле fragment offset нулевое), то его заголовок помещается в буфер заголовка. Если это последний фрагмент (поле more fragments нулевое), то вычисляется общая длина данных. Если этот фрагмент завершает датаграмму (проверяется по установке битов в таблице фрагментации), то датаграмма направляется на следующий этап обработки. В противном случае таймер устанавливается на максимальное из двух: текущее значение таймера и время жизни для данного фрагмента. Выполнение процедуры сборки приостанавливается.
      Если таймер отсчитал положенное время, то все ресурсы сборки, связанные с данным идентификатором буфера, освобождаются. Первоначальная установка таймера является нижней границей для времени ожидания при сборке. Это происходит потому, что всемя ожидания будет увеличено, если время жизни приходящего фрагмента окажется больше, но не может быть уменьшено. Установка таймера может достигать максимального времени жизни (примерно 4.25 минуты). В настоящее время рекомендуется первоначально устанавливать таймер на 15 секунд. Это значение можно изменить при получении достаночного практического опыта. Заметим, что выбор значения для этого параметра связи связан с емкостью буфера и скоростью получения данных с коммуникационных сетей. Например, скорость получения данных следует умножать на размер буфера (т.е. 10 кбайт/сек * 15 сек = 150 кбайт).
    Обозначения
    FO
    смещение фрагмента
    IHL длина Internet заголовка
    MF флаг More Fragments
    TTL время жизни
    NFB количество фрагментов
    TL общая длина
    TDL общая длина данных
    BUFID идентификатор буфера
    RCVBT битовая таблица фрагментации
    TLB нижняя граница для значения таймера

    Процедура
    (1) BUFID <- отправитель|получатель|протокол|идентификация;
    (2) IF FO = 0 AND MF = 0 THEN
    (3)     IF буфер с идентификатором BUFID выделены THEN
    (4)         завершить сборку для этого идентификатора BUFID;
    (5)         Приготовить датаграмму для дальнейшей обработки.
               Запустить обработку
    (6)     ELSE
               IF буфер для идентификатора BUFID не выделен THEN
    (7)             выделить ресурсы для сборки с идентификатором BUFID
                   TIMER <- TLB; TDL <- 0;
    (8)         перенести данные из фрагмента в буфер данных с идентификатором
               BUFID, данные с октета FO*8 по октет (TL-(IHL*4))+FO*8;
    (9)         установить биты RCVBT с FO по FO+((TL-(IHL*4)+7)/8);
    (10)        IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
    (11)        IF FO = 0 THEN поместить заголовок в буфер заголовка
    (12)        IF TDL # 0 AND все биты RCVBT с 0 по (TDL+7)/8 выставлены THEN
    (14)            TL <- TDL+(IHL*4)
    (15)            Приготовить датаграмму к дальнейшей обработке
    (16)            Освободить все ресурсы сборки для этого идентификатора
                   BUFID. Запустить обработку.
    (17)        TIMER <- MAX(TIMER,TTL);
    (18)        приостановить работу до получения следующего фрагмента или
               сигнала от таймера
    (19) Сигнал от таймера:
            Освободить все ресурсы, связанные с этим идентификатором BUFID.
      В случае, если два или более фрагмента содержат одни и те же данные, либо идентичны или частично перекрываются, то эта процедура будет использовать последнюю полученную копию при создании буфера данных и воссоздании датаграммы.

    Идентификация
      Выбор способа идентификации исходит из необходимости уникальной идентификации фрагментов конкретной датаграммы. Модуль протокола, собирающий фрагменты, считает, что они относятся к одной и той же датаграмме, если они имеют общего отправителя, получателя, протокол и идентификатор. Таким образом, отправитель должен выбрать идентификатор таким образом, чтобы он был уникален для данной пары отправителя - получателя, для данного протокола и в течении того времени, пока данная датаграмма (или любой ее фрагмент) может существовать в сети Internet.
      Очевидно, что модуль протокола, отправляющий датаграммы, должен иметь таблицу идентификаторов, где каждая запись соотносится с каждым отдельным получателем, с которым осуществлялась связь, и указывает последнее значение максимального времени жизни датаграммы в сети Internet.
      Однако, поскольку поле идентификатора позволяет использовать 65536 различных значений, некоторые хост-компьютеры могут использовать просто уникальные идентификаторы независимо от адреса получателя.
      Обычно идентификаторы выбирают протоколы более высокого уровня,
    например модули TCP протокола могут повторно передавать идентичные TCP сегменты. Вероятность правильного приема увеличивалась бы, если повторная передача осуществлялась с тем же самым идентификатором, что и исходная датаграмма, поскольку ее фрагменты могли бы использоваться для сборки правильного TCP сегмента.

    Тип обслуживания
      Тип обслуживания (TOS) используется для выбора качества Internet сервиса. Тип обслуживания определяется абстрактными параметрами приоритета, задержки, продолжительности и достоверности. Эти параметры должны отображаться на реальные параметры сервиса для конкретных сетей, через которые проходит данная датаграмма.
    Приоритет. Независимая единица измерения для важности данной датаграммы.
    Задержка. Указание задержки важно для датаграмм с этим знаком.
    Пропускная способность. Для датаграмм с этим знаком важна высокая скорость    передачи данных.
    Достоверность. Для датаграмм с таким типом обслуживания важен более высокий уровень усилий, предпринимаемых для обеспечения достоверности.
      Например, сеть ARPANET имеет бит приоритета, а также выбор между "стандартными" сообщениями (тип 0) и "неконтролируемыми" (тип 3) (также в качестве одного из сервисных параметров может использоваться выбор между единичным пакетом и многопакетными сообщениями). Неконтролируемые сообщения имеют тенденцию иметь меньшую достоверность, но и меньшую задержку. Допустим, Internet датаграмма должна быть передана через сеть ARPANET. Пусть тип Internet сервиса определен как
    приоритет
    5
    задержка 0
    пропускная способность 1
    достоверность 1

      В рассматриваемом примере отображение описанных параметров на параметры, допустимые в сети ARPANET, привело бы к установке бита приоритета ARPANET (поскольку приоритет Internet находится в верхней половине своего диапазона), выбору стандартного типа сообщений (поскольку указаны требования высокой пропускной способности и достоверности, а параметр задержки сброшен). Дополнительные детали реализации сервиса даны в документе "Service Mappings" [8].

    Время жизни
      Время жизни устанавливается отправителем в соответствии с максимальным значением, которое данная датаграмма может иметь в системе Internet. Если датаграмма пребывает в системе Internet дольше, чем указанное время жизни, она подлежит уничтожению.
      Значение в поле, где указано время жизни, должно уменьшаться в каждой точке, где обрабатывается Internet заголовок, с тем, чтобы показать время, потраченное на обработку датаграммы. Даже если нет возможности получать информацию о том, сколько реально времени было потрачено, значение этого поля должно быть уменьшено на единицу. Время изменяется в секундах (т.е. указанная единица соответствует одной секунде). Таким образом, максимальное время жизни составляет 255 секунд или 4.25 минуты. Поскольку каждый модуль, обрабатывающий датаграмму, должен уменьшать значение поля TTL по крайней мере на единицу, даже если он обрабатывает ее быстрее, чем за секунду, то поле TTL следует рассматривать лишь как верхнюю границу для времени существования датаграммы. Цель процедуры заключается в разрушении датаграмм, не достигших получателя, а также в ограничении времени жизни датаграммы в сети.
      Некоторые протоколы более высокого уровня, управляющие соединениями, основываются на предположении, что старые датаграммы-дубликаты не достигают цели по истечении определенного времени. TTL - это способ, с помощью которого такие протоколы могли бы убедиться, что их предположение удовлетворяется.

    Опции
      Опции могут присутствовать в любой датаграмме, но должны всегда быть обработаны. А именно, наличие или отсутствие какой-либо опции дело отправителя, но каждый Internet модуль должен быть в состоянии произвести разбор каждой опции.
      Опции могут оканчиваться не на 32-битной границе. В этом случае Interntet заголовок может дополняться нулевыми октетами. Первый из них должен интрепретироваться как заключительная опция, а остальные - как октеты выравнивания Internet заголовка по границе.
      Каждый Internet модуль должен быть в состоянии реагировать на каждую опцию. Например, опция безопасности требует классификации, внесения ограничений, или передачи по изолированному пути.

    Контрольная сумма
      Пересчет контрольной суммы Internet заголовка осуществляется каждый раз при его изменении. Например, это происходит при уменьшении времени жизни, добавлении или изменении Internet опций или при фрагментации. Контрольная сумма на уровне Internet имеет целью защиту полей Internet заголовка от ошибок при пересылке.
      Существуют некоторые приложения, которые могли бы допустить несколько ошибочных битов в поле данных при условии отсутствия задержки. Однако, если Internet протокол усиливает ошибочность данных, то такие приложения не могут поддерживаться.

    Ошибки
      Ошибки Internet заголовка могут быть оглашены посредством ICMP сообщений [3].

    3.3 Интерфейсы
      Функциональное описание взаимодействия между пользователем и Internet протоколом будет, в лучшем случае, умозрительным в силу специфики операционной системы. Следовательно, мы должны предупредить читатетлей, что различные реализации Internet протокола будут иметь различный интерфейс с пользователем. Тем не менее, все реализации должны давать определенный минимальный набор услуг, с тем, чтобы гарантировать, что все они придерживаются единой иерархи протоколов. Данная глава описывает интерфейс с функцией, обызательный для всех реализаций.
      Internet протокол взаимодействует, с одной стороны, с локальной сетью, а с другой - с протоколом более высокого уровня или прикладной программой. В дальнейшем протокол более высокого уровня или прикладную программу (или даже программу межсетевого шлюза) мы будем называть "пользователем", поскольку они используют Internet модуль для своих целей. Поскольку Internet протокол - это протокол работы с датаграммами, то в промежутке между этапами их передачи системе придаются минимальные ресурсы памяти, она поддерживает определенные регистры состояния, а следовательно, каждый вызов пользователем Internet протокола сообщает системе всю информацию, необходимую для осуществления требуемого сервиса.

    Пример интерфейса с вышестоящим уровнем
      Два примера вызовов, приведенные ниже, удовлетворяют запросы пользователя в общении с Internet протоколом (символ "=>" означает возвращаемое значение).
    SEND(src,dst,prot,TOS,TTL,BufPTR,len,Id,DF,opt => result)
    где
     src    - адрес отправителя
     dst    - адрес получателя
     prot   - протокол
     TOS    - тип сервиса
     TTL    - время жизни
     BufPTR - указатель буфера
     len    - длина данных в буфере
     Id     - идентификатор
     DF     - запрет фрагментации
     opt    - опции
     result - ответ:
        Ok    - успешная посылка датаграммы
        Error - ошибка в аргументах функции или в локальной сети
      Заметим, что тип сервиса TOS включает приоритет, а требование безопасности передается в качестве опции.
    RECV(BufPTR,prot => result,src,dst,TOS,len,opt)
     BufPTR - указатель буфера
     prot   - протокол
     result - ответ:
         Ok    - успешное получение датаграммы
         Error - ошибка в аргументах
     len    - длина буфера
     src    - адрес отправителя
     dst    - адрес получателя
     TOS    - тип сервиса
     opt    - опции
      Когда пользователь отправляет датаграмму, он осуществляет SEND вызов, сопровождаемый всеми аргументами. Модуль Internet протокола по получении этого вызова проверяет аргументы, приготавливает и отправляет сообщение. Если аргументы в порядке, а датаграмма принята локальной сетью, то вызов завершается успешно. Если же агрументы неверны или датаграмма не принята локальной сетью, то вызов завершается с ошибкой. В последнем случае должен быть сделан соответствующий отчет о причине проблемы, однако детали таких отчетов относятся уже к конкретным реализациям.
      В момент, когда датаграмма приходит на модуль Internet протокола из локальной сети, может присутствовать ожидающий ее RECV вызов от пользователя - адресата, а может и не присутствовать. В первом случае ожидающий вызов удовлетворяется посылкой информации из датаграммы к пользователю. Во втором случае пользователю - адресату посылается напоминание о ждущей его датаграмме. Если пользователь - адресат не присутствует, отправителю возвращается ICMP сообщение об ошибке, а принятые данные разрушаются.
      Напоминание пользователю может быть выполнено через псевдопрерывание или с помощью аналогичного механизма в соответствии с конкретной операционной системой, поддерживающей данную реализацию.
      Сделанный пользователем запрос RECV может быть немедленно удовлетворен ждущей этого датаграммой или же он может быть задержан до получения соответствующей датаграммы.
      Адрес отправителя включается в запрос на посылку, если отправляющий датаграмму хост-компьютер имеет несколько адресов (несколько физических соединений или же чисто логических адресов). Internet модуль должен следить за тем, чтобы адрес отправителоя был одним из разрешенных адресов для данного хоста.
      Реализация протокола может допускать или даже требовать применения запроса к Internet модулю для обозначения заинтересованности, или же, наоборот, использование исключительно какого-либо класса датаграмм (т.е. всех датаграмм, которые имеют в поле протокола определенное занчение).
      Данная глава характеризует функции интерфейса между пользователем и Internet протоколом. Используемые обозначения аналогичны большинству процедур функций вызовов на языках высокого уровня, однако данный способ обращения с Internert протоколом не является правилом для запросов на обслуживание типа ловушек (т.е. SVC, UUO, EMT), или для любой другой формы общения между процессами.

    Приложение А: Примеры и сценарии
    Пример 1
      Пример минимальной Internet датаграммы, несущей данные
    +-------+-------+---------------+-------------------------------+
    | Ver=4 | IHL=5 |Type of Service|          Total Length = 21    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Identification = 111    |Flg=0|    Fragment Offset = 0  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Time =123   |  Protocol =1  |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     data      |
    +-+-+-+-+-+-+-+-+
    

    Рис. 5  Пример Internet датаграммы
      Напомним, что каждая метка означает место для одного бита. Здесь приведена Internet датаграмма версии 4 Internet протокола. Internet заголовок состоит из пяти 32 битных слов, а общая длина датаграммы составляет 21 октет. Данная датаграмма является полноценной датаграммой (а не фрагментом).

    Пример 2
      В данном примере мы показываем сперва Internet датаграмму промежуточного размера (452 октета данных), а затем два Internet фрагмента, которые могли бы возникнуть при фрагментации исходной датаграммы в случае, когда максимальная допустимая единица пересылки составляла 280 октетов.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver=4 | IHL=5 |Type of Service|          Total Length = 472   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Identification = 111    |Flg=0|    Fragment Offset = 0  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Time =123   |  Protocol =6  |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    \                                                               \
    \                                                               \
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              data             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    Рис. 6 Пример Internet датаграммы
      Теперь приведем первый фрагмент, который возникает при расщеплении исходной датаграммы по границе после 256 октета данных.
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver=4 | IHL=5 |Type of Service|          Total Length = 276   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Identification = 111    |Flg=1|    Fragment Offset = 0  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Time =119   |  Protocol =6  |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    \                                                               \
    \                                                               \
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Рис. 7 Пример Internet фрагмента                    
    и второй фрагмент
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver=4 | IHL=5 |Type of Service|          Total Length = 216   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Identification = 111    |Flg=0|   Fragment Offset = 32  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Time =119   |  Protocol =6  |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    \                                                               \
    \                                                               \
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              data             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Рис. 8 Пример Internet заголовка                    

    Пример 3
      Здесь мы показываем пример, когда датаграмма имеет опции
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver=4 | IHL=8 |Type of Service|          Total Length = 576   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Identification = 111    |Flg=0|   Fragment Offset = 32  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Time =123   |  Protocol =6  |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opt. Code = x | Opt. len. = 3 | option value  | Opt. Code = x |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opt. len. = 4 |        option value           | Opt. Code = 1 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Opt. Code = y | Opt. len. = 3 | option value  | Opt. Code = 0 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              data                             |
    \                                                               \
    \                                                               \
    |                              data                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Рис. 9 Пример Internet датаграммы                    

                      Приложение Б: Порядок передачи данных                  
      Порядок передачи заголовка и данных, описанных в данном документе,
    определяется на уровне октетов. В то время как диаграмма обозначает группу
    октетов, порядок их передачи является таким же, как при чтении на
    английском языке. Например, в нижеприведенной диаграмме октеты передаются
    в порядке номеров.
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       1       |       2       |       3       |       4       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       5       |       6       |       7       |       8       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       9       |      10       |      11       |      12       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Рис. 10 Порядок передачи байтов                    
      Октет представляет собой число, для котрого самый левый бит на
    диаграмме является самым старшим или самым значащим битом. Так бит,
    отмеченный нулем, является наиболее значащим битом. Например, следующая
    диаграмма представляет число 170 (десятичное)
                                  0 1 2 3 4 5 6 7                             
                                 +-+-+-+-+-+-+-+-+                            
                                 |1 0 1 0 1 0 1 0|                            
                                 +-+-+-+-+-+-+-+-+ 

                             
                            Рис. 11 Старшинство битов                        
      Аналогично, если многооктетное поле представляет число, то самый левый
    бит в этом поле является самым значащим битом. При передаче многооктетного
    чила самый значащий октет передается первым.

                                Толковый словарь                            
    1822 BBN доклад 1822, "The Specification of the Interconnection of a Host
        and an IMP". Спецификация взаимодействия между хост-компьютером и
        сетью ARPANET.
    ARPANET проводник
        Управляющая информация в ARPANET сообщении для интерфейса между
        хост-компьютером и IMP процессором.
    ARPANET сообщение
        Единица передачи между хост-компьютером и IMP процессором в сети
        ARPANET. Максимальный ее размер примерно 1012 октетов (8096 битов).
    ARPANET пакет
        Единица передачи внутри сети ARPANET между IMP процессорами.
        Максимальный размер ее около 126 октетов (1008 бит).
    Destination (Получатель)
        Адрес получателя, поле в Internet заголовке.
    DF
        Бит запрета фрагментации в поле флагов.
    Flags (Флаги)
        Поле Internet заголовка, содержащее различные управляющие биты.
    Fragment Offset (Смещение фрагмента)
        Это поле Internet заголовка указывает, к какому месту в Internet
        датаграмме относится фрагмент.
    GGP
        Gateway to Gateway Protocol - Протокол общения между шлюзами. Данный
        протокол первоначально использовался шлюзами для управления
        маршрутизацией и другими функциями шлюзов.
    header (заголовок)
        Управляющая информация в начале сообщения, сегмента, датаграммы,
        пакета или блока данных.
    ICMP
        Internet Control Message Protocol - Протокол контрольных сообщений
        Internet. Поддерживаемое Internet модулем, ICMP сообщение передается
        от шлюзов к хост-компьютерам и между хост-компьютерами, используется
        для отчетов об ошибках а также для создания предположений о
        маршрутизации.
    Identification (Идентификация)
        Поле Internet заголовка, содержащее идентифицирующее значение,
        назначенное отправителем, и служащее для сборки фрагментов какой-либо
        датаграммы.
    IHL
        The Internet Header Length - Поле Internet заголовка. Представляет
        собой длину Internet заголовка, измеренную в 32-битных словах.
    IMP
        The Interface Message Processor - Процессор сообщений интерфейса.
        Пакетный переключатель сети ARPANET.
    Internet Address (адрес Internet)
        Четырехоктетный (32 бита) адрес отправителя или получателя. Состоит
        из поля сети и поля локального адреса.
    Internet фрагмент
        Порция данных из Internet датаграммы, снабженная Internet заголовком.
    Local Address (локальный адрес)
        Адрес хост-компьютера внутри какой-либо сети. Реальное отображение
        локального адреса Internet на адреса хост-компьютеров в сети довольно
        произвольное, что позволяет отображать несколько локальных адресов на
        один хост-компьютер.
    MF
        Флаг появления дополнительных фрагментов, содержащийся в поле флагов
        Internet заголовка
    module (модуль)
        Реализация, обычно программная, протокола или других процедур
    more-fragments flag (флаг дополнительных фрагментов)
        Флаг, показывающий, содержит ли данная Internet датаграмма
        заключительную часть исходной Internet датаграммы. Флаг включен в
        поле флагов Internet заголовка.
    NFB
        The Number of Fragments Blocks - количество блоков фрагментации с
        данными в Internet фрагменте. Иными словами, длина поля с данными.
        Единица измерения - 8 октет.
    octet (октет)
        байт с восемью битами
    Options (опции)
        Поле опций Internet заголовка, может содержать несколько опций.
        Каждая опция может иметь длину в несколько октет.
    Padding (Выравнивание)
        Поле выравнивания Internet заголовка, используемое для того, чтобы
        убедиться в том, что данные начинаются по границе 32-битного слова.
        Выравнивание осуществляется нулями.
    Protocol (Протокол)
        Для данного документа это идентификатор протокола более высокого
        уровня, поле в Internet заголовке.
    Rest (Остаток)
        Часть Internet адреса, указывающая локальный адрес.
    Source (Отправитель)
        Адрес отправителя, поле Internet заголовка.
    TCP
        Transmission Control Protocol - Протокол управления передачей.
        Протокол общения между хост-компьютерами для осуществления
        коммуникаций в среде Internet.
    TCP сегмент
        Единица данных, передаваемая между TCP модулями (имеющая TCP
        заголовок).
    TFTP
        Trivial File Transfer Protocol: Простой протокол передачи файлов,
        созданный для UDP.
    Time to Live (Время жизни)
        Поле Internet заголовка, показывающее верхний предел для времени
        существования данной Internet датаграммы.
    TOS
        Тип сервиса
    Total length (общая длина)
        Поле Internet заголовка Total Length, определяющее длину датаграммы в
        октетах, включающее Internet заголовок и данные.
    TTL
        Время жизни
    Type of Service (Тип сервиса)
        Поле Internet заголовка, определяющее тип сервиса для данной Internet
        датаграммы.
    UDP
        User Datagram Protocol. Протокол на уровне пользователя для
        приложений, ориентированных на транзакции.
    User (Пользователь)
        Пользователь Internet протокола. Это может быть модуль протокола
        более высокого уровня, прикладная программа или программа шлюза.
    Version (версия)
        Поле версии, определяющее формат Internet заголовка.

                                     Ссылки                                  
    [1] Cerf, V., "The Catenet Model for Internetworking," Офис технологий
       обработки информации, Оборонное Агентство расширенных
       исследовательских проектов, IEN 48, июль 1978.
    [2] Bolt Beranek and Newman, "Specification for the Interconnection of a
       Host and an IMP," BBN Технический отчет 1822, пересмотрен в мае 1978.
    [3] Postel, J., "Internet Control Message Protocol - DARPA Internet
       Program Protocol Specification," RFC 792, USC/Институт Информатики,
       сентябрь 1981.
    [4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON,
       компьютерное общество IEEE, конец 1978 года.
    [5] Postel, J., "Address Mappings," RFC 796, USC/Институт Информатики,
       сентябрь 1981.
    [6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer
       Networks, v.3, n.1, январь 1979.
    [7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
       Newman, август 1979.
    [8] Postel, J., "Service Mappings," RFC 795, USC/Институт Информатики,
       сентябрь 1981.
    [9] Postel, J., "Assigned Numbers," RFC 790, USC/Институт Информатики,
       сентябрь 1981.





  • Хостинг HOST-FOOD

    2014-07-27, lissyara
    gmirror

    Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
    2013-08-20, zentarim
    Scan+Print server FreeBSD 9

    Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
    2011-11-20, BlackCat
    Разъём на WiFi-карту

    Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
    2011-09-14, manefesto
    Настройка git+gitosis

    Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
    2011-08-14, zentarim
    Wi-FI роутер + DHCP + DNS

    Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
    2011-06-15, -ZG-
    Охранная система на FreeBSD+LPT

    В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
    2011-03-13, terminus
    ng_nat

    Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
    2011-02-20, Капитан
    Nagios+Digitemp

    Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
    2011-02-17, Le1
    Zyxel Configuration

    Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
    2011-02-16, fox
    hast carp zfs ucarp cluster

    HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
    2011-02-04, BlackCat
    Восстановление ZFS

    История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
    2011-02-03, Капитан
    1-Wire

    Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
    2011-01-28, Капитан
    Температура в серверной

    Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
    2011-01-21, m4rkell
    Syslog server

    Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
    2011-01-07, lissyara
    Canon/gphotofs

    Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
    2010-12-13, Al
    IPSec

    Описание принципов работы IPSEC и способов аутентификации.
    2010-12-07, manefesto
    FreeBSD on flash

    Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
    2010-12-05, Fomalhaut
    root ZFS, GPT

    Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
    2010-09-05, Cancer
    Настройка аудиоплеера на ximp3

    Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
    2010-08-31, Cancer
    Установка и настройка OpenVPN

    На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
    2010-08-25, manefesto
    freebsd lvm

    Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
    2010-04-30, gonzo111
    proftpd file auth&quota

    Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
    2010-04-22, lissyara
    tw_cli

    Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
    2010-04-14, fox
    MySQL Master+Master

    MySQL (Master Master) and (Master Slave) Как настроить репликацию…
    2010-03-09, terminus
    DNS zones

    Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
    2010-03-09, aspera
    Squid+AD (group access)

    Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
    2010-03-02, BlackCat
    Шлюз: Часть 4

    Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
    2010-03-01, BlackCat
    Шлюз: Часть 3

    Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
    2010-03-01, BlackCat
    Шлюз: Часть 2

    Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
    2010-03-01, BlackCat
    Шлюз: Часть 1

    Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
    2010-02-23, Morty
    darkstat

    Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
    2010-01-23, gonzo111
    squid+sams+sqstat

    Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
    2009-12-19, schizoid
    mpd5 + radius + ng_car + Abills

    Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
    2009-11-16, lissyara
    UFS->ZFS

    Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
    2009-11-13, gx_ua
    fusefs-ntfs

    Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
    2009-11-12, Morty
    LiveCD

    Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
    2009-09-27, lissyara
    Samba как PDC

    Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
    2009-08-30, terminus
    ipfw nat

    Подробное руководство по ipfw nat, сложные случаи конфигурации.
    2009-08-24, levantuev
    HotSpot

    Установка Hotspot системы в общественное заведение.
    2009-08-18, lissyara
    diskless

    Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
    2009-07-29, BAV_Lug
    Видеонаблюдение

    Настройка бюджетного варианта видеонаблюдения на удаленном объекте
    2009-07-22, Cancer
    OpenLDAP адресная книга

    Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
    2009-06-30, SergeySL
    AimSniff

    Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
    2009-06-25, atrium
    Управление правами доступа

    Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
    2009-06-16, DNK
    Exim+PgSQL

    Установка почтовой системы exim+pgsql на FreeBSD 7.1
    2009-05-30, mvalery
    HDD(mbr) -> HDD(gpt)

    Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
    2009-05-22, Cancer
    SendXMPP

    Отправка сообщений на Джаббер сервер по средствам SendXMPP
    2009-05-11, Raven2000
    Network UPS Tools

    Network UPS Tools представляет собой набор программ, которые обеспечивают общий интерфейс для мониторинга и администрирование UPS оборудования.
    2009-04-29, m0ps
    IPSEC over GRE with RIP

    Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
    2009-04-24, WhiteBear777
    qemu network

    Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
    2009-04-22, vp
    freebsd + huawei 162 gsm modem

    В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
    2009-04-12, mvalery
    Мониторинг RAID

    Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
    2009-04-09, texnotronic
    RAID1 via LAN

    Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
    2009-04-03, Raven2000
    Оптимизация хоста для CMS

    В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и ~10 сайтов/CMS.
    2009-04-01, atrium
    VSFTPD + AD && MySQL

    Настройка самого безопасного сервера FTP - vsftpd.
    2009-03-31, Dron
    Peoplenet + C-motech (3G)

    Описание подключения к сети Peoplenet посредством 3G модема С-motech CCu-650U на FreeBSD
    2009-03-25, lissyara
    mod_auth_external

    mod_auth_external - авторизация пользователей в apache c помощью внешней программы - например, системных пользователей.
    2009-03-24, gx_ua
    Lightsquid

    Частично lightsquid может заменить sams: быстрая и простая инсталляция, быстрый парсер, cgi скрипт для динамической генерации отчета, нет привязки к БД, различные графические отчеты, мультиязычный инт
    2009-03-18, LHC
    Установка Zabbix-1.6

    Установка и первоначальная настройка системы мониторинга Zabbix (версия 1.6)
    2009-03-16, Cancer
    Принт-Сервер Samba+LPD & AD

    Простейшая настройка Принт-Сервера на FreeBSD используя Samba+LPD & AD
    2009-03-04, Mad_caterpillar
    ipsec_vpnc

    Настройка VPN IPSec концентратора на FreeBSD 6.2 для клиента cisco с использованием ipsec-tools и авторизацией в активной директории
    2009-02-18, Andy
    Free-SA

    Программа анализирует log файлы Squid'а и формирует по ним отчет.
    2009-02-02, Cancer
    Openfire Jabber Server

    Установка Jabber сервера на примере Openfire
    2009-01-28, Cancer
    mpd5 + сжатие и шифрование

    Установка VPN сервера mpd5 + сжатие и шифрование
    2009-01-26, vp
    freebsd + webcamera

    Подключение и настройка вебмкамеры для работы с freebsd на примере Logitech QCam STX
    2009-01-10, Grishun_U_S
    конфиг для офисов

    В статье разбирается конфиг для офиса, пользователи которого имеют строгие ограничения по портам. Заворачиваем www трафик на транспарентный прокси, а остальное NAT'им. Эффективно делим канал интернет
    2008-12-27, Storoge
    sftp+chroot

    Возникла необходимость дать возможность нескольким пользователям заливать на сервер контент для своих сайтов через sftp, чтобы при этом не страдала безопасность.
    2008-12-13, Morty
    PurefFTPd

    Администрирование pureftpd-сервера с помощью вэб интерфейса Usermanager
    2008-12-11, lissyara
    termlog

    Небольшая простая утилита, использующаяся для записи в файл всего что происходит на терминалах системы. Полезно, когда есть доступ по ssh у тех, кому не очень доверяете. Паранойя - это не плохо =)
    2008-11-26, Cancer
    SQUID+SAMS +Rejik-(ADLDAP)

    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
    2008-11-22, dvg_lab
    php5-oci8

    Решение проблем segmentation fault (core dumped) при работе с oracle8-client и php5-oci8
    2008-11-21, m0ps
    NTP

    Пример настройки NTP сервера для локальной сети и клиента, для синхронизации времени с локальный NTP сервером. Обновление ntpd из портов.
    2008-11-20, Cancer
    SQUID+SAMS +Rejik-(NTLM)

    Установка Прокси сервера SQUID с аутентификацией по NTL с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf, РЕЖИК собственно рубит банеры и запрещает пользователям хо
    2008-11-20, UA
    Hotspot

    Настройка безпроводной точки доступа (WiFi) на freebsd
    2008-11-12, Shaman
    Enemy Territory

    Появилась у меня такое желание поднять сервер Enemy Territory. Поискал погуглил, ничего толкового не нашел пришлось все самому делать. И вот решил поделиться опытом. Начинаем......
    2008-11-11, lissyara
    Samba+ NT ACL

    Использование vfs самбы - модули full_audit и recycle. Настройка для использования в качестве файлопомойки с 500+ одновременно работающих юзеров. Раздача прав через нативный виндовый интерфейс.
    2008-11-11, Raven2000
    Upgrading OpenBSD

    Сегодня мы будем обновлять OpenBSD. Систему необходимо поддерживать в актуальном виде и следить, чтобы все работало, как часы и все дырки были залатаны до прихода врага =)
    2008-11-10, lexy
    SMSTools 3

    Как автоматизировать отправку и обработку входящих сообщений при помощи мобильного телефона, датакабеля и компа
    2008-11-06, Cancer
    Asterisk IP PBX

    Установка VoiP сервера Asterisk IP PBX для соединения двух шлюзов и АТС
    2008-10-30, atrium
    Samba & CUPS & AD & ACL

    Настройка Samba в роли доменного файл-сервера, и CUPS в роли принт-сервера для Windows клиентов
    2008-10-17, Raven2000
    src & ports

    Конечно, в OpenBSD система портов никогда не сможет быть полной сравнение с той же системой во FreeBSD. Связано это с тем, что разработчики включают в порты лишь те приложение которые протестированн
    2008-10-13, Morty
    Mysql - базовое описание

    Базовое описание и принципы работы с MySQL
    2008-10-10, Cancer
    exim&dovecot + fetchmail + SSL

    Exim & Dovecot + Postfixadmin & Roundcube + Fetchmail & smtp_relay С возможностью отправлять письма через смтп релей провайдера. С использование SSL шифрование: POP3s IMAPs sSMTP
    2008-10-09, m0ps
    Дополнительные порты для роутера

    Увеличение количества Ethernet портов маршрутизатора за счет свободных портов коммутатора пробросив vlan с сабинтерфейса роутера на интерфейс коммутатора.
    2008-10-06, princeps
    Bacula

    Настройка сервера системы резервного копирования Bacula на FreeBSD для бэкапов FreeBSD и Windows машин
    2008-10-02, zheromo
    Postfix + DBMail

    Создание почтовой системы на основе Postfix + DBMail + SASL2 + TLS + DSpam + ClamAV + RoundCubeWebMail
    2008-10-02, Cancer
    SugarForge CRM

    SugarForge CRM предоставляет подавляющее большинство функциональных возможностей CRM систем
    2008-09-12, arksu
    ng_ipacct + squid

    Подсчет трафика с помощью ng_ipacct. Связка ng_ipacct + squid + парсер логов + авторизатор + nginx + mysql и куча служебных скриптов для работы всей системы.
    2008-09-03, Raven2000
    GLPI

    Мне надо было найти замену существующей программы инвентаризации, чтобы за компьютерами, принтерами, картриджами, лицензиями и тп был учет. Желательно с дополнительными бонусами типа системы подачи...
    2008-09-03, salimk
    POWERDNS

    Статья о том как мигрировать с DNS сетвера ISC Bind на POWERDNS
    2008-09-03, DNK
    Rinetd

    Редирект TCP портов с помощью утилиты rinetd - просто до безобразия - само прилодение простое, конфиг в одну строчку - что ещё надо для счастья? =)
    2008-09-03, L!Ner
    eGroupWare

    Это сервер групповой работы. Он укомплектован собственным веб-интерфейсом, который обеспечивает доступ к вашим данным с любой платформы по всей планете.
    2008-08-30, jafff
    MAC адрес

    У девайса VoIP Planet VIP-000 слетел MAC адрес и стал FF-FF-FF-FF-FF-FF, как я его востанавливал
    2008-08-30, Morty
    clonehdd

    Перенесение, бэкапирование HDD,легко и просто
    2008-07-31, Raven2000
    Proxy Auto Configuration

    Возникла необходимость автоматически настраивать прокси для всех компов и не бегать например если поменялось что-то на сервере прокси. Для этого давно существует технология Proxy Auto Configuration.
    2008-07-29, f0s
    NNTP сервер

    Конфигурирование собственного NNTP-сервера.
    2008-07-28, Al
    spamooborona

    настройка yandex spamooborona в качестве smtp-proxy для работы с exim
    2008-07-28, Cancer
    SQUID+SAMS +Rejik-(NCSA)

    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты,
    2008-07-20, Raven2000
    Pax

    Эта замечательная утилита поставляется с FreeBSD по умолчанию, и она имеет неплохой потенциал. Можно создавать архивы модифицировать их, а так же живьем переносить всю операционную систему с данными
    2008-07-16, Andy2k
    BIND & AD

    Настройка BIND для обслуживания запросов контроллеров Active Directory. Альтернатива поднятию DNS от Microsoft.
    2008-07-16, aleksey.kravchenko
    Samba (PDC+BDC)

    Поднять главный (офис) и резервный (филиал) контроллер домена на базе Samba и OpenLDAP, организовать синхронизацию и репликацию между ними. Запись в LDAP должена выполняться только на PDC.
    2008-07-14, aleksey.kravchenko
    OpenVPN + LDAP

    Статья о том, как настроить OpenVPN с авторизацией пользователей в OpenLDAP.
    2008-07-14, aleksey.kravchenko
    ProFTPd + LDAP

    ProFTPd с авторизацией пользователей в OpenLDAP
    2008-07-13, lissyara
    Asus Eee PC

    Дали на несколько дней поиграться Asus Eee PC - мелкий ноутбок по смешной цене. Ну, первым делом ставим правильный ОС и смотрим - что из этого получиться.
    2008-07-09, terminus
    DNS сервер Unbound

    Установка и настройка кеширующего DNS сервера Unbound под управлением FreeBSD 7.0
    2008-07-08, f0s
    mozilla autoconfig

    Автонастройка браузера и почты Mozilla Seamonkey пользователям
    2008-07-05, lissyara
    iftop

    Утилита предназначена для мониторинга загрузки канала в режиме реального времени - позволяет видеть кто именно занял полосу. Полезно для организаций с FreeBSD на шлюзовой машине.
    2008-07-02, manefesto
    snd_hda

    Патчим snd_hda для корректной работы с наушниками
    2008-06-27, Grishun_U_S
    dd : бэкапируем windows

    Клонирование разделов windows с помощью загрузочного диска FreeBSD
    2008-06-25, terminus
    DNS сервер NSD

    Установка и настройка авторитарного DNS сервера NSD под управлением FreeBSD 7.0
    2008-06-17, Al
    NetXtreme BCM5722

    Драйвер для сетевой карты NetXtreme BCM5722 Gigabit Ethernet
    2008-06-15, tango
    Amanda

    Установка и настройка сервера резервного копирования Amanda на FreeBSD.
    2008-06-12, LMik
    Виртуальный свитч

    Статья описывает создание виртуального коммутатора для соединения удаленных физических ethernet сетей.
    2008-06-08, littlesavage
    SiS*Mirage*1 на D201GLY2

    Как заставить работать видеоrарту SiS*Mirage*1 на материнской D201GLY2
    2008-06-06, nsand
    Рыбалка на FreeBSD

    Стьатья о том как настроить рыбалку со спутника под FreeBSD
    2008-06-06, nsand
    TT budget S-1401

    Настройка драйвера ttbudget (SkyStar3) под FreeBSD
    2008-05-30, Andy2k
    NOD32 mirror

    Скрипт для создания зеркала обновлений для антивируса NOD. Автоматически ищет нужные логин-пароль для получения обновлений. В теории не требует обслуживания.
    2008-05-25, Romzes
    метаданные exif

    Пример сортировки фотографий сделаных разными фотоаппаратами, с разными названиями, датами создания/модификации. Из под консоли, конечно.
    2008-05-23, FenX
    svn+apache+trac

    Установка связки Apache2.2 + Subversion + Trac (Установка и настройка SVN сервера с доступом к репозиториям по http протоколу)
    2008-05-22, Grishun_U_S
    простой конфиг PF

    В статье разбирается простой конфигурационный файл pf "изнутри можно все"
    2008-05-20, KrivoSoft
    HAVP

    HAVP(HTTP AntiVirus proxy)- работает как http прокси, проверяющий файлики используя LibClamav. В заметке описан процес прикручивания антивируса к уже работающему прокси серверу squid.
    2008-05-20, Covax
    ALTQ в IPFW

    Исполльзование ALTQ вместе с IPFW
    2008-05-19, nonalog2007
    pppoe

    Настройка ADSL-модема для подключения к Интернет.
    2008-05-04, Abigor
    php + mssql

    Настройка php на freebsd для работы с базами в mssql по доменной авторизации.
    2008-04-28, serge
    i386=>amd64

    Рассматриваеться способ удаленной миграции с архитектуры i386 на amd64 на рабочем сервере.
    2008-04-24, Mr.Y
    Lan over Bluetooth

    Статья описывает как используя Bluetooth, объединить две FreeBSD машины в сеть.
    2008-04-19, lissyara
    WiFi WPA

    Подключение FreeBSD к беспроводной WiFi сети с использованием шифрования WPA.
    2008-04-18, nikll
    nginx+php-fpm+mysql

    Статья о настройке мощного веб сервера который не ляжет от хорошей нагрузки.
    2008-04-16, nikll
    qmail-ldap + AD

    Статья о том как я прикрутил qmail к АД win2003 (с упровлением почтовыми аккаунтами через консоль mmc из под винды)
    2008-04-14, SHPAk
    Приглашение csh/tcsh

    Приглашение csh/tcsh не всегда удобно. Здесь описано как помянять оное...
    подписка

        вверх      
    Статистика сайта
    Сейчас на сайте находится: 47 чел.
    За последние 30 мин было: 281 человек
    За сегодня было
    4677 показов,
    1166 уникальных IP
     

      Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
      Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

    © lissyara 2006-10-24 08:47 MSK

    Время генерации страницы 0.0654 секунд
    Из них PHP: 60%; SQL: 40%; Число SQL-запросов: 46 шт.
    Исходный размер: 288693; Сжатая: 55803