6.2.5. Icmp-протокол обмена управляющей информацией

Функцию передачи специальных управляющих и диагностирующих сообщений в сетях TCP/IP выполняет Internet Control Message Protocol (ICMP), описание которого приведено в документе RFC 792. ICMP является протоколом сетевого уровня по выполняемым функциям и его сообщения инкапсулируются в IP-пакет. Сообщения ICMP генерируются и обрабатываются одноименными программными модулями, функционирующими на разных сетевых узлах. Когда в ходе обработки какого-либо пакета маршрутизатором или конечным узлом обнаруживается необходимость отправки сообщения ICMP, то единственным получателем такого сообщения будет узел-отправитель. Эти сообщения не используются для информирования промежуточных узлов, поскольку маршрут передачи IP-пакета c ICMP-сообщением не детерминирован и ценность этой информации для промежуточных узлов маршрута не гарантирована.

Протокол ICMP генерирует два вида сообщений: управляющие и сообщения об ошибках, но он не содержит никаких средств коррекции состояния узла; эта задача решается протоколами управления узла-отправителя, т.е. задача ICMP – доставить сигнал обратной связи.

Сообщения ICMP содержат три обязательных поля: «Тип», «Код» и «Контрольная сумма». Кроме этого, многие сообщений об ошибках включают в себя заголовок и первые 64 бита пакета, в котором была обнаружена ошибка. Это сделано для более точной идентификации узлом-отправителем причины ошибки. Поле «Тип» определяет содержание сообщения и его формат. В таблице 6.6. приведены некоторые его значения.

Таблица 6.6.

Тип	Содержание сообщения	Тип	Содержание сообщения
0	Ответ на эхо	11	Превышено время жизни пакета
3	Получатель недостижим	12	Ошибка параметров в пакете
4	Подавление источника	13-14	Запрос/Ответ метки времени
5	Изменение маршрута	17	Запрос маски адреса
8	Запрос эха	18	Ответ на запрос маски адреса

Сообщения «Запрос эха» и «Ответ на эхо» являются компонентами утилиты ping, широко используемой для диагностики работоспособности сетевых устройств. Поскольку как «Запрос эха», так и «Ответ на эхо» передаются в IP-пакетах, то успешный прием ответа свидетельствует о работоспособности основных компонентов сетевой транспортной системы, т.е. успешной маршрутизации, работоспособности IP-модулей на конечных станциях. На рис. 6.8. представлен формат этих сообщений.

Поля «Идентификатор» и «Порядковый номер» используются отправителем для установления соответствия между запросом и ответом. Так, в поле «Идентификатор» записывается системный идентификатор процесса, отправляющего запрос; значение этого поля копируется в такое же поле сообщения-ответа. Это позволяет ICMP-модулю верно интерпретировать адресат ответного сообщения в условиях, когда на одном и том же хосте одновременно могут выполняться несколько разных приложений (или несколько экземпляров одного приложения), способных порождать ICMP-запросы.

Поле «Порядковый номер» начинается с 0 и увеличивается на единицу каждый раз, когда посылается следующий запрос. Значение этого поля копируется в одноименное поле ответа, что позволяет установить связь между запросом и ответом, определить потерю какого-либо пакета из этой пары.

Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю.

Сообщение «Получатель недостижим» (Тип=3) генерируется маршрутизатором в ситуации, когда он не может доставить пакет по назначению. Его формат представлен на рис. 6.9.

Это сообщение содержит поле «Код», которое уточняет причину невозможности доставки пакета. Некоторые из кодов представлены в таблице 6.7.

Таблица 6.7

Код	Причины
0	Сеть недостижима
1	Устройство недостижимо
2	Протокол недостижим
3	Порт недостижим
4	Требуется фрагментация
5	Ошибка при маршрутизации от источника
6	Сеть назначения неизвестна
9	Взаимодействие с сетью назначения административно запрещено
11	Сеть недостижима из-за класса обслуживания (нет маршрута с требуемым TOS, или маршрута с TOS=000
12	Устройство недостижимо из-за класса обслуживания

Формат сообщения «Подавление источника» (Тип=4) аналогичен формату сообщения типа 3, но значение поля «Код» в нем всегда равно 0. Сообщение «Подавление источника» отправляется маршрутизатором хосту-отправителю в ответ на каждый, полученный в состоянии перегрузки маршрутизатора, пакет. Отправители этих пакетов, получая такие ICMP-сообщения, уменьшают интенсивность отправки очередных пакетов, что способствует устранению перегрузки.

Сообщение «Изменение маршрута» (Тип=5) отправляется маршрутизатором хосту-отправителю, находящемуся с ним в одной физической сети, для того, чтобы сообщить об использовании хостом неоптимального маршрута к узлу назначения. В сообщении (рис.6.10) указывается адрес маршрутизатора, использование которого является предпочтительным.

Рис. 6.10. Формат сообщения «Изменение маршрута»

Из поля «Заголовок IP- пакета…» узел узнает, для какой сети/узла необходимо направлять пакеты указанному маршрутизатору. Значения поля «Код» (0-3) уточняют условия применения рекомендуемого маршрута (0 – для всей сети, 1 – для данного хоста, 2 – для данной сети при заданном в IP-пакете требовании к обслуживанию, 3 - для данного хоста при заданном в IP-пакете требовании к обслуживанию).

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

Сообщения «Превышено время жизни» (Тип=11) посылается отправителю в двух ситуациях. При обнулении поля TTL в заголовке IP-пакета узлом, на котором это произошло, отправляется ICMP-сообщение с кодом = 0. Причиной этого явления может быть петля маршрутизации, или слишком длинный путь до узла назначения. Сообщение «Превышено время жизни» с кодом =1 отправляется и при превышении времени ожидания фрагмента при сборке дейтограммы.

Сообщения «Запрос/Ответ метки времени» (Тип = 13/14, Код=0) используется для синхронизации счетчиков времени различных хостов сети Internet. Формат этих сообщений представлен на рис. 6.11. В 32-битных полях «Время ...» записывается время в миллисекундах, прошедшее после полуночи по универсальному скоординированному времени (UСT/GMT). «Время отправления» (Originate timestamp) - это время, которое отправитель фиксировал последний раз перед посылкой Запроса метки времени. «Время получения» (Receive timestamp) - это время, когда сообщение-запрос впервые «увидел» получатель сообщения. Эти два поля копируются в сообщение-ответ и дополняются полем «Время отправки ответа» (Transmit timestamp) - это время, которое фиксировал в последний раз компьютер, отправляющий ответное сообщение. Располагая этими тремя временными отсчетами и дополнив их временной меткой получения ответа, хост инициировавший этот обмен имеет возможность вычислить сетевую задержку ответа и, прибавив ее к метке «Время отправки ответа», получить текущее значение часов запрашиваемого хоста, по которому он может синхронизовать свои часы.

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