Экстернат |
Протокол Интернет версии 4
Сетевой уровень
Основным протоколом сетевого уровня является протокол Интернета (IP), которым пользуется IP-модуль для коммутации (перемещения) пакета с одного интерфейса на другой.
Протокол Интернета (Internet Protocol — IP) — это механизм передачи, используемый протоколами TCP/IP.
IP-протокол передачи дейтаграмм, не обеспечивающий надежность и не ориентированный на соединение, обслуживает передачу с наилучшими из возможных показателей (наилучшими намерениями — best effort), но без гарантий. Термин с наилучшими из возможных показателей означает, что IP не гарантирует никаких показателей, не проводит проверку ошибок или отслеживание качества передачи информации. При таком принципе сетевые ресурсы выделяются по возможности. IP предполагает ненадежность основных уровней и осуществляет передачу информации к оконечному пункту без всяких гарантий. Если надежность является важной, IP может сочетаться с надежными протоколами, такими как TCP.
IP также протокол без установления соединения. Он передает пакет коммутируемой сети, используя метод дейтаграмм. Это означает, что каждая дейтаграмма обрабатывается независимо, и каждая дейтаграмма следует разными маршрутами к конечному пункту. Поэтому дейтаграммы, переданные одним и тем же источником к одному и тому же оконечному пункту, могут поступать не по порядку, также некоторые из них могут быть потеряны или искажены во время передачи. IP полагается на протокол более высокого уровня для того, чтобы решить все эти проблемы.
Дейтаграмма
Протокол Интернета версии 4 (Internet Protocol, IPv4) решает две базовые функции: адресацию и фрагментацию. Маршрутизацию пакета модуль IP осуществляет по адресу, расположенному в заголовке пакета. Там же имеется информация о способе фрагментации / сборки дейтаграмм, если максимальная длина сетевого пакета (Maximum Transfer Unit – MTU) отличается от значения MTU, принятого на адресуемом интерфейсе.
Пакеты на уровне IP называются дейтаграммами. Рис. 4.1 а а показывает формат IP-дейтаграммы.
Дейтаграмма — пакет переменной длины (рис. 4.1 а) состоит из двух частей: заголовка и данных. Заголовок имеет от 20 до 60 байт длины и содержит существенную информацию для маршрутизации и доставки. Обыкновенно в TCP/IP заголовок содержит в себе четыре секции. Краткое описание каждого поля заголовка дано ниже.
- Версия (VER). Это поле из 4 бит определяет версию протокола IP: в настоящее время это версия 4 - IPv4 (двоичный код 0100). Однако версия 6 может полностью заменить версию 4 через несколько лет. Поле VER показывает программному обеспечению IP, функционирующему в обрабатывающем компьютере, что дейтаграмма имеет формат версии 4. Все поля должны интерпретироваться, как определено в четвертой версии протокола. Если компьютер использует некоторую другую версию IP, дейтаграмма отклоняется, но не интерпретируется некорректно.
- Длина заголовка (HLEN – Header Length). Это поле из 4 бит определяет полную длину дейтаграммного заголовка в 4-байтовых словах. Оно необходимо, потому что длина заголовка является переменной
-
Различные услуги (прежний тип сервиса). IETF недавно изменил интерпретацию и имя этого поля на 8 бит. Это поле прежде называлось типом сервиса (Service Type – TS), теперь оно называется различными услугами (DS – Differentiated Service).
Обе интерпретации показаны на рис. 4.2 а Рассмотрим каждую из них.
-
Тип сервиса (Type of Service – TOS), показан на рис. 4.2 а. В этой интерпретации первые 3 бита называются битами категории срочности (приоритета). Следующие 4 бита называются битами типа услуги, и последний бит не используется.
- Биты категории срочности (Precedence) — подполе из 3 бит в пределах от 0 (000 в двоичном представлении) до 7 (111 в двоичном представлении). Поле категории срочности определяет приоритет дейтаграммы при перегрузках. Если маршрутизатор перегружен и должен удалить некоторые дейтаграммы, то первыми будут удалены дейтаграммы с самой низкой категорией срочности. Некоторые дейтаграммы в Интернете более важны, чем другие. Например, дейтаграмма, используемая для управления сетью, намного более срочная и важная, чем дейтаграмма, содержащая дополнительную информацию для группы. В настоящее время подполе категории срочности не используется. Это, как ожидается, будет функционировать в будущих версиях.
-
Биты типа обслуживания – это подполе из 4 бит, при этом каждый бит имеет специальное значение. Хотя бит может иметь значение либо 0, либо 1, но в каждой дейтаграмме один и только один бит может иметь значение 1. Образцы битов и их интерпретация даны в табл. 4.1. С таким набором, где только один бит может принять значение 1, мы можем получить пять различных услуг.
Таблица 4.1. Тип сервиса Биты типа обслуживания Описание 0000 Нормально (по умолчанию) 0001 Минимизация стоимости 0010 Максимизация надежности 0100 Максимизация пропускной способности 1000 Минимизация задержки Прикладные программы могут запросить специальный тип услуг. Тогда биты типа обслуживания устанавливаются по умолчанию. Значения по умолчанию для некоторых приложений показаны в табл. 4.2.
Из приведенных выше таблиц ясно, что интерактивные действия, такие как запрос, требуют немедленного внимания, а действия, запрашивающие немедленный отклик, требуют минимальной задержки. Те действия, которые связаны с передачей большого объема данных, требуют максимальной пропускной способности по всему соединению. Действия по управлению нуждаются в максимальной надежности. Основные действия нуждаются в минимальной стоимости.
-
Различные услуги
В этой трактовке (рис.4.2.б) первые 6 битов компонуют кодовую комбинацию подполя, а последние два бита не используются. Кодовая комбинация подполя может применяться двумя различными способами:
- Когда 3 самых правых бита — нулевые, 3 крайних левых бита интерпретируются так же, как биты категории срочности при интерпретации типа сервиса. Другими словами, это совместимо со старой интерпретацией.
- Когда 2 самых правых бита — не все нули, 6 битов определяют 64 услуги, основанные на назначении приоритета с помощью Интернета или местных полномочий согласно табл. 4.3. Первая категория содержит 32 типа сервиса; вторая и третья содержит 16 типов каждая. Первая категория (числа 0, 2, 4, ..., 62) назначает полномочия Интернета (IETF — Internet Task Force). Вторая категория (3, 7, 11, 15, ..., 63) может использоваться местными организациями. Третья категория (1, 5, 9, ..., 61) является временной и может применяться для экспериментальных целей. Обратите внимание, что числа не непрерывны. Если бы они были непрерывны, то первая категория расположилась бы от 0 до 31, вторая от 32 до 47, и третья от 48 до 63. Это было бы несовместимо с интерпретацией бит типа услуг, потому что XXX000(включает 0, 8, 16, 24, 32, 40, 48 и 56) попадал бы во все три категории. Вместо этого, при этом методе назначения все эти услуги принадлежат категории 1. Эти назначения еще нельзя считать окончательными.
Продолжим рассмотрение полей IP-дейтаграммы.
-
Тип сервиса (Type of Service – TOS), показан на рис. 4.2 а. В этой интерпретации первые 3 бита называются битами категории срочности (приоритета). Следующие 4 бита называются битами типа услуги, и последний бит не используется.
-
Указатель полной длины. Это поле на 16 битов, которое определяет полную длину (заголовок плюс данные) дейтаграммы IP в байтах. Чтобы найти длину данных, поступающих от верхнего уровня, из полной длины вычитают длину заголовка. Длина заголовка может быть найдена, если умножить значение в HLEN поля на четыре.
Длина данных = полная длина – длина заголовка.
Так как длина поля — 16 битов, полная длина дейтаграммы IP ограничена 65 535 (216 – 1) байтами, из которых 20-60 байтов являются заголовком, а остальные — данные верхнего уровня.
Хотя размер 65 535 байтов мог бы казаться большим, размер дейтаграммы IP может увеличиться в ближайшем будущем, поскольку основные технологии позволяют даже большую производительность (большую пропускную способность).
Когда мы обсудим в следующем разделе фрагментацию, мы увидим, что некоторые физические сети не способны инкапсулировать в своих кадрах дейтаграмму 65 535 байтов.
Чтобы пройти через эти сети, дейтаграмма должна быть фрагментирована. Когда устройство обработки информации или коммутатор (маршрутизатор или хост) получает кадр, он отбрасывает этот заголовок и окончание, оставляя дейтаграмму. Почему в формат включают дополнительное поле, которое не является необходимым? Во многих случаях мы действительно не нуждаемся в этом поле. Однако есть случаи, в которых дейтаграмма — не единственная вещь, которая инкапсулирована в кадр; она может быть дополнена заполнением. Например, протокол локальной сети на основе протокола Ethernet имеет минимальное и максимальное ограничение на размер данных, которые могут быть инкапсулированы в кадре (46-1500 байтов). Если размер дейтаграммы IP меньше чем 46 байтов, будет добавляться некоторое заполнение, чтобы выполнить это требование, и в этом случае, когда устройство извлечет дейтаграмму, оно должно проверить полное поле длины, чтобы определить, какая информация является действительно данными и какая — заполнением (рис. 4.3).
-
Время жизни (Time to live). Дейтаграмма имеет ограниченное время существования при ее перемещении через Интернет. После этого считается, что информация "стареет". Это поле было первоначально разработано, чтобы сохранять метку времени, которая уменьшалась посещаемым маршрутизатором. Дейтаграмма удалялась, когда это значение метки времени становилось нулем. Однако по этой схеме все компьютеры должны синхронизировать генераторы и должны знать, как много времени требуется дейтаграмме, чтобы пройти от одного компьютера до другого. Сегодня это поле главным образом используется для того, чтобы управлять максимальным числом переприемных участков (маршрутизаторов), посещаемых дейтаграммой. Когда исходный хост посылает дейтаграмму, он сохраняет число в этом поле. Это значение приблизительно равно двум максимальным числам маршрутов между любыми двумя хостами. Каждый маршрутизатор, который обрабатывает дейтаграмму, уменьшает этот номер на единицу. Если это значение будет уменьшено до нуля, маршрутизатор удаляет дейтаграмму. Это поле необходимо, потому что таблицы маршрутизации в Интернете могут быть разрушены. Дейтаграмма может перемещаться между двумя или более маршрутизаторами в течение долгого времени и никогда не будет доставлена хосту пункта назначения. Ресурсы могут быть заняты. Это поле ограничивает полную жизнь дейтаграммы и препятствует старым дейтаграммам вывести из строя сеть и, возможно, внести путаницу в работу высокоуровневых протоколов (особенно TCP).
Другое использование этого поля должно преднамеренно ограничить прохождение пакета. Например, если источник хочет ограничить пакет в местной сети, он может хранить 1 в этом поле. Когда пакет достигает первого маршрутизатора, это значение уменьшается до 0, и дейтаграмма удаляется.
-
Протокол. Это поле на 8 бит определяется протоколом высокого уровня, который использует услуги IP-уровня. Дейтаграмма IP может инкапсулировать данные от нескольких протоколов высокого уровня, таких как ICMP, TCP, UDP (см. табл. 4.4). Это поле задает протокол конечного пункта, которому должна быть доставлена дейтаграмма. Другими словами, пока IP-протокол мультиплексирует и демультиплексирует данные от различных протоколов высоких уровней, значение этого поля помогает в процессе демультиплексирования, когда дейтаграмма прибывает к своему пункту назначения (рис. 4.4).
Числовые обозначения различных протоколов приведены в табл. 4.4.
- Контрольная сумма. Концепция контрольной суммы и ее вычисление будет обсуждаться далее.
- Адрес источника. Это поле на 32 бита определяет IP-адрес источника. Это поле должно оставаться неизменным в течение всего времени прохождения дейтаграммы по сети от хоста источника к хосту конечного пункта.
-
Адрес конечного пункта. Это поле на 32 бита определяет IP-адрес конечного пункта. Это поле должно оставаться постоянным в течение времени прохождения IP-дейтаграммы от хоста источника к хосту конечного пункта.
Поля – идентификация, флажки, смещение фрагментации — обсуждаются в следующем разделе.
Пример 1
IP-пакет прибывает с 8 первыми битами, как это показано ниже:
Приемник удаляет пакет. Почему?
Решение
В этом пакете есть ошибка. Четыре крайних левых бита (0100) показывают версию, которая является правильной. Следующие 4 бита (0010) показывают длину заголовка, что означает (2 x 4 = 8), который является неправильным. Минимальное число байтов в заголовке должно быть 20. Пакет был искажен при передаче.
Пример 2
В пакете IP значение HLEN — 1000 в двоичном представлении. Сколько байтов опций переносится этим пакетом?
Решение
Значение HLEN — 8, это означает, что общее количество байтов в заголовке — 8 x 4, или 32 байта. Первые 20 байтов — главный заголовок, следующие 12 байтов — опции.
Пример 3
В пакете IP значение HLEN – 516 и значение полного поля длины – 002816. Сколько байтов данных несет этот пакет?
Решение
Значение HLEN — 5. Это означает, что общее количество байтов в заголовке — 5 x 4, или 20 байтов (без опций). Полная длина — 40 байтов, то есть пакет несет 20 байтов данных (полных 40 из 20 для данных).
Пример 4
Пакет IP прибыл с первыми несколькими шестнадцатеричными цифрами, как показано ниже:
Сколько переприемных участков этот пакет может пройти прежде, чем будет удален? К какому протоколу верхнего уровня принадлежат данные?
Решение
Для того чтобы найти поле времени жизни, мы должны пропустить 8 байтов (16 шестнадцатеричных цифр). Поле времени жизни — это девятый байт, который равен 01. Это означает, что пакет может пройти только один переприемный участок. Поле протокола – это следующий байт (02), что означает, что протокол верхнего уровня — IGMP (см. табл. 4.4).