На рисунке 5 показан формат IP датаграммы. Стандартный размер IP заголовка составляет 20 байт, если не присутствуют опции.

Рисунок 5 – IP датаграмма.

Мы покажем, как выглядят заголовки протоколов TCP/IP на рисунке 5. Старший значащий бит имеет номер 0 (слева), а младший значащий бит из 32-х бит имеет номер 31 и показан справа.

Байта из 32-битного значения передаются в следующем порядке: сначала биты 0 - 7, затем биты 8 - 15, затем 16 - 23 и, наконец, 24 - 31. Такой порядок движения байтов называется big endian (big endian - метод хранения или передачи данных, при котором старший значащий бит или байт стоит первым) и обязателен для всех двоичных целых чисел в TCP заголовках при их передаче по сети. Это называется порядок сетевых байтов (network byte order). Машины, которые хранят двоичные целые в других форматах, как, например, в формате little endian (little endian - метод хранения или передачи данных, при котором младший значащий бит или байт стоит первым), должны конвертировать значения заголовков в соответствующий порядок сетевых байтов перед передачей данных.

Текущая версия протокола - 4, поэтому IP иногда называется IPv4.

Длина заголовка (header length) это количество 32-битных слов в заголовке, включая любые опции. Так как это 4-битное поле, оно ограничивает размер заголовка в 60 байт. В главе 8 мы увидим, что это ограничение сильно влияет на некоторые опции, такие как опция записи маршрута. Обычная величина в этом поле (когда отсутствуют опции) - 5.

Поле типа сервиса (TOS - type-of-service) состоит из 3-битного поля приставки (которое в настоящее время игнорируется), 4 бит TOS и неиспользуемого бита, который должен быть равен 0. 4 бита TOS следующие: минимальная задержка, максимальная пропускная способность, максимальная надежность и минимальная стоимость. Только один из этих 4 бит может быть установлен в единицу одновременно. Если все 4 бита равны 0, это означает обычный сервис.

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

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

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

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

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

Поле протокола (protocol) указывает, какой протокол отправил данные через 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 заголовка, в дополнение к своим собственным заголовкам и данным.