TCP-IP крупным планом
       

Рекомендованные значения поля типа сервиса (TOS).



Рисунок 3.2 Рекомендованные значения поля типа сервиса (TOS).


Диалоговые приложения, Telnet и Rlogin, требуют свести к минимуму задержку, так как они используются человеком интерактивно и осуществляют небольшую передачу данных. Передача файлов с использованием FTP, с другой стороны, требует максимальной пропускной способности. Максимальная надежность необходима для сетевого управления (SNMP) и для протоколов маршрутизации. Новости Usenet (NNTP) это единственное приложение, которое требует минимизации стоимости.

Характеристика TOS, в настоящее время, большинством реализаций TCP/IP не поддерживается, однако она включена в новые системы, начиная с 4.3BSD Reno. Некоторые протоколы маршрутизации, такие как OSPF и IS-IS, имеют возможность принимать решение о маршрутизации на основе этого поля.

В разделе "Вычисление загруженности последовательной линии" главы 2 мы упомянули, что драйверы SLIP обычно осуществляют построение очереди на основе типа сервиса, что позволяет диалоговому траффику обрабатываться перед передачей данных. Так как большинство реализаций не используют поле TOS, это построение очереди делается с помощью драйвера SLIP, который смотрит в поле протокола (для того чтобы определить, является ли данный сегмент TCP сегментом или нет) и затем проверяет номера портов TCP источника и назначения, чтобы определить, принадлежит ли этот номер диалоговому сервису.

Поле полной длины (total length) содержит полную длину IP датаграммы в байтах. Благодаря этому полю и полю длины заголовка, мы знаем, с какого места начинаются данные в IP датаграмме и их длину. Так как это поле состоит из 16 бит, максимальный размер IP датаграммы составляет 65535 байт. (Обратитесь к рисунку 2.5 и обратите внимание, что Hyperchannel имеет MTU, равный 65535. В действительности это не MTU - здесь используется максимально возможный размер IP датаграммы). Это поле изменяется в момент фрагментации и повторной сборки датаграммы, что будет описано в разделе "Фрагментация IP" главы 11.

Несмотря на то что существует возможность отправить датаграмму размером 65535 байт, большинство канальных уровней поделят подобную датаграмму на фрагменты. Более того, от хоста не требуется принимать датаграмму размером больше чем 576 байт. TCP делит пользовательские данные на части, поэтому это ограничение обычно не оказывает влияния на TCP. Что касается UDP, услугами которого пользуются многие приложения (RIP, TFTP, BOOTP, DNS, SNMP), то он ограничивает себя 512 байтами пользовательских данных, что даже меньше ограничения в 576 байт. Большинство приложений в настоящее время (особенно те, которые поддерживают NFS - Network File System) позволяют использовать IP датаграмму размером 8192 байта.

Однако, поле полной длины требуется в IP заголовке для некоторых каналов (как например, Ethernet), который дополняет маленькие фреймы до минимальной длины. Несмотря на то что минимальный размер фрейма Ethernet составляет 46 байт (рисунок 2.1), IP датаграмма может быть еще меньше. Если поле полной длины не было представлено, IP уровень не будет знать, сколько 46-байтных фреймов Ethernet получится из IP датаграммы.

Поле идентификации (identification) уникально идентифицирует каждую датаграмму, отправленную хостом. Значение, хранящееся в поле, обычно увеличивается на единицу с посылкой каждой датаграммы. Мы обратимся к этому полю, когда будем рассматривать фрагментацию и обратную сборку в разделе "Фрагментация IP" главы 11. Там же мы рассмотрим поле флагов (flags) и поле смещения фрагментации (fragmentation offset).

RFC 791 [Postel 1981a] сообщает, что поле идентификации должно быть выбрано верхним уровнем, который отправляет IP датаграммы, а это означает, что две последовательно отправленные IP датаграммы, одна из которых сгенерирована TCP, а другая - UDP, должны иметь одно и то же поле идентификации. Подобный подход работает (алгоритм сборки может обработать такую ситуацию). Однако, большинство реализаций, произошедших от Berkeley, увеличивают соответствующую переменную в ядре IP уровня каждый раз, когда отправляется IP датаграмма, вне зависимости от того какой уровень отправляет данные через IP. Переменная ядра инициируется каждый раз в момент загрузки системы.

