Формат дейтаграммы

Формат дейтаграммы протокола IPv4 показан на рис. 4.23. Ниже перечислены ключевые поля IPv4-дейтаграммы.

□ Версия. Четыре бита в этом поле определяют номер версии протокола IP. По этому номеру маршрутизатор может определить, как интерпретировать остальные поля IP-дейтаграммы. В различных версиях протокола IP применяются различные форматы IP-дейтаграмм. На рисунке показан формат дейтаграммы текущей версии протокола IP (IPv4). Формат дейтаграммы новой версии протокола IP (IPv6) обсуждается в разделе «Протокол IPv6».
□ Длина заголовка. Поскольку IPv4-дейтаграмма может содержать разное количество необязательных полей параметров (включаемых в заголовок IPv4-дейтаграммы), эти четыре бита необходимы для того, чтобы определить, где заканчивается заголовок и начинаются данные. В большинстве IP-дейтаграмм не содержатся поля параметров, поэтому обычно заголовок IP-дейтаграммы 20-разрядный.

□ Тип службы. Поле типа службы (Type Of Service, TOS) было включено в заголовок IPv4-дейтаграммы, чтобы была возможность разделять IP-дейтаграммы на типы (например, выделять дейтаграммы, для которых требуется низкая задержка, или высокая пропускная способность, или высокая надежность). Так, может оказаться полезным отличать дейтаграммы реального времени (например, используемые в IP-телефонии) от прочего трафика (например, FTP). В последние годы один из основных производителей маршрутизаторов (Cisco) стал интерпретировать первые три бита поля TOS как идентификатор уровня услуг, предоставляемых маршрутизатором. Предоставляемый уровень услуг определяется администратором маршрутизатора. Дифференцированное обслуживание будет более подробно обсуждаться в главе 6.
□ Длина дейтаграммы. Это полная длина IP-дейтаграммы (заголовок плюс данные) в байтах. Поскольку размер этого поля равен 16 бит, теоретически максимальный размер IP-дейтаграммы может составлять 65 535 байт. Однако размер дейтаграмм редко превосходит 1500 байт и обычно ограничивается значением 576 байт.
□ Идентификатор, флаги, смещение фрагмента. Эти три поля имеют отношение к так называемой IP-фрагментации. Этот вопрос мы подробно рассмотрим чуть позже. Интересно отметить, что новая версия протокола IP (IPv6) запрещает фрагментацию в маршрутизаторах.
□ Время жизни. Поле времени жизни (Time То Live, TTL) позволяет гарантировать, что дейтаграммы не будут вечно циркулировать в сети (например, из-за существующей в течение долгого времени маршрутной петли). Значение этого поля уменьшается на единицу на каждом маршрутизаторе. Когда значение поля TTL достигает нуля, маршрутизатор отбрасывает дейтаграмму.
□ Протокол. Это поле используется только тогда, когда IP-дейтаграмма достигает конечного адресата. Значение поля определяет протокол транспортного уровня, которому следует передать данные из IP-дейтаграммы. Например, значение 6 означает, что порция данных должна быть передана протоколу TCP, а значение 17 — протоколу UDP. Список всех возможных номеров имеется в RFC 1700, RFC 3232. Обратите внимание, что роль номера протокола в IP-дейтаграмме полностью аналогична роли номера порта в сегменте транспортного уровня. Номер протокола представляет собой «клей», связывающий вместе сетевой и транспортный уровни, тогда как номер порта связывает транспортный уровень с прикладным. В главе 5 мы увидим, что в кадре канального уровня также есть специальное поле, связывающее канальный уровень с сетевым уровнем.
□ Контрольная сумма заголовка. Контрольная сумма заголовка помогает маршрутизатору обнаруживать ошибки в полученных IP-дейтаграммах. Контрольная сумма заголовка вычисляется путем суммирования всех двухбайтовых слов заголовка в дополнительном коде. Как уже упоминалось в разделе «Протокол UDP — передача без установления соединения» главы 3, дополнение до 1 этой суммы хранится в поле контрольной суммы. Маршрутизатор вычисляет контрольную сумму заголовка для каждой полученной дейтаграммы и таким образом проверяет ошибки в заголовке. Как правило, маршрутизаторы отбрасывают дейтаграммы, в которых обнаруживают ошибки. Обратите внимание, что контрольную сумму нужно вычислять заново и снова сохранять в поле заголовка на каждом маршрутизаторе, так как на единицу уменьшается поле времени жизни, могут также измениться поля параметров. Интересное описание быстрых алгоритмов для вычисления контрольной суммы заголовка IP-дейтаграммы содержится в RFC 1071. В этом месте читатели часто задают вопрос, зачем TCP/IP выполняет проверку контрольной суммы на обоих уровнях (на сетевом и на транспортном)? Тому есть несколько причин. Во-первых, на IP-уровне вычисляется только контрольная сумма IP-заголовка, тогда как на транспортном уровне вычисляется сумма всего TCP- или UDP-сегмента. Во-вторых, протоколы TCP/UDP и IP, вообще говоря, не обязаны принадлежать одному и тому же стеку протоколов. В принципе, протокол TCP может работать поверх другого протокола (например, ATM), а протокол IP может переносить данные, которые не будут передаваться протоколу TCP или UDP.
□ IP-адреса отправителя и получателя. Эти поля содержат 32-разрядные IP-адреса отправителя и конечного получателя IP-дейтаграммы. Мы подробно обсуждали IP-адресацию в подразделе «Адресация в протоколе IPv4» данного раздела. Однако нам следует упомянуть еще один тип IP-адреса, а именно широковещательный IP-адрес 255.255.255.255. Когда хост передает дейтаграмму с адресом получателя 255.255.255.255, сообщение доставляется всем хостам той же сети. Кроме того, маршрутизаторы могут переправить широковещательное сообщение в соседние IP-сети (хотя, как правило, они этого не делают). При описании протокола DHCP будет приведен пример использования широковещательного IP-пакета.
□ Параметры. Поле параметров позволяет расширить IP-заголовок. Параметры заголовка представляют собой редко используемые необязательные поля IP-дейтаграммы. Поэтому было решено не включать их в заголовок каждой дейтаграммы и таким образом снизить накладные расходы. Однако само существование необязательных полей заголовка усложняет его обработку, так как заголовки дейтаграмм могут иметь различную длину, и, чтобы определить, где заканчивается заголовок и начинается поле данных, необходимо дополнительное поле длины заголовка. Кроме того, поскольку для одних дейтаграмм требуется обработка параметров, а для других нет, время обработки IP-дейтаграммы на маршрутизаторе может варьироваться в широких пределах. Эти соображения имеют особую важность для высокопроизводительных маршрутизаторов и хостов. Среди причин, по которым в протоколе IPv6 отказались от необязательных полей заголовка, была и эта.
□ Данные {полезная нагрузка). Наконец, мы добрались до последнего, самого важного поля, ради которого и существует дейтаграмма! В большинстве случаев поле данных IP-дейтаграммы содержит сегмент транспортного уровня (TCP или UDP), который необходимо доставить адресату. Однако поле данных может содержать и другие типы данных, например сообщения протокола ICMP (который будет обсуждаться в подразделе «Протокол IСМР» данного раздела).

Обратите внимание, что IP-дейтаграмма содержит 20-разрядный заголовок (без дополнительных полей). Если дейтаграмма содержит TCP-сегмент, тогда в каждой (не фрагментированной) дейтаграмме помимо сообщения прикладного уровня содержится 40 байт заголовков (20 байт IP-заголовка и 20 байт ТСР-заголовка).