Глава 9 | «« Назад |  Оглавление |  Вперед »»

Межсетевой протокол управляющих сообщений (ICMP).

Для успешной передачи дейтаграмм между сетями необходим механизм диагностики состояния маршрута, при необходимости сообщающий о возникающих ошибках узлу-отправителю. Этой цели служит протокол обмена управляющими сообщениями ICMP. Самостоятельной роли он не играет, исправлять ошибки (или чем-то управлять) не может, более того, взаимодействие узлов может проходить и без использования этого протокола. Хотя некоторая функциональность связи без ICMP может быть потеряна. Например при неработающем MTU-Discovery (ICMP зафильтрован полностью) могут не проходить пакеты больше какого-либо количества байт.

Тем не менее, ICMP предназначен для диагностики, и использование его возможностей является серьезной помощью для устранения неисправностей.

Сразу надо отметить, что этот протокол не участвует в процессе обмена дейтаграммами IP, и присоединяется к обычному IP-заголовку, занимая место данных. Но это не мешает ICMP (как и большинству протоколов более высоких уровней) иметь свой заголовок (до 8 байтов), и сообщение (не имеет фиксированной длинны).

В общем, все сообщения ICMP можно разделить на парные, состоящие из двух компонентов, запрос (Request) и ответ (Reply), и непарные - только ответ, возникающий из-за проблемы в передаче.

Вот пример наиболее часто встречающиеся непарного сообщения:

Цель недоступна (Destination Unreachable). Формируется в случае, если запрошенный сетевой ресурс является недоступным для запрашивающей его станции. Например, Network Unreachable, Host Unreachable, Protocol Unreachable, и другие. Причем эти сообщения могут быть сформированы не только узлом назначения, но и промежуточным роутером. Например, в случае невозможности доставить сообщение узлу, последний доступный маршрутизатор выдает сообщение типа:

Ответ от 192.168.0.2: Заданный узел недоступен (Destination Host Unreachable)

В качестве распространенного примера парного сообщения можно привести Echo (эхо). Используются они для того, что бы определить принципиальную достижимость узла, или маршрут по ответу (Echo Reply), который должен быть сформирован в ответ на ICMP запрос (Echo Request).

Именно на этом механизме построена простая и широко применяемая для диагностики утилита ping, или traceroute. Более подробно способ их использования на практике будет описан в следующих главах.

В заключение этого раздела, хотелось бы отметить, что есть еще целый ряд протоколов, работающих на сетевом уровне модели OSI. С ростом уровня, резко расширяется функциональность протоколов. Даже полное описание возможностей относительно простого ICMP может занять больше места, чем эта глава. А это очень мало по сравнению, например, с RIP (протокол маршрутизации, выполняющий широковещательную рассылку таблиц маршрутизации), или OSPF (протокол выявления маршрутов маршрутизаци по состоянию связи).

Транспортный уровень.

Как следует из названия, протоколы транспортного уровня предназначены для непосредственного взаимодействия двух пользовательских процессов. При этом для передачи информации они используют описанные выше дейтаграммы IP, помещая свои сообщения в их поле данных.

В общем виде существует два типа протоколов транспортного уровня - сегментирующие (TCP, разбивают исходное сообщение на блоки), и не сегментирующие, или дейтаграммные (UDP, отправляют сообщение "как есть", одним куском). Разумеется, второй способ намного проще, но он не гарантирует доставки.

Не будет большой ошибкой сказать, что в реальной сети Интернет используются всего два транспортных протокола:

  • Протокол передачи пользовательских дейтаграмм (UDP User Datagram Protocol).
  • Протокол управления передачи (TCP Transmission Control Protocol).

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

Транспортный протокол UDP

Дейтаграммы UDP имеют переменную длину и состоят из заголовка сообщения, и собственно данных.

Таб. 7.7. Формат дейтаграммы UDP

Номер порта отправителя Номер порта получателя
Длина сообщения Контрольная сумма
Данные

Номер порта источника указывается только в том случае, если предполагается ответ. Минимальная длина дейтаграммы составляет 8 байт (размер заголовка).

Протокол UDP не обеспечивает гарантированной доставки сообщений. Поэтому, он может быть использован только для приложений, которые не нуждаются в этом качестве. Как пример можно привести передачу звука, или видео. Второй вариант использования UDP - приложения, которые обеспечивают доставку своими средствами. Например, всем известный Telnet и старые версии ICQ.

Транспортный протокол TCP

Этот протокол, пожалуй, более распространен, чем все остальные, вместе взятые. Он используется для гарантированной доставки сообщений (называемых пакетами) в сетях Интернет.

Таб. 7.8. Формат пакета TCP

