Протокол udp

UDP (User Datagram Protocol) – протокол пользовательских дейтаграмм. Он используется в том случае, если передаваемые данные помещаются в одном пакете, а гарантия их доставки не особенно важна. Этот протокол не заботится о пропавших пакетах, о расположении данных в правильном порядке и о других тонкостях. Протокол применяется для тех программ, которые посылают только короткие сообщения и могут повторить передачу данных, если ответ задерживается.

Формат дейтаграммы UDP показан на рисунке.

Поле «длина» указывает количество байтов в дейтаграмме (т.е. длина заголовка и данных).

Данные протокола UDP инкапсулируется в IP-дейтаграммах при передаче их по сети (см. рис.).

Только IP-заголовок определяет отправителя и получателя. Сама же дейтаграмма содержит только номера портов.

UDP обеспечивает мультиплексирование и демультиплексирование дейтаграмм (см. рис.).

Каждый такой порт (также как и в протоколе TCP) может быть представлен в виде входной и выходной очереди дейтаграмм.

Протокол icmp

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) является вспомогательным в стеке TCP/IP.

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

Протокол включается в каждую реализацию протокола IP и может рассматриваться и как его неотъемлемая часть.

Сообщения ICMP передаются по сети в поле данных IP-дейтаграммы. Протокол посылает два вида сообщений:

• управляющие сообщения;

• сообщения об ошибках.

Эти сообщения могут быть посланы как на другие маршрутизаторы, так и на конечные станции.

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

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

Все сообщения ICMP начинаются с трех одинаковых полей (см. рис.).

Поле «тип» определяет смысл сообщения и его формат. Это поле может иметь, например, следующие значения:

• 8 — запрос эха;

• 3 — получатель недостижим;

• 11 — время жизни дейтаграммы истекло;

• 12 — ошибка параметра;

• 17 — запрос маски адреса и т. д.

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

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

• 1 — устройство недостижимо;

• 3 — порт недостижим;

• 4 — требуется фрагментация;

• 6 — сеть назначения неизвестна и т.д.

В это сообщение включается IP-заголовок отвергнутой IP-дейтаграммы и ее первые 64 бита.

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

Сообщение «Изменение маршрута» используется для указания источнику на то, что в данной сети существует более оптимальный путь доставки отправленной дейтаграммы. В сообщении указывается адрес рекомендуемого маршрутизатора.

Сообщение «Время жизни дейтаграммы истекло» посылается при обнулении счетчика времени жизни дейтаграммы или при превышении времени ожидания формирования фрагментов дейтаграммы.

Сообщение «Ошибка параметра» посылается маршрутизатором при обнаружении неправильного параметра в заголовке. Тогда дейтаграмма уничтожается. Неверный байт передается в специальном поле «указатель».

Сообщения «Запрос временной метки» и «Передача временной метки» используются для синхронизации часов в распределенной системе.

Сообщения «Запрос маски адреса» и «Передача маски адреса» необходимы для уточнения того, какие биты адреса относятся к адресу сети.