Поле времени жизни (TTL - time-to-live) содержит максимальное количество пересылок (маршутизаторов), через которые может пройти датаграмма. Это поле ограничивает время жизни датаграммы. Значение устанавливается отправителем (как правило 32 или 64) и уменьшается на единицу каждым маршрутизатором, который обрабатывает датаграмму. Когда значение в поле достигает 0, датаграмма удаляется, а отправитель уведомляется об этом с помощью ICMP сообщения. Подобный алгоритм предотвращает зацикливание пакетов в петлях маршрутизации. Мы вернемся к этому полю в главе 8, когда будем рассматривать программу Traceroute.

Мы говорили о поле протокола (protocol) в главе 1 и показали на рисунке 1.8 как оно используется в IP для демультиплексирования входящих датаграмм. Это поле указывает, какой протокол отправил данные через IP.

Контрольная сумма заголовка (header checksum) рассчитывается только для IP заголовка. Она не включает в себя данные, которые следуют за заголовком. ICMP, IGMP, UDP и TCP имеют контрольные суммы в своих собственных заголовках, которые охватывают их заголовки и данные.

Чтобы рассчитать контрольную сумму IP для исходящей датаграммы, поле контрольной суммы сначала устанавливается в 0. Затем рассчитывается 16-битная сумма с поразрядным дополнением (One's complement - поразрядное дополнение к двоичной системе.) (заголовок целиком воспринимается как последовательность 16-битных слов). 16-битное поразрядное дополнение этой суммы сохраняется в поле контрольной суммы. Когда IP датаграмма принимается, вычисляется 16-битная сумма с поразрядным дополнением. Так как контрольная сумма, рассчитанная приемником, содержит в себе контрольную сумму, сохраненную отправителем, контрольная сумма приемника состоит из битов равных 1, если в заголовке ничего не было изменено при передаче. Если в результате не получились все единичные биты (ошибка контрольной суммы), IP отбрасывает принятую датаграмму. Сообщение об ошибке не генерируется. Теперь задача верхних уровней каким-либо образом определить, что датаграмма отсутствует, и обеспечить повторную передачу.

ICMP, IGMP, UDP и TCP используют такой же алгоритм расчета контрольной суммы. Также TCP и UDP включают в себя различные поля из IP заголовка, в дополнение к своим собственным заголовкам и данным. RFC 1071 [Braden, Borman, and Partridge 1988] описывает технику и реализацию расчета контрольной суммы Internet. Так как маршрутизаторы обычно изменяют только поле TTL (уменьшают его значение на единицу), маршрутизатор может просто увеличить на единицу контрольную сумму, когда он перенаправляет полученную датаграмму, вместо того чтобы рассчитывать контрольную сумму заново для IP заголовка в целом. RFC 1141 [Mallory and Kullberg 1990] описывает как этого можно добиться.

Стандартные реализации BSD, однако, не используют метод обновления контрольной суммы на единицу при перенаправлении датаграммы.

Каждая IP датаграмма содержит IP адрес источника (source IP address) и IP адрес назначения (destination IP address). Это 32-битные значения, которые мы описали в разделе "Адресация Internet" главы 1.

И последнее поле - поле опций (options), это список дополнительной информации переменной длины. В настоящее время опции определены следующим образом:

  • безопасность и обработка ограничений (для военных приложений, описано в RFC 1108 [Kent 1991]),
  • запись маршрута (запись каждого маршрута и его IP адрес, глава 7, раздел "Опция записи IP маршрута"),
  • временная марка (запись каждого маршрута, его IP адрес и время, глава 7, раздел "IP опция временной марки"),


  • свободная маршрутизация от источника (указывает список IP адресов, через которые должна пройти датаграмма, глава 8, раздел "Опция IP маршрутизации от источника"), и
  • жесткая маршрутизация от источника (то же самое, что и в предыдущем пункте, однако IP датаграмма должна пройти только через указанные в списке адреса, глава 8, раздел "Опция IP маршрутизации от источника").

Эти опции редко используются и не все хосты или маршрутизаторы поддерживают все опции.

Поле опций всегда ограничено 32 битами. Байты заполнения, значение которых равно 0, добавляются по необходимости. Благодаря этому IP заголовок всегда кратен 32 битам (как это требуется для поля длины заголовка).



Содержание раздела