Номер порта отправителя Номер порта получателя
Порядковый номер
Номер подтверждения
Смещение Резерв U A P R S F Окно
Контрольная сумма Указатель важности
Опции и заполнение
Данные

Заголовок пакета TCP состоит из нескольких (обычно 6) 32-х битных слов, и в этом похож на формат дейтаграммы IP. Поясним значение некоторых полей:

  • Порядковый номер первого октета в сегменте необходим для определения места пакета для сборки блока переданных данных после сегментации (если она была проведена перед передачей).
  • Номер подтверждения содержит значение следующего порядкового номера, который отправитель сегмента рассчитывает получить.
  • Смещение данных - 4-х битовое поле, указывающее число 32-х битовых слов в заголовке пакета, или начало поля данных.
  • Резерв - зарезервированное поле размером в 6 бит.
  • Поле флагов управления. U (URG) - значимое поле указателя важности, A (ACK) - значимое поле подтверждения, P (PSH) - функция push, R (RST) - сброс соединения, F (FIN) - нет данных от отправителя.
  • Окно, это 16-битовое поле, которое содержит число октетов данных, которые отправитель данного сегмента будет отправлять без немедленного подтверждения доставки. Отсчет ведется, начиная с октета, указанного в поле номер подтверждения.
  • Уровень важности - значение смещения до октета, с которого начинаются важные (urgent) данные. Разумеется, поле принимается во внимание только для пакетов с установленным флагом "U".

Различия в величине заголовка пакета TCP и дейтаграммы UDP сразу обращают на себя внимание. Объяснение кроется в сложности обеспечения гарантированной и эффективной доставки (да еще и с заданным уровнем качества). Для этого можно использовать метод квитирования с повторной передачей.

Несмотря на сложное название, его суть достаточно проста. При получении пакета узел назначения посылает отправителю специальный сигнал ACK (квитанцию). Узел, передавший пакет, в свою очередь, до получения подтверждения прекращает передачу. А в случае отсутствия "квитанции" в течение определенного времени, начинает передачу пакета заново. Несмотря на простоту, такой алгоритм имеет большой недостаток - пропускная способность сети передачи данных используется очень неэффективно. Как минимум, половину времени процессы ожидают получения подтверждения.

В связи с этим применяется более эффективный алгоритм квитирования с использованием "скользящего окна", при котором передающий узел отправляет сразу несколько пакетов, не дожидаясь получения подтверждения о приеме. Для определения максимального количества передающихся таким образом пакетов TCP применяют параметр "окно" в заголовке. Соответственно, узел, принимающий пакеты так же может обработать несколько "квитанций" за один раз.

При отсутствии ошибок и задержек передачи, получается что "окно" передаваемых пакетов непрерывно скользит вдоль входящего потока данных, эффективно загружая сеть.

От размера окна очень много зависит, но его выбор - не слишком тривиальная задача. На практике алгоритм пошел немного "от противного", не от максимальной скорости передачи. Каждое сообщение подтверждения доставки пакета содержит значение размера окна, которое может быть предоставлено принимающим узлом (window advertisement). Обычно, оно определяется размером свободного в данный момент буфера принимающего адаптера.

При этом достигается еще одна цель - становятся не нужными дополнительные механизмы, которые контролируют процесс переполнения. В каком-то плане, это можно рассматривать как довольно красивый (хотя и не полный) ответ сложным методам, применяемым для тех же целей (но на канальном уровне) в технологии АТМ.

Но для обеспечения передачи с заданным качеством одного механизма квитирования совершенно недостаточно. И существует еще достаточно широкий спектр способов повышения эффективности транспортных протоколов. Например, этому служит виртуальное логическое соединение, или TCP-сессия. Инициировать ее установление может один из узлов, а далее обе стороны контролируют качество, и при возникновении сложностей в информационном обмене, могут разорвать сессию с отправкой соответствующих сообщений протоколам более высокого уровня.

Кроме этого, может быть использован режим потокового обмена, механизм ускорения доставки трафика, чувствительного ко времени (push), и некоторые другие.

Чем более высокий уровень OSI используется, тем больше возможностей предоставляют протоколы для управления. Описать их все - большая, но отдельная задача. Поэтому, рассматривать сеансовый и более высокие уровни (или уровень приложений стека TCP/IP) в рамках данной главы не целесообразно. Разумеется, необходимые для работы простых сетей протоколы (такие как NetBios, DNS, FTP, Telnet, http) будут описаны в следующих главах.

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

Исходя из вышесказанного, на транспортном уровне описание модели OSI можно закончить, и рассматривать работу протоколов более высокого уровня на примере конкретных приложений.

Глава 9 | «« Назад |  Оглавление |  Вперед »»