Введение в Интернет

1.1. Протокол IP

В Интернет используется много различных типов пакетов, но один из основных — IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP и ICMP. IP-протокол предлагает ненадежную транспортную среду: ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтаграммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтаграмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 1.5.

Поле версия характеризует версию IP-протокола (например, 4 для v4 или 6 – для v6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса или других вариаций заголовка слишком тяжелых последствий не произойдет. Понятно также, что значение поля версия во избежание непредсказуемых последствий должно контролироваться программой. Поле версия определяет то, что следует далее делать с заголовком дейтаграммы и полем данных. Ниже на рис. 1.5а для сравнения приведен формат заголовка дейтаграммы IPv6 (RFC-2460). Заголовок для IPv6 имеет размер в два раза больше, чем для IPv4.

Общим полем для заголовков является только версия. Поле длина заголовка Hlen (v4) нужно из-за возможности присутствия полей опций. Hlen — длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (Hlen=5, без опций и заполнителя). В версии 6 заголовок имеет фиксированную длину, и необходимость в поле длины заголовка отпадает. Функция тип сервиса (ToS IPv4) реализуется в IPv6 в несравненно большем объеме с помощью полей класс трафика и метка потока. Функции полей идентификатор, флаги и указатель фрагмента, управляющие фрагментацией, реализуются, если требуется, с помощью полей метка потока или следующий заголовок (IPv6).

Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset; IPv4) управляют процессом фрагментации и последующей "сборки" дейтаграммы. Идентификатор представляет собой уникальный код дейтаграммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтаграмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 — фрагментация разрешена; 1 — запрещена), бит 2 определяет, является ли данный фрагмент последним (0 — последний фрагмент; 1 — следует ожидать продолжения). Поле полная длина (IPv4) функционально эквивалентно полю размер поля данных (IPv6). Поле полная длина определяет полную длину IP-дейтаграммы (до 65535 октетов), включая заголовок и данные. В случае Ethernet длина дейтаграммы не может быть больше 1500 байт.

В IPv6 фрагментация может производиться только отправителем и можно считать, что флаг DF (не фрагментировать) по умолчанию подразумевается равным 1 (хотя поля флаги здесь по понятным причинам нет).

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов, должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Рис. 1.5. Формат дейтаграммы Интернет IPv4

Рис. 1.5a. Формат заголовка дейтаграммы IPv6

Поле протокол (IPv4) заменено в IPv6 полем следующий заголовок. При этом функциональность существенно обогатилась, так как в IPv4 можно реализовать лишь один уровень вложения (UDP, TCP, ICMP). В IPv6 этого ограничения нет, и можно обеспечить любое число уровней вложения. В определенном смысле можно утверждать, что поля протокол (IPv4) и следующий заголовок выполняют ту же функцию, что и поле версия, — определяет программу обработки вложенного заголовка.

Поле контрольная сумма заголовка (IPv4) в версии 6 удалено, так как вероятность искажения заголовка по мере развития технологии стала пренебрежимо малой. Поля TTL (IPv4) и предельное число шагов (IPv6) в настоящее время совершенно тождественны.

Поле TTL относится к числу переменных полей заголовка. При прохождении через маршрутизатор над содержимым этого поля производится операция TTL=TTL-1, при этом должна быть пересчитана контрольная сумма. И, если TTL=0, дейтаграммы отбрасываются.

Потенциально переменными полями заголовка в IPv4 являются также флаги и указатель фрагмента.

IPv6 поля опций не нужны, так как их функцию может выполнить поле следующий заголовок.

Однооктетное поле тип сервиса (TOS — type of service; IPv4) характеризует то, как должна обрабатываться дейтаграмма, как производится буферизация. Это поле делится на 6 субполей (рис. 1.5б.).

Рис. 1.5b.

Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтаграмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

0 — обычный уровень

1 — приоритетный

2 — немедленный

3 — срочный

4 — экстренный

5 — ceitic/ecp

6 — межсетевое управление

7 — сетевое управление

Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтаграммы. Так, D=1 требует минимальной задержки, T=1 — высокую пропускную способность, R=1 — высокую надежность, а C=1 — низкую стоимость. В таблице 1.1 приведены рекомендуемые значения TOS.

Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так, при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) — надежность.

До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возросло. Появилось предложение замены поля TOS на поле DSCP (Differentiated Services Code Point), которое также имеет 8 бит (см. RFC-2474). (Смотри рис. 1.6.). Биты CU пока не определены. Иногда это поле называется байтом DS (Differentiated Services).

Рис. 1.6. Формат поля DSCP.

Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000 (Таблица . 1.1.1.).

На базе DSCP разработана технология "пошагового поведения" PHB (Per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

Маршрут транспортировки IP-дейтаграммы нельзя знать заранее, это связано с поэтапным (пошаговом) принятием решения о пути каждого пакета. Это свойство маршрутизации обусловлено тем, что IP является протоколом передачи данных без установления соединения.

Поле время жизни (TTL — time to live) раньше задавало время жизни дейтаграммы в секундах, т.е. предельно допустимое время пребывания дейтаграммы в пути. В настоящее время TTL определяет предельное число маршрутизаторов, через которые может пройти дейтаграмма. При каждой обработке дейтаграммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтаграмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет алгоритм обработки поля данные (см. табл. 1.1.1).

Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтаграммы. Поле опции не обязательно присутствует в каждой дейтаграмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, то используется заполнитель. Структура октета кода опции отражена на рис. 1.7.

Рис. 1.7. Формат описания опций