Основным протоколом сетевого уровня является протокол Интернета (IP), которым пользуется IP-модуль для коммутации (перемещения) пакета с одного интерфейса на другой.
Протокол Интернета (Internet Protocol — IP) — это механизм передачи, используемый протоколами TCP/IP.
IP-протокол передачи дейтаграмм, не обеспечивающий надежность и не ориентированный на соединение, обслуживает передачу с наилучшими из возможных показателей (наилучшими намерениями — best
IP также протокол без установления соединения. Он передает пакет коммутируемой сети, используя метод дейтаграмм. Это означает, что каждая дейтаграмма обрабатывается независимо, и каждая дейтаграмма следует разными маршрутами к конечному пункту. Поэтому дейтаграммы, переданные одним и тем же источником к одному и тому же оконечному пункту, могут поступать не по порядку, также некоторые из них могут быть потеряны или искажены во время передачи. IP полагается на протокол более высокого уровня для того, чтобы решить все эти проблемы.
Протокол Интернета версии 4 (Internet Protocol, IPv4) решает две базовые функции: адресацию и фрагментацию. Маршрутизацию пакета модуль IP осуществляет по адресу, расположенному в заголовке пакета. Там же имеется информация о способе фрагментации / сборки дейтаграмм, если максимальная длина сетевого пакета (Maximum
Пакеты на уровне IP называются дейтаграммами. Рис. 4.1 а а показывает формат IP-дейтаграммы.
(рис 4.1) IP дейтаграмма
Дейтаграмма — пакет переменной длины (рис. 4.1 а) состоит из двух частей: заголовка и данных. Заголовок имеет от 20 до 60 байт длины и содержит существенную информацию для маршрутизации и доставки. Обыкновенно в TCP/IP заголовок содержит в себе четыре секции. Краткое описание каждого поля заголовка дано ниже.
0100). Однако версия 6 может полностью заменить версию 4 через несколько лет. Поле Обе интерпретации показаны на рис. 4.2 а Рассмотрим каждую из них.
(рис 4.2) Тип сервиса и различные услуги
000 в двоичном представлении) до 7 (111 в двоичном представлении). Поле категории срочности определяет приоритет дейтаграммы при перегрузках. Если маршрутизатор перегружен и должен удалить некоторые дейтаграммы, то первыми будут удалены дейтаграммы с самой низкой категорией срочности. Некоторые дейтаграммы в Интернете более важны, чем другие. Например, дейтаграмма, используемая для управления сетью, намного более срочная и важная, чем дейтаграмма, содержащая дополнительную информацию для группы. В настоящее время подполе категории срочности не используется. Это, как ожидается, будет функционировать в будущих версиях.| Биты типа обслуживания | Описание |
|---|---|
0000 |
Нормально (по умолчанию) |
0001 |
Минимизация стоимости |
0010 |
Максимизация надежности |
0100 |
Максимизация пропускной способности |
1000 |
Минимизация задержки |
Прикладные программы могут запросить специальный тип услуг. Тогда биты типа обслуживания устанавливаются по умолчанию. Значения по умолчанию для некоторых приложений показаны в табл. 4.2.
| Протокол | Биты обслуживания | Описание |
|---|---|---|
| ICMP | 0000 | Нормально |
| 0000 | Нормально | |
| 0001 | Минимизация стоимости | |
| 0010 | Максимизация надежности | |
| SNMP | 0010 | Максимизация надежности |
| TELNET | 1000 | Минимизация задержки |
| FTP (данные) | 0100 | Минимизация задержки |
| FTP (управление) | 1000 | Минимизация задержки |
| TFTP | 1000 | Максимизация пропускной способности |
| SMTP (команда) | 1000 | Минимизация задержки |
| DNS (UDP-запрос) | 0100 | Нормально |
| DNS (TCP-запрос) | 000 | Нормально |
| DNS (Зона) | 0100 | Максимизация пропускной способности |
Из приведенных выше таблиц ясно, что интерактивные действия, такие как запрос, требуют немедленного внимания, а действия, запрашивающие немедленный отклик, требуют минимальной задержки. Те действия, которые связаны с передачей большого объема данных, требуют максимальной пропускной способности по всему соединению. Действия по управлению нуждаются в максимальной надежности. Основные действия нуждаются в минимальной стоимости.
В этой трактовке (рис.4.2.б) первые 6 битов компонуют кодовую комбинацию подполя, а последние два бита не используются. Кодовая комбинация подполя может применяться двумя различными способами:
| Категория | Кодовая комбинация | Назначенные полномочия |
|---|---|---|
| 1 | XXXX0 | Интернет |
| 2 | XXX11 | Местные |
| 3 | XXX01 | Временные и экспериментальные |
Продолжим рассмотрение полей IP-дейтаграммы.
Длина данных = полная длина – длина заголовка.
Так как длина поля — 16 битов, полная длина дейтаграммы IP ограничена 65 535 (216 – 1) байтами, из которых 20-60 байтов являются заголовком, а остальные — данные верхнего уровня.
Хотя размер 65 535 байтов мог бы казаться большим, размер дейтаграммы IP может увеличиться в ближайшем будущем, поскольку основные технологии позволяют даже большую производительность (большую пропускную способность).
Когда мы обсудим в следующем разделе фрагментацию, мы увидим, что некоторые физические сети не способны инкапсулировать в своих кадрах дейтаграмму 65 535 байтов.
Чтобы пройти через эти сети, дейтаграмма должна быть фрагментирована. Когда устройство обработки информации или коммутатор (маршрутизатор или хост) получает кадр, он отбрасывает этот заголовок и окончание, оставляя дейтаграмму. Почему в формат включают дополнительное поле, которое не является необходимым? Во многих случаях мы действительно не нуждаемся в этом поле. Однако есть случаи, в которых дейтаграмма — не единственная вещь, которая инкапсулирована в кадр; она может быть дополнена заполнением. Например, протокол локальной сети на основе протокола Ethernet имеет минимальное и максимальное ограничение на размер данных, которые могут быть инкапсулированы в кадре (46-1500 байтов). Если размер дейтаграммы IP меньше чем 46 байтов, будет добавляться некоторое заполнение, чтобы выполнить это требование, и в этом случае, когда устройство извлечет дейтаграмму, оно должно проверить полное поле длины, чтобы определить, какая информация является действительно данными и какая — заполнением (рис. 4.3).
(рис 4.3) Инкапсуляция небольшой дейтаграммы в кадр EthernetДругое использование этого поля должно преднамеренно ограничить прохождение пакета. Например, если источник хочет ограничить пакет в местной сети, он может хранить 1 в этом поле. Когда пакет достигает первого маршрутизатора, это значение уменьшается до 0, и дейтаграмма удаляется.
(рис 4.4) Мультиплексирование данных с различными протоколами
Числовые обозначения различных протоколов приведены в табл. 4.4.
| Значение | Протокол |
|---|---|
| 1 | ICMP |
| 2 | |
| 6 | TCP |
| 17 | UDP |
| 89 | OSPF |
Поля – идентификация, флажки, смещение фрагментации — обсуждаются в следующем разделе.
Пример 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), что означает, что протокол верхнего уровня —
Дейтаграмма может проходить через различные сети. Каждый маршрутизатор извлекает дейтаграмму IP из кадра, получает его, обрабатывает и затем инкапсулирует в другом кадре. Формат и размер полученного кадра зависят от протокола, используемого физической сетью, через которую кадр только что проходил. Формат и размер посланного кадра зависят от протокола, применяемого физической сетью, через которую кадр собирается проходить. Например, если маршрутизатор подключает сеть Ethernet к сети Token Ring ("Кольцевая сеть с маркерным доступом"), он получает кадр в формате Ethernet и посылает кадр в формате Token Ring (см. "
Каждый протокол уровня звена передачи данных имеет свой собственный формат кадра. Одно из полей, определенных в формате – это максимальный размер поля данных. Другими словами, когда дейтаграмма инкапсулируется в кадр, полный размер дейтаграммы должен быть меньше, чем максимальный размер кадра, который определен ограничениями аппаратных и программных средств, используемых в сети (рис. 4.5).
(рис 4.5) Максимальный модуль передачи
Значение
В части функционирования IP-поток не зависит от физической сети. При создании пакетов стараются сделать так, чтобы добиться максимальной длины IP-дейтаграммы, равной максимальной
| Протокол | |
|---|---|
| Hyperchannel | 65 535 |
| Token Ring (16 Мбит/с) | 17 914 |
| Token Ring (4 Мбит/с) | 4 484 |
| FDDI | 4 352 |
| Ethernet | 1500 |
| X.25 | 576 |
| PPP | 296 |
Это делает передачу более эффективной, если мы используем протокол, позволяющий такой максимальный размер модуля передачи. Однако для другой физической сети необходимо разделить дейтаграмму, чтобы сделать возможным передачу через эту сеть. Это разделение называется фрагментацией.
Когда дейтаграмма фрагментируется, каждый фрагмент имеет собственный заголовок с большинством повторяющихся полей, но некоторые из них изменяются. Фрагментированная дейтаграмма может быть фрагментирована, если она сталкивается с сетью, которая имеет еще более мелкие
Дейтаграмма может быть фрагментирована хостом источника или любым маршрутизатором на пути следования. Однако собирается (реассемблируется) дейтаграмма только пунктом конечного назначения, потому что каждый фрагмент поступает в независимой дейтаграмме. Фрагментированная дейтаграмма может проходить через различные маршрутизаторы, и невозможно ни управлять ей, ни гарантировать, какой маршрут она может выбрать. Все фрагменты, принадлежащие одной и той же дейтаграмме, должны в конечном итоге прибывать в хост пункта назначения. Такова логика реассемблирования в конечном пункте назначения.
Когда дейтаграмма фрагментирована, требуемые части заголовка должны быть скопированы всеми фрагментами. Поле опции может или не может быть скопировано, как увидим в следующем разделе. Хост или маршрутизатор, который фрагментирует дейтаграмму, должны изменить значения трех полей: флажки, смещение фрагментации и полная длина. Остальная часть полей должна быть скопирована. Конечно, значение контрольной суммы должно быть повторно вычислено независимо от фрагментации.
Поля, которые связаны с фрагментацией и повторной сборкой IP-дейтаграммы — это (см. рис. 4.1):
(рис 4.6) Пример фрагментации
Помните, что значение смещения измерено в единицах 8 байт. Это сделано, потому что длина поля смещения составляет только 13 битов и не может представить последовательность байтов больше, чем 8191. Это вынуждает хосты или маршрутизаторы, которые фрагментируют дейтаграммы, выбрать размер каждого фрагмента так, чтобы номер первого байта делился на 8.
Рис. 4.7. показывает расширенный вид фрагментов предыдущего рисунка. Заметим, что значение поля идентификации — одно и то же во всех фрагментах. Также заметим, что значение поля флажков установлено с третьим битом флага, равным 1 для всех фрагментов, кроме последнего. Также показано значение поля смещения для каждого фрагмента.
(рис 4.7) Детальный пример фрагментации
Рисунок показывает, что получается, если фрагментирован сам фрагмент. В таком случае значение поля смещения всегда дается относительно первоначальной дейтаграммы. Например, на рисунке второй фрагмент сам фрагментирован на два фрагмента — 800 байтов и 600 байтов, но смещение показано относительно позиции фрагментов первоначальных данных.
Очевидно, что, даже если каждый фрагмент следует различным путем и прибывает в неисправном состоянии, заключительный хост пункта назначения может повторно собрать первоначальную дейтаграмму из полученных фрагментов (если ни один из них не потерян), используя следующую стратегию:
Пример 5
Пакет прибывает со значением бита M = 0. Это первый фрагмент, последний фрагмент или средний фрагмент? Можно ли узнать, был ли пакет фрагментирован?
Решение
Если бит M = 0, это означает, что далее нет фрагментов; этот фрагмент — последняя единица. Однако мы не можем сказать, был ли пакет фрагментирован или нет. Не фрагментированный пакет считается последним фрагментом.
Пример 6
Пакет прибывает со значением бита M = 1. Является ли этот пакет первым фрагментом, последним фрагментом или средним фрагментом? Можно ли узнать, был ли пакет фрагментирован?
Решение
Если бит M = 1, это означает, что имеется, по крайней мере, дальнейший фрагмент. Фрагмент может быть первой и средней единицей, но не последней. Мы не знаем, первая это единица или средняя; нам нужна дальнейшая информация — значение смещения фрагмента. Однако мы можем определенно сказать, что M = 1.
Пример 7
Пакет прибывает со значением бита M = 1, смещение фрагментации имеет значение 0. Является ли этот пакет первым фрагментом, последним фрагментом или средним фрагментом?
Решение
Поскольку M = 1, это или первый, или средний фрагмент. Поскольку смещение фрагмента равно 0 – это первый фрагмент.
Пример 8
Прибывает пакет, в котором значение смещения – 100. Каков номер первого байта? Знаем ли мы номер последнего байта?
Решение
Для того чтобы найти номер первого байта, мы умножаем значение смещения на 8. Это означает, что номер первого байта 800. Мы не можем опередить номер последнего байта, если мы не знаем длину данных.
Пример 9
Прибывает пакет, в котором значение смещения – 100, значение HLEN – 5 и значение поля полной длины – 100. Каковы номера первого байта и последнего байта?
Решение
Номер первого байта 100 * 8 = 800. Полная длина 100 байт и длина заголовка 20 байт (5 x 4), которая означает, что в этой дейтаграмме имеется 80 байт. Если номер первого байта 800, последний номер должен быть 879.
Заголовок дейтаграммы IP состоит из двух частей: фиксированная часть и переменная часть. Фиксированная часть имеет 20 байтов длины, мы обсуждали ее в предыдущем разделе. Переменная часть включает опции, которые могут быть максимально 40 байт. Опции не требуются для каждой дейтаграммы. Они используются для испытания сети и отладки. Хотя опции — не обязательная часть заголовка IP, обработка опции требует программного обеспечения IP. Это означает, что все применяемые средства должны быть способны обработать опции, если они окажутся в заголовке.
Рис. 4.8. показывает формат опции. Он составлен из 1-байтового поля кода, 1-байтового поля длины и поля данных переменного размера.
(рис 4.8) Формат опции
Код
Длина
Поле длины определяет полную длину опции, включая поле кода и длину самого поля. Это поле не входит в некоторые типы опций.
Данные
Поле "данные" содержит данные, которые задают требуемые опциям. Это поля не входит в некоторые типы опций.
Как раньше было упомянуто, в настоящее время используются шесть опций. Две из них — 1-байтные, и они не требуют полей длины или данных. Четыре из них — многобайтные опции; они требуют полей длины и данных (рис. 4.9).
(рис 4.9) Категории опций
Опция нет оператора — однобайтовая опция, используемая как наполнитель между опциями. Например, она может использоваться для того, чтобы выровнять следующую к границе опцию на 32 бита или 16 бит (рис. 4.10).
(рис 4.10) Опция "нет операции"
"Конец опции" — также однобайтовая опция, используемая для того, чтобы дополнить конец поля опции. Однако он может использоваться только как последняя опция. Только один конец опции может использоваться опцией. После этой опции приемник ищет данные полезной нагрузки. Это означает, что, если необходим больше чем 1 байт, чтобы выровнять поле опции, некоторые опции "нет оператора" не должны быть использованы вслед за "концом опции" (рис. 4.11).
(рис 4.11) Опция "конец опции"
Опция запись полного маршрута (Record Route) имеет тип опции 7 и предписывает маршрутизатору записывать все IP-адреса, через которые проходит маршрут следования пакета. Во избежание нехватки длины поля о данных маршрута ее следует выбирать достаточно большой, в противном случае соответствующий маршрутизатор генерирует исходящему узлу сообщение об ошибке. Запись маршрута может содержать список до девяти адресов IP-маршрутизатора, в то же время максимальный размер заголовка — 60 байтов, которые должны включать в себя 20 байтов для основного заголовка. Это подразумевает, что только 40 байтов оставляют для части "опция". Источник создает незаполненные места в опции — она будет заполнена маршрутизаторами, которые прошла дейтаграмма. Рис. 4.12 показывает формат опции "запись маршрута".
И код и поля длины были описаны выше. Поле указателя — поле смещения, целое число, содержащее номера байта первого пустого входа. Другими словами, он указывает на первый доступный вход.
(рис 4.12) Опция "запись маршрута"
Источник создает пустые поля для адресов IP в поле данных опции. Когда дейтаграмма оставляет источник, все поля пусты. Поле указателя имеет значение 4, указывая на первое пустое поле. Поэтому при переходе от маршрутизатора к маршрутизатору указатель длины меняется на 4. Когда дейтаграмма перемещается, каждый маршрутизатор, который обрабатывает дейтаграмму, сравнивает значение указателя со значением длины. Если значение указателя больше, чем значение длины, опция полна, и никакие изменения не делаются.
Однако если значение указателя не больше, чем значение длины, маршрутизатор вставляет свой исходящий адрес IP в следующее пустое поле. Напомним, что маршрутизатор может иметь несколько адресов. В данном случае он имеет входящий и исходящий адрес. В этом случае маршрутизатор добавляет адрес IP своего исходящего интерфейса, т. е. того, который дейтаграмма покидает. Маршрутизатор затем увеличивает значение указателя 4. Рис. 4.13. показывает, как перемещается дейтаграмма слева направо от маршрутизатора к маршрутизатору.
(рис 4.13) Концепция записи маршрута
Опция свободная маршрутизация (Loose Source and Record Route – LSRR) имеет тип опции 131 и разрешает маршрутизатору использовать любой из альтернативных маршрутов для достижения очередного адреса назначения из данных маршрута. Если адрес назначения (
Опция строгая маршрутизация от источника(Strict Source and Record Route – SSRR) имеет тип опции 137 и предписывает маршрутизатору использовать только смежные маршрутизаторы для достижения очередного адреса из данных маршрута. Она применяется источником, чтобы предопределить маршрут для дейтаграммы, как он проходит через Интернет. Задание маршрута источником может быть полезно с точки зрения нескольких целей. Отправитель может выбрать маршрут с определенным типом обслуживания, например, с минимальной задержкой или максимальной производительностью. Альтернативно, она может выбрать маршрут, который более безопасен или более достоверен для целей отправителя — например так, чтобы дейтаграмма не проходила через сеть конкурента.
Если дейтаграмма задает строгую маршрутизацию от источника, все маршрутизаторы, определенные в опции, должны быть пройдены дейтаграммой. Маршрутизатор не должен быть пройден, если его адрес IP не содержится в списке дейтаграммы. Если дейтаграмма проходит маршрутизатор, который не находится в списке, дейтаграмма отклоняется и создается сообщение об ошибках. Если дейтаграмма достигает пункта назначения и некоторые из адресов не были использованы, она будет также отклонена и создано сообщение об ошибках.
Однако непривилегированные пользователи обычно не знают о физической топологии Интернета. Следовательно, строгая исходная маршрутизация не является опцией большинства пользователей.
Формат подобен опции "записи маршрута", за исключением того, что все адреса IP введены отправителем.
Когда дейтаграмма проходит по сети каждый маршрутизатор, который обрабатывает дейтаграмму, сравнивает значение указателя со значением длины. Если значение указателя больше, чем значение длины, — дейтаграмма посетила все предопределенные маршрутизаторы. Тогда она не может больше перемещаться; она будет отклонена, и создается сообщение об ошибках. Если значение указателя не больше, чем значение длины, маршрутизатор сравнивает адрес IP указанный в сообщении с его входящим адресом IP. Если они равны, он обрабатывает дейтаграмму, записывает поверх текущего адреса IP его исходящий адрес IP, увеличивает значение указателя 4 и передает дейтаграмму вперед. Если они не равны, он удаляет дейтаграмму и создает сообщение об ошибках. Рис. 4.14. показывает действия, предпринимаемые каждым маршрутизатором, пока дейтаграмма перемещается от источника до пункта назначения.
(рис 4.14) Концепция "строгая маршрутизация от источника" маршрута
Опция несвязанная маршрутизация от источника — смягченная версия строгой маршрутизации от источника. Согласно ей дейтаграмма должна пройти каждый маршрутизатор в списке, но может также посетить другие маршрутизаторы.
Перечисленные опции используются администраторами сетей для проверки работоспособности определенных маршрутов. На рис. 4.15. показано применение этой опции для тестового петлевого соединения по маршруту: сеть A – сеть B – сеть C – сеть D – сеть A через промежуточную сеть B. Результирующее поле данных маршрута содержит информацию обо всех IP-адресах в порядке их прохождения.
(рис 4.15) Обработка полей в опции свободная маршрутизация — LSRR
Опция метки времени используется, чтобы сделать запись времени обработки дейтаграммы маршрутизатором. Время выражено в миллисекундах, отсчет ведется с полуночи – так называемое Универсальное время. Обработка значения времени дейтаграммы может помочь пользователям и менеджерам проследить поведение маршрутизаторов в Интернете. Мы можем оценить время, которое требуется для дейтаграммы, чтобы пройти от одного маршрутизатора к другому. Мы говорим "оценка", потому что, хотя все маршрутизаторы могут использовать Универсальное время, их местные часы могут быть не синхронизированы.
Однако непривилегированные пользователи обычно не знают о физической топологии Интернета. Следовательно, опция метки времени не нужна для большинства пользователей. Рис. 4.16. показывает формат опции метки времени.
На этом рисунке определены поля кода и длины — те же самые, что прежде. Поле перегрузки записывает номера маршрутизаторов, которые не смогли добавить их метку времени, потому что не было больше доступного поля. Поле флажков задает посещенные маршрутизаторы. Если значение флажка — 0, каждый маршрутизатор добавляет только метку времени в предоставленном поле.
(рис 4.16) Опция метки времени
Если значение флажка — 1, каждый маршрутизатор должен добавить его исходящий адрес IP и метку времени. Если значение — 3, даются адреса IP, и каждый маршрутизатор должен сверить данный адрес IP с его собственным исходящим адресом IP. Если есть соответствие, маршрутизатор записывает поверх адреса IP его исходящий адрес IP и добавляет метку времени (рис. 4.17).
(рис 4.17) Использование флагов в метках времени
Рис. 4.17. показывает действия, предпринимаемые каждым маршрутизатором, когда дейтаграмма проходит от источника до пункта назначения. Рисунок предполагает значение флажка, равное 1.
Пример 10
Какие опции из шести вышеописанных должны быть скопированы каждым фрагментом?
Решение
Посмотрим первые (старшие слева) биты кодов каждой опции.
00000001; не копирует.00000000; не копирует.00000111; не копирует.10001001; копирует каждый фрагмент.10001011; копирует каждый фрагмент.01000100; не копирует.Пример 11
Какие шесть опций используются для управления дейтаграммой и какие — для отладки и административного управления?
Решение
Рассмотрим вторые и третьи биты кода (старшие слева).
00000001; управление дейтаграммой.00000000; управление дейтаграммой.00000111; управление дейтаграммой.10001001; управление дейтаграммой.10001011; управление дейтаграммой.01000100;отладка и административное управление.Метод обнаружения ошибок, используемый в соответствии с большинством протоколов TCP/IP, назван контрольной суммой. Контрольная сумма защищает от искажений, которые могут возникнуть в течение передачи пакета (то есть от избыточной информации, которая добавляется к пакету).
Контрольная сумма вычисляется в передатчике, и полученное значение посылается с пакетом. Приемник повторяет те же самые вычисления всего пакета, включая контрольную сумму. Если результат вычисления удовлетворителен (см. ниже), то пакет принимается; в противном случае он отклоняется.
В передатчике пакет разделяется на n-битовые секции (n обычно 16). Эти секции складываются вместе, используя арифметику с инверсным кодом. Эта сумма затем складывается и инвертируется (все нули изменяются на единицы, все единицы на нули), чтобы получить контрольную сумму.
Приемник разделяет полученный пакет на k секций и складывает все секции. Затем он инвертирует результат. Если конечный результат равен нулю, пакет принимается; в противном случае он отклоняется.
Реализация контрольной суммы в IP-пакете следует тем же самым принципам, которые обсуждались выше. Сначала значение поля контрольной суммы устанавливается в 0. Затем заголовок разбивается на 16-битные числа. Эти числа складываются. Если в результате получилось число на более, чем 16 бит - оно тоже разбивается на два 16-битных числа; суммируем их. Полученное число переписываем в бинарном виде и инвертируем (ноль - в единицу, единицу - в ноль). Результат записывает в поле "Контрольная сумма".
Контрольная сумма в IP-пакете защищает заголовок, но не данные. Для этого имеются две причины. Первая: все протоколы высокого уровня, которые инкапсулируют данные в IP-дейтаграмму, имеют контрольную сумму, которая покрывает весь пакет. Поэтому контрольная сумма для IP-дейтаграммы не может проверять инкапсулированные данные. Вторая причина: заголовок IP изменяется в каждом маршрутизаторе, который он посещает, а данные этого не делают. Таким образом, контрольная сумма включает в себя только изменения части, которая меняется. Если разрешить контрольной сумме проверять данные, каждый маршрутизатор должен пересчитать контрольную сумму для всего пакета, что означает увеличение времени обработки для каждого маршрутизатора.
Пояснения для подсчета контрольной суммы оставляем для практических занятий.
В этом разделе представлен простой пример блок-схемы IP. Наша цель — продемонстрировать отношения между различными частями, обсужденными в этой лекции. Рис. 4.18. показывает эти восемь компонентов и их взаимодействие.
Хотя IP поддерживает несколько опций, которые были изложены выше, в блок-схеме их обработка не рассмотрена, чтобы упростить понимание.
Мы можем сказать, что блок-схема IP содержит восемь компонентов:
Кроме того, блок-схема включает в себя исходящие и входящие очереди.
Блок-схема получает пакет либо от звена данных, либо от протокола высокого уровня. Когда пакет поступает от протокола высокого уровня, он доставляется к уровню звена данных для передачи (если это не адрес обратной тестовой петли 127.X.Y.Z). Когда пакет поступает от уровня звена данных, он доставляется либо к уровню звена данных для дальнейшего продвижения (в маршрутизатор), либо на верхний уровень протокола (если этот IP-адрес конечного пункта пакета — такой же как и адрес станции).
(рис 4.18) IP компоненты
Модуль, дополняющий заголовок, получает данные от протокола верхнего уровня наряду с адресом конечного пункта. Он инкапсулирует данные в IP-дейтаграмму, дополняя IP-заголовком (рис. 4.19).
(рис 4.19) Алгоритм модуля дополняющего заголовок
Модуль обработки – центральный в совокупности модулей IP (алгоритм рис. 4.20). Обрабатывающий модуль получает дейтаграмму от интерфейса или от модуля, дополняющего заголовок. В обоих случаях их обрабатывают одинаково. Дейтаграмма должна быть обработана и маршрутизирована независимо от того, откуда она прибыла.
(рис 4.20) Алгоритм модуля обработки
Модуль обработки сначала осуществляет проверку, чтобы определить, является дейтаграмма пакетом тестовой обратной связи с адресом конечного пункта 127.X.Y.Z или пакетом, который достиг своего конечного пункта. В любом случае, пакет посылают модулю реассемблирования.
Если модуль – это маршрутизатор, он уменьшает поле времени жизни (TTL — time to live) на единицу. Если значение поля меньше или равно нулю, дейтаграмма отклоняется и посылается сообщение системы управления Интернета (ICMP) на начальную станцию. Если значение TTL после уменьшения больше чем нуль, обрабатывающий модуль посылает дейтаграмму к модулю-маршрутизатору.
Наше пакетирование использует два типа очередей: исходящие очереди и входящие очереди. Исходящие очереди накапливают дейтаграммы, приходящие от уровня звена данных или протоколов высшего уровня. Входящие очереди накапливают дейтаграммы, идущие к уровню звена данных или протоколов высшего уровня. Модуль обработки выбирает дейтаграммы из исходящих очередей. Модули фрагментации и ассемблирования добавляют дейтаграммы во входящие очереди.
Таблица маршрутизации используется модулем маршрутизации для определения адреса следующего участка пакета.
Модуль маршрутизации получает IP-пакет от модуля обработки. Если пакет передается дальше, то это делает этот модуль. Модуль находит IP-адрес следующей станции в соответствии с номером, который должен быть послан в пакете. Затем он посылает пакет с этой информацией в модуль фрагментации.
В нашей блок-схеме модуль фрагментации (рис. 4.21). получает IP-дейтаграммы от модуля маршрутизации. Модуль маршрутизации пересылает: IP-дейтаграмму, IP-адрес следующей станции (либо конечный пункт назначения для прямой доставки, либо следующий маршрутизатор для непрямой доставки) и номер интерфейса, с помощью которого дейтаграмма будет выслана.
(рис 4.21) Алгоритм модуля фрагментации
Таблица
Модуль фрагментации обращается к таблице
Таблица реассемблирования используется модулем реассемблирования. В нашем пакетировании таблица реассемблирования имеет пять полей: состояние, адрес источника, IP-дейтаграммы, отсчет времени, ID-дейтаграммы и фрагменты (рис. 4.22).
(рис 4.22) Таблица реассемблирования
Значение поля состояние может быть одним из двух: FREE (СВОБОДНО) или IN_USE (в использовании). Поле IP-адреса определяет IP-адреса источника дейтаграммы и все фрагменты, принадлежащие этой дейтаграмме. Отсчет времени – заранее определенное количество времени, в которое каждый фрагмент должен прибыть. В заключение определим: поле "фрагменты" — это указатель списка связи фрагментов.
Модуль реассемблирования принимает от модуля обработки те фрагменты, которые прибывают на их конечный пункт. В нашем пакетировании модуль реассемблирования обращается с не фрагментированными дейтаграммами как с фрагментированными, принадлежащими дейтаграмме только с одним фрагментом.
Поскольку IP — протокол без коммутации, нет гарантий, что фрагменты прибывают в порядке. С другой стороны, фрагменты одной дейтаграммы могут быть перемешаны с фрагментами от других дейтаграмм. Для того чтобы зафиксировать такую ситуацию, модуль использует таблицу реассемблирования с вспомогательной таблицей связей, как мы это описывали ранее.
Задача модуля реассемблирования — найти дейтаграмму, которой принадлежат по порядку все фрагменты одной и той же дейтаграммы, и реассемблировать все фрагменты, когда они все прибудут. Если истекает установленный отсчет времени и некоторый фрагмент не соответствует порядку следования, модуль отклоняет фрагмент.
45 00 00 54 00 03 00 00 20 06 00 00 7C 4E 03 02 B4 0E 0F 02
Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.
Основным протоколом сетевого уровня является протокол Интернета (IP), которым пользуется IP-модуль для коммутации (перемещения) пакета с одного интерфейса на другой.
Протокол Интернета (Internet Protocol — IP) — это механизм передачи, используемый протоколами TCP/IP.
IP-протокол передачи дейтаграмм, не обеспечивающий надежность и не ориентированный на соединение, обслуживает передачу с наилучшими из возможных показателей (наилучшими намерениями — best
IP также протокол без установления соединения. Он передает пакет коммутируемой сети, используя метод дейтаграмм. Это означает, что каждая дейтаграмма обрабатывается независимо, и каждая дейтаграмма следует разными маршрутами к конечному пункту. Поэтому дейтаграммы, переданные одним и тем же источником к одному и тому же оконечному пункту, могут поступать не по порядку, также некоторые из них могут быть потеряны или искажены во время передачи. IP полагается на протокол более высокого уровня для того, чтобы решить все эти проблемы.
Протокол Интернета версии 4 (Internet Protocol, IPv4) решает две базовые функции: адресацию и фрагментацию. Маршрутизацию пакета модуль IP осуществляет по адресу, расположенному в заголовке пакета. Там же имеется информация о способе фрагментации / сборки дейтаграмм, если максимальная длина сетевого пакета (Maximum
Пакеты на уровне IP называются дейтаграммами. Рис. 4.1 а а показывает формат IP-дейтаграммы.
(рис 4.1) IP дейтаграмма
Дейтаграмма — пакет переменной длины (рис. 4.1 а) состоит из двух частей: заголовка и данных. Заголовок имеет от 20 до 60 байт длины и содержит существенную информацию для маршрутизации и доставки. Обыкновенно в TCP/IP заголовок содержит в себе четыре секции. Краткое описание каждого поля заголовка дано ниже.
0100). Однако версия 6 может полностью заменить версию 4 через несколько лет. Поле Обе интерпретации показаны на рис. 4.2 а Рассмотрим каждую из них.
(рис 4.2) Тип сервиса и различные услуги
000 в двоичном представлении) до 7 (111 в двоичном представлении). Поле категории срочности определяет приоритет дейтаграммы при перегрузках. Если маршрутизатор перегружен и должен удалить некоторые дейтаграммы, то первыми будут удалены дейтаграммы с самой низкой категорией срочности. Некоторые дейтаграммы в Интернете более важны, чем другие. Например, дейтаграмма, используемая для управления сетью, намного более срочная и важная, чем дейтаграмма, содержащая дополнительную информацию для группы. В настоящее время подполе категории срочности не используется. Это, как ожидается, будет функционировать в будущих версиях.| Биты типа обслуживания | Описание |
|---|---|
0000 |
Нормально (по умолчанию) |
0001 |
Минимизация стоимости |
0010 |
Максимизация надежности |
0100 |
Максимизация пропускной способности |
1000 |
Минимизация задержки |
Прикладные программы могут запросить специальный тип услуг. Тогда биты типа обслуживания устанавливаются по умолчанию. Значения по умолчанию для некоторых приложений показаны в табл. 4.2.
| Протокол | Биты обслуживания | Описание |
|---|---|---|
| ICMP | 0000 | Нормально |
| 0000 | Нормально | |
| 0001 | Минимизация стоимости | |
| 0010 | Максимизация надежности | |
| SNMP | 0010 | Максимизация надежности |
| TELNET | 1000 | Минимизация задержки |
| FTP (данные) | 0100 | Минимизация задержки |
| FTP (управление) | 1000 | Минимизация задержки |
| TFTP | 1000 | Максимизация пропускной способности |
| SMTP (команда) | 1000 | Минимизация задержки |
| DNS (UDP-запрос) | 0100 | Нормально |
| DNS (TCP-запрос) | 000 | Нормально |
| DNS (Зона) | 0100 | Максимизация пропускной способности |
Из приведенных выше таблиц ясно, что интерактивные действия, такие как запрос, требуют немедленного внимания, а действия, запрашивающие немедленный отклик, требуют минимальной задержки. Те действия, которые связаны с передачей большого объема данных, требуют максимальной пропускной способности по всему соединению. Действия по управлению нуждаются в максимальной надежности. Основные действия нуждаются в минимальной стоимости.
В этой трактовке (рис.4.2.б) первые 6 битов компонуют кодовую комбинацию подполя, а последние два бита не используются. Кодовая комбинация подполя может применяться двумя различными способами:
| Категория | Кодовая комбинация | Назначенные полномочия |
|---|---|---|
| 1 | XXXX0 | Интернет |
| 2 | XXX11 | Местные |
| 3 | XXX01 | Временные и экспериментальные |
Продолжим рассмотрение полей IP-дейтаграммы.
Длина данных = полная длина – длина заголовка.
Так как длина поля — 16 битов, полная длина дейтаграммы IP ограничена 65 535 (216 – 1) байтами, из которых 20-60 байтов являются заголовком, а остальные — данные верхнего уровня.
Хотя размер 65 535 байтов мог бы казаться большим, размер дейтаграммы IP может увеличиться в ближайшем будущем, поскольку основные технологии позволяют даже большую производительность (большую пропускную способность).
Когда мы обсудим в следующем разделе фрагментацию, мы увидим, что некоторые физические сети не способны инкапсулировать в своих кадрах дейтаграмму 65 535 байтов.
Чтобы пройти через эти сети, дейтаграмма должна быть фрагментирована. Когда устройство обработки информации или коммутатор (маршрутизатор или хост) получает кадр, он отбрасывает этот заголовок и окончание, оставляя дейтаграмму. Почему в формат включают дополнительное поле, которое не является необходимым? Во многих случаях мы действительно не нуждаемся в этом поле. Однако есть случаи, в которых дейтаграмма — не единственная вещь, которая инкапсулирована в кадр; она может быть дополнена заполнением. Например, протокол локальной сети на основе протокола Ethernet имеет минимальное и максимальное ограничение на размер данных, которые могут быть инкапсулированы в кадре (46-1500 байтов). Если размер дейтаграммы IP меньше чем 46 байтов, будет добавляться некоторое заполнение, чтобы выполнить это требование, и в этом случае, когда устройство извлечет дейтаграмму, оно должно проверить полное поле длины, чтобы определить, какая информация является действительно данными и какая — заполнением (рис. 4.3).
(рис 4.3) Инкапсуляция небольшой дейтаграммы в кадр EthernetДругое использование этого поля должно преднамеренно ограничить прохождение пакета. Например, если источник хочет ограничить пакет в местной сети, он может хранить 1 в этом поле. Когда пакет достигает первого маршрутизатора, это значение уменьшается до 0, и дейтаграмма удаляется.
(рис 4.4) Мультиплексирование данных с различными протоколами
Числовые обозначения различных протоколов приведены в табл. 4.4.
| Значение | Протокол |
|---|---|
| 1 | ICMP |
| 2 | |
| 6 | TCP |
| 17 | UDP |
| 89 | OSPF |
Поля – идентификация, флажки, смещение фрагментации — обсуждаются в следующем разделе.
Пример 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), что означает, что протокол верхнего уровня —
Дейтаграмма может проходить через различные сети. Каждый маршрутизатор извлекает дейтаграмму IP из кадра, получает его, обрабатывает и затем инкапсулирует в другом кадре. Формат и размер полученного кадра зависят от протокола, используемого физической сетью, через которую кадр только что проходил. Формат и размер посланного кадра зависят от протокола, применяемого физической сетью, через которую кадр собирается проходить. Например, если маршрутизатор подключает сеть Ethernet к сети Token Ring ("Кольцевая сеть с маркерным доступом"), он получает кадр в формате Ethernet и посылает кадр в формате Token Ring (см. "
Каждый протокол уровня звена передачи данных имеет свой собственный формат кадра. Одно из полей, определенных в формате – это максимальный размер поля данных. Другими словами, когда дейтаграмма инкапсулируется в кадр, полный размер дейтаграммы должен быть меньше, чем максимальный размер кадра, который определен ограничениями аппаратных и программных средств, используемых в сети (рис. 4.5).
(рис 4.5) Максимальный модуль передачи
Значение
В части функционирования IP-поток не зависит от физической сети. При создании пакетов стараются сделать так, чтобы добиться максимальной длины IP-дейтаграммы, равной максимальной
| Протокол | |
|---|---|
| Hyperchannel | 65 535 |
| Token Ring (16 Мбит/с) | 17 914 |
| Token Ring (4 Мбит/с) | 4 484 |
| FDDI | 4 352 |
| Ethernet | 1500 |
| X.25 | 576 |
| PPP | 296 |
Это делает передачу более эффективной, если мы используем протокол, позволяющий такой максимальный размер модуля передачи. Однако для другой физической сети необходимо разделить дейтаграмму, чтобы сделать возможным передачу через эту сеть. Это разделение называется фрагментацией.
Когда дейтаграмма фрагментируется, каждый фрагмент имеет собственный заголовок с большинством повторяющихся полей, но некоторые из них изменяются. Фрагментированная дейтаграмма может быть фрагментирована, если она сталкивается с сетью, которая имеет еще более мелкие
Дейтаграмма может быть фрагментирована хостом источника или любым маршрутизатором на пути следования. Однако собирается (реассемблируется) дейтаграмма только пунктом конечного назначения, потому что каждый фрагмент поступает в независимой дейтаграмме. Фрагментированная дейтаграмма может проходить через различные маршрутизаторы, и невозможно ни управлять ей, ни гарантировать, какой маршрут она может выбрать. Все фрагменты, принадлежащие одной и той же дейтаграмме, должны в конечном итоге прибывать в хост пункта назначения. Такова логика реассемблирования в конечном пункте назначения.
Когда дейтаграмма фрагментирована, требуемые части заголовка должны быть скопированы всеми фрагментами. Поле опции может или не может быть скопировано, как увидим в следующем разделе. Хост или маршрутизатор, который фрагментирует дейтаграмму, должны изменить значения трех полей: флажки, смещение фрагментации и полная длина. Остальная часть полей должна быть скопирована. Конечно, значение контрольной суммы должно быть повторно вычислено независимо от фрагментации.
Поля, которые связаны с фрагментацией и повторной сборкой IP-дейтаграммы — это (см. рис. 4.1):
(рис 4.6) Пример фрагментации
Помните, что значение смещения измерено в единицах 8 байт. Это сделано, потому что длина поля смещения составляет только 13 битов и не может представить последовательность байтов больше, чем 8191. Это вынуждает хосты или маршрутизаторы, которые фрагментируют дейтаграммы, выбрать размер каждого фрагмента так, чтобы номер первого байта делился на 8.
Рис. 4.7. показывает расширенный вид фрагментов предыдущего рисунка. Заметим, что значение поля идентификации — одно и то же во всех фрагментах. Также заметим, что значение поля флажков установлено с третьим битом флага, равным 1 для всех фрагментов, кроме последнего. Также показано значение поля смещения для каждого фрагмента.
(рис 4.7) Детальный пример фрагментации
Рисунок показывает, что получается, если фрагментирован сам фрагмент. В таком случае значение поля смещения всегда дается относительно первоначальной дейтаграммы. Например, на рисунке второй фрагмент сам фрагментирован на два фрагмента — 800 байтов и 600 байтов, но смещение показано относительно позиции фрагментов первоначальных данных.
Очевидно, что, даже если каждый фрагмент следует различным путем и прибывает в неисправном состоянии, заключительный хост пункта назначения может повторно собрать первоначальную дейтаграмму из полученных фрагментов (если ни один из них не потерян), используя следующую стратегию:
Пример 5
Пакет прибывает со значением бита M = 0. Это первый фрагмент, последний фрагмент или средний фрагмент? Можно ли узнать, был ли пакет фрагментирован?
Решение
Если бит M = 0, это означает, что далее нет фрагментов; этот фрагмент — последняя единица. Однако мы не можем сказать, был ли пакет фрагментирован или нет. Не фрагментированный пакет считается последним фрагментом.
Пример 6
Пакет прибывает со значением бита M = 1. Является ли этот пакет первым фрагментом, последним фрагментом или средним фрагментом? Можно ли узнать, был ли пакет фрагментирован?
Решение
Если бит M = 1, это означает, что имеется, по крайней мере, дальнейший фрагмент. Фрагмент может быть первой и средней единицей, но не последней. Мы не знаем, первая это единица или средняя; нам нужна дальнейшая информация — значение смещения фрагмента. Однако мы можем определенно сказать, что M = 1.
Пример 7
Пакет прибывает со значением бита M = 1, смещение фрагментации имеет значение 0. Является ли этот пакет первым фрагментом, последним фрагментом или средним фрагментом?
Решение
Поскольку M = 1, это или первый, или средний фрагмент. Поскольку смещение фрагмента равно 0 – это первый фрагмент.
Пример 8
Прибывает пакет, в котором значение смещения – 100. Каков номер первого байта? Знаем ли мы номер последнего байта?
Решение
Для того чтобы найти номер первого байта, мы умножаем значение смещения на 8. Это означает, что номер первого байта 800. Мы не можем опередить номер последнего байта, если мы не знаем длину данных.
Пример 9
Прибывает пакет, в котором значение смещения – 100, значение HLEN – 5 и значение поля полной длины – 100. Каковы номера первого байта и последнего байта?
Решение
Номер первого байта 100 * 8 = 800. Полная длина 100 байт и длина заголовка 20 байт (5 x 4), которая означает, что в этой дейтаграмме имеется 80 байт. Если номер первого байта 800, последний номер должен быть 879.
Заголовок дейтаграммы IP состоит из двух частей: фиксированная часть и переменная часть. Фиксированная часть имеет 20 байтов длины, мы обсуждали ее в предыдущем разделе. Переменная часть включает опции, которые могут быть максимально 40 байт. Опции не требуются для каждой дейтаграммы. Они используются для испытания сети и отладки. Хотя опции — не обязательная часть заголовка IP, обработка опции требует программного обеспечения IP. Это означает, что все применяемые средства должны быть способны обработать опции, если они окажутся в заголовке.
Рис. 4.8. показывает формат опции. Он составлен из 1-байтового поля кода, 1-байтового поля длины и поля данных переменного размера.
(рис 4.8) Формат опции
Код
Длина
Поле длины определяет полную длину опции, включая поле кода и длину самого поля. Это поле не входит в некоторые типы опций.
Данные
Поле "данные" содержит данные, которые задают требуемые опциям. Это поля не входит в некоторые типы опций.
Как раньше было упомянуто, в настоящее время используются шесть опций. Две из них — 1-байтные, и они не требуют полей длины или данных. Четыре из них — многобайтные опции; они требуют полей длины и данных (рис. 4.9).
(рис 4.9) Категории опций
Опция нет оператора — однобайтовая опция, используемая как наполнитель между опциями. Например, она может использоваться для того, чтобы выровнять следующую к границе опцию на 32 бита или 16 бит (рис. 4.10).
(рис 4.10) Опция "нет операции"
"Конец опции" — также однобайтовая опция, используемая для того, чтобы дополнить конец поля опции. Однако он может использоваться только как последняя опция. Только один конец опции может использоваться опцией. После этой опции приемник ищет данные полезной нагрузки. Это означает, что, если необходим больше чем 1 байт, чтобы выровнять поле опции, некоторые опции "нет оператора" не должны быть использованы вслед за "концом опции" (рис. 4.11).
(рис 4.11) Опция "конец опции"
Опция запись полного маршрута (Record Route) имеет тип опции 7 и предписывает маршрутизатору записывать все IP-адреса, через которые проходит маршрут следования пакета. Во избежание нехватки длины поля о данных маршрута ее следует выбирать достаточно большой, в противном случае соответствующий маршрутизатор генерирует исходящему узлу сообщение об ошибке. Запись маршрута может содержать список до девяти адресов IP-маршрутизатора, в то же время максимальный размер заголовка — 60 байтов, которые должны включать в себя 20 байтов для основного заголовка. Это подразумевает, что только 40 байтов оставляют для части "опция". Источник создает незаполненные места в опции — она будет заполнена маршрутизаторами, которые прошла дейтаграмма. Рис. 4.12 показывает формат опции "запись маршрута".
И код и поля длины были описаны выше. Поле указателя — поле смещения, целое число, содержащее номера байта первого пустого входа. Другими словами, он указывает на первый доступный вход.
(рис 4.12) Опция "запись маршрута"
Источник создает пустые поля для адресов IP в поле данных опции. Когда дейтаграмма оставляет источник, все поля пусты. Поле указателя имеет значение 4, указывая на первое пустое поле. Поэтому при переходе от маршрутизатора к маршрутизатору указатель длины меняется на 4. Когда дейтаграмма перемещается, каждый маршрутизатор, который обрабатывает дейтаграмму, сравнивает значение указателя со значением длины. Если значение указателя больше, чем значение длины, опция полна, и никакие изменения не делаются.
Однако если значение указателя не больше, чем значение длины, маршрутизатор вставляет свой исходящий адрес IP в следующее пустое поле. Напомним, что маршрутизатор может иметь несколько адресов. В данном случае он имеет входящий и исходящий адрес. В этом случае маршрутизатор добавляет адрес IP своего исходящего интерфейса, т. е. того, который дейтаграмма покидает. Маршрутизатор затем увеличивает значение указателя 4. Рис. 4.13. показывает, как перемещается дейтаграмма слева направо от маршрутизатора к маршрутизатору.
(рис 4.13) Концепция записи маршрута
Опция свободная маршрутизация (Loose Source and Record Route – LSRR) имеет тип опции 131 и разрешает маршрутизатору использовать любой из альтернативных маршрутов для достижения очередного адреса назначения из данных маршрута. Если адрес назначения (
Опция строгая маршрутизация от источника(Strict Source and Record Route – SSRR) имеет тип опции 137 и предписывает маршрутизатору использовать только смежные маршрутизаторы для достижения очередного адреса из данных маршрута. Она применяется источником, чтобы предопределить маршрут для дейтаграммы, как он проходит через Интернет. Задание маршрута источником может быть полезно с точки зрения нескольких целей. Отправитель может выбрать маршрут с определенным типом обслуживания, например, с минимальной задержкой или максимальной производительностью. Альтернативно, она может выбрать маршрут, который более безопасен или более достоверен для целей отправителя — например так, чтобы дейтаграмма не проходила через сеть конкурента.
Если дейтаграмма задает строгую маршрутизацию от источника, все маршрутизаторы, определенные в опции, должны быть пройдены дейтаграммой. Маршрутизатор не должен быть пройден, если его адрес IP не содержится в списке дейтаграммы. Если дейтаграмма проходит маршрутизатор, который не находится в списке, дейтаграмма отклоняется и создается сообщение об ошибках. Если дейтаграмма достигает пункта назначения и некоторые из адресов не были использованы, она будет также отклонена и создано сообщение об ошибках.
Однако непривилегированные пользователи обычно не знают о физической топологии Интернета. Следовательно, строгая исходная маршрутизация не является опцией большинства пользователей.
Формат подобен опции "записи маршрута", за исключением того, что все адреса IP введены отправителем.
Когда дейтаграмма проходит по сети каждый маршрутизатор, который обрабатывает дейтаграмму, сравнивает значение указателя со значением длины. Если значение указателя больше, чем значение длины, — дейтаграмма посетила все предопределенные маршрутизаторы. Тогда она не может больше перемещаться; она будет отклонена, и создается сообщение об ошибках. Если значение указателя не больше, чем значение длины, маршрутизатор сравнивает адрес IP указанный в сообщении с его входящим адресом IP. Если они равны, он обрабатывает дейтаграмму, записывает поверх текущего адреса IP его исходящий адрес IP, увеличивает значение указателя 4 и передает дейтаграмму вперед. Если они не равны, он удаляет дейтаграмму и создает сообщение об ошибках. Рис. 4.14. показывает действия, предпринимаемые каждым маршрутизатором, пока дейтаграмма перемещается от источника до пункта назначения.
(рис 4.14) Концепция "строгая маршрутизация от источника" маршрута
Опция несвязанная маршрутизация от источника — смягченная версия строгой маршрутизации от источника. Согласно ей дейтаграмма должна пройти каждый маршрутизатор в списке, но может также посетить другие маршрутизаторы.
Перечисленные опции используются администраторами сетей для проверки работоспособности определенных маршрутов. На рис. 4.15. показано применение этой опции для тестового петлевого соединения по маршруту: сеть A – сеть B – сеть C – сеть D – сеть A через промежуточную сеть B. Результирующее поле данных маршрута содержит информацию обо всех IP-адресах в порядке их прохождения.
(рис 4.15) Обработка полей в опции свободная маршрутизация — LSRR
Опция метки времени используется, чтобы сделать запись времени обработки дейтаграммы маршрутизатором. Время выражено в миллисекундах, отсчет ведется с полуночи – так называемое Универсальное время. Обработка значения времени дейтаграммы может помочь пользователям и менеджерам проследить поведение маршрутизаторов в Интернете. Мы можем оценить время, которое требуется для дейтаграммы, чтобы пройти от одного маршрутизатора к другому. Мы говорим "оценка", потому что, хотя все маршрутизаторы могут использовать Универсальное время, их местные часы могут быть не синхронизированы.
Однако непривилегированные пользователи обычно не знают о физической топологии Интернета. Следовательно, опция метки времени не нужна для большинства пользователей. Рис. 4.16. показывает формат опции метки времени.
На этом рисунке определены поля кода и длины — те же самые, что прежде. Поле перегрузки записывает номера маршрутизаторов, которые не смогли добавить их метку времени, потому что не было больше доступного поля. Поле флажков задает посещенные маршрутизаторы. Если значение флажка — 0, каждый маршрутизатор добавляет только метку времени в предоставленном поле.
(рис 4.16) Опция метки времени
Если значение флажка — 1, каждый маршрутизатор должен добавить его исходящий адрес IP и метку времени. Если значение — 3, даются адреса IP, и каждый маршрутизатор должен сверить данный адрес IP с его собственным исходящим адресом IP. Если есть соответствие, маршрутизатор записывает поверх адреса IP его исходящий адрес IP и добавляет метку времени (рис. 4.17).
(рис 4.17) Использование флагов в метках времени
Рис. 4.17. показывает действия, предпринимаемые каждым маршрутизатором, когда дейтаграмма проходит от источника до пункта назначения. Рисунок предполагает значение флажка, равное 1.
Пример 10
Какие опции из шести вышеописанных должны быть скопированы каждым фрагментом?
Решение
Посмотрим первые (старшие слева) биты кодов каждой опции.
00000001; не копирует.00000000; не копирует.00000111; не копирует.10001001; копирует каждый фрагмент.10001011; копирует каждый фрагмент.01000100; не копирует.Пример 11
Какие шесть опций используются для управления дейтаграммой и какие — для отладки и административного управления?
Решение
Рассмотрим вторые и третьи биты кода (старшие слева).
00000001; управление дейтаграммой.00000000; управление дейтаграммой.00000111; управление дейтаграммой.10001001; управление дейтаграммой.10001011; управление дейтаграммой.01000100;отладка и административное управление.Метод обнаружения ошибок, используемый в соответствии с большинством протоколов TCP/IP, назван контрольной суммой. Контрольная сумма защищает от искажений, которые могут возникнуть в течение передачи пакета (то есть от избыточной информации, которая добавляется к пакету).
Контрольная сумма вычисляется в передатчике, и полученное значение посылается с пакетом. Приемник повторяет те же самые вычисления всего пакета, включая контрольную сумму. Если результат вычисления удовлетворителен (см. ниже), то пакет принимается; в противном случае он отклоняется.
В передатчике пакет разделяется на n-битовые секции (n обычно 16). Эти секции складываются вместе, используя арифметику с инверсным кодом. Эта сумма затем складывается и инвертируется (все нули изменяются на единицы, все единицы на нули), чтобы получить контрольную сумму.
Приемник разделяет полученный пакет на k секций и складывает все секции. Затем он инвертирует результат. Если конечный результат равен нулю, пакет принимается; в противном случае он отклоняется.
Реализация контрольной суммы в IP-пакете следует тем же самым принципам, которые обсуждались выше. Сначала значение поля контрольной суммы устанавливается в 0. Затем заголовок разбивается на 16-битные числа. Эти числа складываются. Если в результате получилось число на более, чем 16 бит - оно тоже разбивается на два 16-битных числа; суммируем их. Полученное число переписываем в бинарном виде и инвертируем (ноль - в единицу, единицу - в ноль). Результат записывает в поле "Контрольная сумма".
Контрольная сумма в IP-пакете защищает заголовок, но не данные. Для этого имеются две причины. Первая: все протоколы высокого уровня, которые инкапсулируют данные в IP-дейтаграмму, имеют контрольную сумму, которая покрывает весь пакет. Поэтому контрольная сумма для IP-дейтаграммы не может проверять инкапсулированные данные. Вторая причина: заголовок IP изменяется в каждом маршрутизаторе, который он посещает, а данные этого не делают. Таким образом, контрольная сумма включает в себя только изменения части, которая меняется. Если разрешить контрольной сумме проверять данные, каждый маршрутизатор должен пересчитать контрольную сумму для всего пакета, что означает увеличение времени обработки для каждого маршрутизатора.
Пояснения для подсчета контрольной суммы оставляем для практических занятий.
В этом разделе представлен простой пример блок-схемы IP. Наша цель — продемонстрировать отношения между различными частями, обсужденными в этой лекции. Рис. 4.18. показывает эти восемь компонентов и их взаимодействие.
Хотя IP поддерживает несколько опций, которые были изложены выше, в блок-схеме их обработка не рассмотрена, чтобы упростить понимание.
Мы можем сказать, что блок-схема IP содержит восемь компонентов:
Кроме того, блок-схема включает в себя исходящие и входящие очереди.
Блок-схема получает пакет либо от звена данных, либо от протокола высокого уровня. Когда пакет поступает от протокола высокого уровня, он доставляется к уровню звена данных для передачи (если это не адрес обратной тестовой петли 127.X.Y.Z). Когда пакет поступает от уровня звена данных, он доставляется либо к уровню звена данных для дальнейшего продвижения (в маршрутизатор), либо на верхний уровень протокола (если этот IP-адрес конечного пункта пакета — такой же как и адрес станции).
(рис 4.18) IP компоненты
Модуль, дополняющий заголовок, получает данные от протокола верхнего уровня наряду с адресом конечного пункта. Он инкапсулирует данные в IP-дейтаграмму, дополняя IP-заголовком (рис. 4.19).
(рис 4.19) Алгоритм модуля дополняющего заголовок
Модуль обработки – центральный в совокупности модулей IP (алгоритм рис. 4.20). Обрабатывающий модуль получает дейтаграмму от интерфейса или от модуля, дополняющего заголовок. В обоих случаях их обрабатывают одинаково. Дейтаграмма должна быть обработана и маршрутизирована независимо от того, откуда она прибыла.
(рис 4.20) Алгоритм модуля обработки
Модуль обработки сначала осуществляет проверку, чтобы определить, является дейтаграмма пакетом тестовой обратной связи с адресом конечного пункта 127.X.Y.Z или пакетом, который достиг своего конечного пункта. В любом случае, пакет посылают модулю реассемблирования.
Если модуль – это маршрутизатор, он уменьшает поле времени жизни (TTL — time to live) на единицу. Если значение поля меньше или равно нулю, дейтаграмма отклоняется и посылается сообщение системы управления Интернета (ICMP) на начальную станцию. Если значение TTL после уменьшения больше чем нуль, обрабатывающий модуль посылает дейтаграмму к модулю-маршрутизатору.
Наше пакетирование использует два типа очередей: исходящие очереди и входящие очереди. Исходящие очереди накапливают дейтаграммы, приходящие от уровня звена данных или протоколов высшего уровня. Входящие очереди накапливают дейтаграммы, идущие к уровню звена данных или протоколов высшего уровня. Модуль обработки выбирает дейтаграммы из исходящих очередей. Модули фрагментации и ассемблирования добавляют дейтаграммы во входящие очереди.
Таблица маршрутизации используется модулем маршрутизации для определения адреса следующего участка пакета.
Модуль маршрутизации получает IP-пакет от модуля обработки. Если пакет передается дальше, то это делает этот модуль. Модуль находит IP-адрес следующей станции в соответствии с номером, который должен быть послан в пакете. Затем он посылает пакет с этой информацией в модуль фрагментации.
В нашей блок-схеме модуль фрагментации (рис. 4.21). получает IP-дейтаграммы от модуля маршрутизации. Модуль маршрутизации пересылает: IP-дейтаграмму, IP-адрес следующей станции (либо конечный пункт назначения для прямой доставки, либо следующий маршрутизатор для непрямой доставки) и номер интерфейса, с помощью которого дейтаграмма будет выслана.
(рис 4.21) Алгоритм модуля фрагментации
Таблица
Модуль фрагментации обращается к таблице
Таблица реассемблирования используется модулем реассемблирования. В нашем пакетировании таблица реассемблирования имеет пять полей: состояние, адрес источника, IP-дейтаграммы, отсчет времени, ID-дейтаграммы и фрагменты (рис. 4.22).
(рис 4.22) Таблица реассемблирования
Значение поля состояние может быть одним из двух: FREE (СВОБОДНО) или IN_USE (в использовании). Поле IP-адреса определяет IP-адреса источника дейтаграммы и все фрагменты, принадлежащие этой дейтаграмме. Отсчет времени – заранее определенное количество времени, в которое каждый фрагмент должен прибыть. В заключение определим: поле "фрагменты" — это указатель списка связи фрагментов.
Модуль реассемблирования принимает от модуля обработки те фрагменты, которые прибывают на их конечный пункт. В нашем пакетировании модуль реассемблирования обращается с не фрагментированными дейтаграммами как с фрагментированными, принадлежащими дейтаграмме только с одним фрагментом.
Поскольку IP — протокол без коммутации, нет гарантий, что фрагменты прибывают в порядке. С другой стороны, фрагменты одной дейтаграммы могут быть перемешаны с фрагментами от других дейтаграмм. Для того чтобы зафиксировать такую ситуацию, модуль использует таблицу реассемблирования с вспомогательной таблицей связей, как мы это описывали ранее.
Задача модуля реассемблирования — найти дейтаграмму, которой принадлежат по порядку все фрагменты одной и той же дейтаграммы, и реассемблировать все фрагменты, когда они все прибудут. Если истекает установленный отсчет времени и некоторый фрагмент не соответствует порядку следования, модуль отклоняет фрагмент.
45 00 00 54 00 03 00 00 20 06 00 00 7C 4E 03 02 B4 0E 0F 02
Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.