- •6. Сети tcp/ip
- •6.1. Архитектура стека протоколов tcp/ip
- •6.2.1. Структура ip-пакета
- •6.2.2. Адресация в сетях ip
- •6.2.3. Разрешение ip-адресов в физические адреса сетевых устройств. Протокол arp
- •6.2.5. Icmp-протокол обмена управляющей информацией
- •6.2.5. Ip маршрутизация
- •6.2.6. Обработка ip-пакетов маршрутизатором
6.2.1. Структура ip-пакета
Функции IP-протокола реализуются посредством специальной структуры заголовка пакета, формат которого приведен на рис. 6.3.
Заголовок содержит поля фиксированной длины (первые 20 байт) и два поля переменной длины: поле «Опции», размер которого может достигать 40 байт, и поле «Выравнивание» (Padding), которое заполняется нулями, для дополнения поля поле «Опции» до величины, кратной 32 битам. Рассмотрим назначение полей заголовка.
Версия (Version) – поле содержит номер версии протокола. Включение версии в каждую дейтограмму позволяет использовать разные, но согласующиеся, версии протолов на разных узлах сети. Так в версии 6 протокола предусмотрены механизмы обработки пакетов протокола версии 4. Во всех остальных случаях пакеты, имеющие несогласующуюся с протокольным модулем узла обработки приемника версию, отбрасываются.
Размер заголовка (Internet Header Length, IHL) - поле определяет размер заголовка в 32-битных словах. Корректный заголовок имеет длину не менее 20 байт (5 слов). Размер поля опций (в 32-разрядных словах) может быть определен как значение этого поля минус 5.
Тип сервиса (Type of service, ToS). В традиционной IP-сети это поле определяет предпочтительный тип обслуживания пакета. Первые три бита поля задают уровень приоритета (0-7); 3-5 биты определяют желательный тип обслуживания по критериям: сетевой задержки (третий бит, какая получится/низкая), пропускной способности (четвертый бит, какая угодно/высокая) и уровню потерь (пятый бит, неконтролируемый/низкий). Маршрутизаторы часто не содержат механизмов приоритетной обработки и удовлетворения перечисленных выше требований к качеству обслуживания, поскольку это выходят за пределы сервиса «как получится»; такие устройства просто игнорируют информацию, содержащуюся в этом поле. Однако, в IP-сетях для удовлетворения требований разнообразных приложений были определены несколько моделей поддержки требований качества обслуживания. Все реализации служб с согласованным качеством обслуживания непременно используют значения битов этого поля. В частности, модель дифференцированного сервиса первые 6 бит этого поля использует для задания класса сервиса доставки (Differentiated Services Code Point, DSCP; RFC 2474, 2475). Граничный маршрутизатор сети или конечный хост, задавая значение этого поля, определяют один из 64 возможных типов обслуживания пакетов. По сути, этим кодом задаются правила классификации пакетов входным интерфейсом маршрутизатора и дисциплина обслуживания очередей. В настоящее время определены четыре класса обслуживания и три уровня вероятности потерь пакетов, что дает 12 типов обслуживания. Отметим, что 3 старших бита кода DSCP непосредственно отражаются в биты приоритета, чем достигается совместимость этих кодов с уровнями приоритетов на устройствах, не поддерживающих дифференцированный сервис. Биты 6 и 7 в модели DSCP не используются. В канонической трактовке протокола они реализуют функцию управления потоком (ECN, Explicit Congestion Notification). Бит 6 устанавливается отправителем с целью индикации того, что его система способна реагировать на сигналы ECN (бит ECN). Бит 7 является собственно сигналом перегрузки (СЕ-бит, Congestion Experienced) и устанавливается маршрутизатором, если при обработке конкретного пакета размер его очереди достигает порогового значения.
Полный размер (Total length) - поле содержит общий размер пакета, величина которого не может превышать 65535 байт. Практически пакеты такой величины никогда не передаются, поскольку технологии канального уровня, в абсолютном большинстве своем не выполняющие фрагментацию, накладывают свои ограничения. Так, Ethernet не допускает кадров размером более 1518 байт, FDDI – 4096 байт и т.д. Значение параметра «Максимальная величина кадра» (Maximim Transmission Unit, MTU) определяется технологией канального уровня и, следовательно, может отличаться на разных сетевых интерфейсах даже одного устройства. В соответствии с MTU интерфейса, через который пакет должен быть отправлен на следующий узел, модуль IP выполняет фрагментацию поступающих к нему сегментов. В RFC 791 установлено, что IP-протокол должен доставлять пакеты, размер которых не превышает 576 байт без фрагментации (с такими пакетами «справляется» любая канальная технология). Следует отметить, что маршрутизатор не выполняет объединение пакетов, даже если выходной интерфейс имеет параметр MTU, допускающий кадры достаточно большого размера. Сборка фрагментированных пакетов в исходный производится станцией назначения.
Поля «Идентификатор», «Флаги» и «Смещение фрагмента» управляют процессом сборки фрагментированного пакета. Идентификатор (порядковый номер пакета) назначается хостом-источником (отправителем пакета); он остается неизменным на всем пути и устанавливается у всех его частей, если пакет подвергся фрагментации. Флаг «Don’t Fragment» - это запрещение фрагментации пакета узлами его обработки, а флаг «More Fragment» свидетельствует о наличии других фрагментов данного пакета; в последнем фрагменте этот флаг устанавливается в 0. Заметим, что размер фрагментов (без IP заголовока) должен быть кратным 8 байтам для всех фрагментов за исключением последнего. Поэтому и значение смещения задается в 8-байтовых словах; оно указывает положение поля данных текущего пакета в поле данных исходного пакета, подвергшегося фрагментации.
Время жизни (Time to live, TTL) - поле определяет максимальное время, которое пакет может существовать в сети. Его наличие помогает избежать перегрузок сети при возникновении ошибок в таблицах маршруизации, приводящих к образованию петель. Значение этого поля устанавливается при отправке пакета и уменьшается на единицу по мере прохождения им каждого маршрутизатора. При достижении нулевого значения этого поля пакет уничтожается. Максимальное значение поля – 255. Начальное значение TTL определяется операционной системой хоста-отправителя.
Протокол (Protocol) – поле указывает модулю какого протокола (TCP, UDP, ICMP, OSPF, …) следует передать полученный IP-пакет. Ниже. приведены значения этого поля для некоторых протоколов.
Таблица 6.1
-
Значение поля
Ключевое слово
Протокол
0
Reserved
Зарезервировано
1
ICMP
Internet Control Message Protocol
4
IP
Internet Protocol
6
TCP
Transmission Control Protocol
17
UDP
User Datagram Protocol
89
OSPF
Open Shortest Path First
Контрольная сумма (Header checksum) – поле содержит значение контрольной суммы, рассчитанной только по заголовку. Поскольку значения некоторых полей заголовка пакета изменяются по мере его прохождения по маршруту (поле TTL, например), то значение контрольной суммы пересчитываются на каждом маршрутизаторе. Этот механизм является единственным средством обеспечения достоверности передачи, содержащимся в протоколе IP.
Адрес отправителя (Source IP address) и Адрес получателя (Destination IP address) – поля одинаковой длины (32 бита), содержащие соответствующие адреса. Правила адресации в IP-сетях будут рассмотрены ниже.
Опции (Options) – необязательное поле, используемое при отладке сетей для запроса и реализации определенных специфических процедур обработки. Всего документом RFC 791 определены 8 опций. В частности, в этих полях могут записываться обязательный маршрут пакета от источника, реализуемый маршрут (трассировка), временные метки получения пакета каждым узлом. До недавнего времени возможности этих опциональных полей использовались редко. Однако, в связи с разработкой новых протоколов, обеспечивающих большую гибкость в обработке IP-трафика, возможность использования этих полей вновь стала предметом обсуждения соответствующих комитетов. Размер опциональных полей переменный, поэтому в заголовке каждой опции предусматривается поле ее размера. Обработка опциональных полей IP-пакета обязательна каждым узлом.
