IP-дата грамма состоит из IP-заголовка и данных, которые часто называют полезной нагрузкой (payload). Длина IP-заголовка не фиксирована.

Поле Версия (Version) состоит из четырех бит и обычно равно 4, обозначая четвертую версию протокола IP. Когда протокол IPv6 получит большее распространение, общепринятым значением станет 6. Версия 5 протокола IP была экспериментальной.

Поле Длина заголовка (Internet Header Length, IHL) состоит из 4 бит и содержит длину IP-заголовка в 32-разрядных словах. Минимальная длина IP-заголовка составляет 20 байт (пять 32-разрядных слов).

Поле Тип обслуживания (Type Ol Service, TOS) состоит из 8 бит, в нем указывают необходимость специальной обработки пакета, например минимизации задержки, повышения скорости и т. д. Подробности — в RFC 791. В настоящее время большинство маршрутизаторов Интернета просто игнорируют это поле.

Поле Длина (Length) состоит из 16 бит и характеризует общую длину (и байтах) IP-пакета. Из этого следует, что IP-пакеты не могут быть длиннее 65 535 байт, а поскольку IP-заголовок занимает как минимум 20 байт, т° полезная нагрузка составит не более 65 515 байт. Все хосты и маршрутизаторы должны поддерживать IP-пакеты длиной не менее 576 байт (20 байт — IP-заголовок, 512 байт — полезная нагрузка, 44 байта — параметры или заголовок протокола нижнего уровня). Это требование гарантирует, что IP-пакеты такой длины будут передаваться без фрагментации. (Фрагментация описана далее в этом разделе.)

Сами IP-датаграммы вкладываются в кадры протоколов нижнего уровня, например Ethernet или TokenRing, и могут пересылаться через разные сети, в которых реализации протоколов нижних уровней зачастую отличаются. Поэтому очень сложно подобрать такую длину 1Р-датаграммы, чтобы она соотносилась со всеми протоколами нижних уровней.

В результате в протоколе IP длина дата грамм не зависит от размера кадров. Реализация протокола IP разбивает дата граммы па фрагменты, каждый из которых имеет одинаковый заголовок, но разные данные. При этом в заголовках всех фрагментов, кроме последнего, в поле флагов устанавливается бит MF (more fragments). Учтите, что один компьютер способен передавать много IP-дата грамм и все они могут быть фраг-ментироваиы. Поэтому одного IP-адреса отправителя недостаточно для идентификации пакетов. Здесь помог бы номер порта, но он существует только в протоколах верхних уровней, например в UDP или TCP.

Именно в такой ситуации используется поле Идентификатор (Identification). Оно имеет одинаковое значение во всех фрагментах, составляющих одну IP-датаграмму, и определяется хостом-отправителем. Поле Смещение фрагмента (Fragment Offset ) состоит из 13 бит и задает место фрагмента мри сборке исходного потока данных. Для первого фрагмента значение смещения равно 0. Не забывайте, что разные фрагменты передаются как отдельные IP-пакеты и, возможно, по разным маршрутам. Следовательно, окончательная сборка выполняется только адресатом, а не промежуточным маршрутизатором. Механизмы сборки фрагментов описаны в RFC 815 и 791.

Поле Флаги (Flags) состоит из 3 бит. Старший бит всегда имеет значение 0. Следующий бит называется «Don't Fragment» (Не фрагментиро-вать) и, установленный в 1, говорит о недопустимости фрагментации данной дата граммы. Последний бит— «More Fragments» (Еще фрагменты) — равен 1 во всех фрагментах одной дата граммы, кроме последнего.

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

Поле Время жизни (Time То Live, T'T'L) используется несколько иначе, чем предполагалось. Его создавали как хранилище времени жизни пакета, при этом 255 секунд считалось большим временем. Трудность в том, что оценить реально необходимое значение очень сложно. Еще одна проблема — маршрутизатор, который «видит» пакет в течение миллисекунд, тем не менее сбрасывает со счетчика целую секунду. В настоящее время это поле используют в качестве счетчика количества узлов (хостов, маршрутизаторов и т. п.), пройденных пакетом, то есть как счетчик переходов (hop count). Каждый узел уменьшает его на единицу, <1 при достижении 0 пакет уничтожается. По умолчанию его значение равно 32, однако отправитель (то есть его IP) может присвоить ему любое значение.

Поле Идентификатор протокола (Protocol Identifier) состоит из 8 бит и показывает, какой протокол верхнего уровня вложен в поле данных IP-пакета. Основные его значения приведены в табл. 3-2.

Это поле используется в IP для выбора одного из протоколов верхнего Уровня, которому следует передать примятый пакет, например UDP (User Datagram Protocol) или TCP (Transmission Control Protocol). Самые последние и полные сведения об идентификаторах протоколов — в RFC 1700.

Поле Контрольная сумма (Checksum) применяется для выявления ошибок передачи пакета. Здесь контрольная сумма — это двоичное дополнение 16-разрядной суммы по содержимому заголовка. Имейте в виду, что поскольку заголовок изменяется (например, в поле TTL), то контрольная сумма пересчитываете^ каждым узлом, в том числе и всеми промежуточными.

Поле Параметры (Options) имеет переменную длину и может вообще отсутствовать (длина 0 тоже допустима). Возможны два формата этого поля:

о один байт — тип параметра;

• несколько байт — тип параметра, длина и значение. Тип параметра состоит из трех подполей.

• Флаг COPIED (I бит). Значения 1 или 0 свидетельствуют о том, необходимо или нет скопировать параметр во все фрагменты датаграммы.

о Класс параметра (2 бита). Значение 0 — контроль, 2 — отладка. Значения I и 3 зарезервированы.

о Номер параметра (5 бит).

Поле Выравнивание (Padding) — это лишь дополнительно занятое место, добавленное для того, чтобы IP-заголовок заканчивался на 32-ом байте. Например, если поле Параметры заканчивается на 30-ом байте, то поле Выравнивание состоит из 2 байт, а если поле Параметры заканчивается на 50-ом байте, то Выравнивание — из 14 байт.

Информационная архитектура



Новости за месяц

  • Август
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс