Перейти к содержанию

UDP

DHCP, DNS, синхронизация времени и потоки данных с датчиков часто идут не по TCP, а по UDP. Это самый простой транспорт стека IP: восемь байт заголовка и никаких обещаний доставки.

Обновлено Редакция GAW

Содержание

UDP (User Datagram Protocol) — транспортный протокол стека TCP/IP для отправки отдельных сообщений-датаграмм без установления соединения. RFC 768 описывает его как протокол с минимумом механизмов: доставка и защита от дублей не гарантируются, и для упорядоченной надёжной доставки RFC отсылает к TCP. Взамен UDP прост, быстр и не тратит память на состояние соединения.

Заголовок

Заголовок UDP — четыре 16-битных поля, всего 8 байт:

ПолеРазмерНазначение
порт отправителя16 биткуда отвечать; 0, если не используется
порт получателя16 биткакому приложению на узле доставить
длина16 битзаголовок и данные в байтах, минимум 8
контрольная сумма16 битзаголовок, данные и псевдозаголовок с IP-адресами

Контрольная сумма считается тем же способом, что в TCP: дополнение до единицы суммы 16-битных слов. В неё входит псевдозаголовок с адресами отправителя и получателя, поэтому она ловит и датаграммы, доставленные не тому узлу. Нулевое поле означает, что сумма не вычислялась, но это допустимо только в IPv4: поверх IPv6 контрольная сумма UDP обязательна, потому что у самого IPv6 контрольной суммы заголовка нет; исключение — особый режим для туннельных протоколов (RFC 8085, разд. 3.4 и 3.4.1).

Чего UDP не делает

RFC 8085 перечисляет, что остаётся на приложении:

  • надёжность — потерю датаграммы никто не заметит, номера пакетов, подтверждения и повтор нужно делать самому;
  • порядок и дубли — датаграммы приходят не по порядку и иногда дважды;
  • управление перегрузкой — UDP не снижает скорость, когда сеть перегружена;
  • размер — датаграмма не должна давать IP-пакет больше MTU пути; для IPv4 без сведений о пути безопасный размер IP-пакета — 576 байт.

Где встречается на микроконтроллерах

DHCP работает поверх UDP: клиент отправляет запросы на порт 67, сервер отвечает на порт 68 (RFC 2131). Пока у устройства нет IP-адреса, запросы уходят на широковещательный адрес — соединение TCP в такой ситуации установить нельзя. По UDP же обычно идут DNS, синхронизация времени и телеметрия, где свежий отсчёт важнее потерянного старого. Аппаратные стеки вроде W5500 дают UDP-сокеты наравне с TCP; ограничения таких микросхем — в статье «Ethernet для микроконтроллеров».

Частые вопросы

Почему UDP теряет пакеты и что с этим делать?

UDP вообще не следит за доставкой: датаграмма может потеряться, прийти дважды или не по порядку, и стек об этом не сообщит. RFC 8085 прямо говорит, что приложение, которому нужна надёжность, должно реализовать её само: номера пакетов, подтверждения и повтор по таймауту. Если всё это нужно, проще взять TCP.

Какого размера можно отправлять датаграмму UDP?

По RFC 8085 датаграмма не должна давать IP-пакет больше MTU пути, иначе её фрагментируют, а потеря любого фрагмента губит всю датаграмму. Для IPv4 без сведений о пути безопасная граница — 576 байт на весь IP-пакет. В локальном Ethernet MTU больше, но у микросхем с аппаратным стеком бывает и запрет фрагментации: W5500, например, фрагментацию IP не поддерживает.

Можно ли не считать контрольную сумму UDP?

Только в IPv4: по RFC 768 нулевое поле контрольной суммы означает, что отправитель её не вычислял, а если вычисленная сумма оказалась нулём, её передают как все единицы. Но тогда искажённые данные дойдут до приложения, так что без своей проверки целостности, например CRC в полезных данных, отключать её не стоит. Поверх IPv6 сумма обязательна (RFC 8085, разд. 3.4).

Источники

  1. IETF. RFC 768 User Datagram Protocol (J. Postel, 28 August 1980) — Introduction: протокол датаграмм с минимумом механизмов, доставка и защита от дублей не гарантируются, для упорядоченной надёжной доставки — TCP; Format: заголовок из четырёх 16-битных полей — порт отправителя (необязателен, 0 если не используется), порт получателя, длина, контрольная сумма; Fields: длина включает заголовок, минимум 8; контрольная сумма — дополнение до единицы суммы псевдозаголовка (адреса, протокол, длина UDP), заголовка и данных; вычисленный ноль передаётся как все единицы, переданный ноль означает «контрольная сумма не вычислялась»
  2. IETF. RFC 8085 UDP Usage Guidelines, BCP 145 (March 2017) — разд. 3.1: у UDP нет управления перегрузкой, приложение должно его выполнять само; разд. 3.2: не следует отправлять датаграммы, дающие IP-пакеты больше MTU пути, — используйте данные о MTU или Path MTU Discovery; для IPv4 EMTU_S — меньшее из 576 байт и MTU первого участка; разд. 3.3: приложение, которому нужна надёжность, обязано реализовать её само; UDP не защищает от дублирования и переупорядочивания; разд. 3.4: в IPv4 RFC 768 разрешает нулевую контрольную сумму, поверх IPv6 сумма обязательна (RFC 2460), нулевая допускается лишь в туннельном режиме по RFC 6935 и 6936 (разд. 3.4.1)
  3. IETF. RFC 2131 Dynamic Host Configuration Protocol (March 1997) — разд. 3.1: клиент рассылает DHCPDISCOVER широковещательно в своей физической сети; разд. 4.1: DHCP использует UDP; сообщения клиента идут на порт сервера 67, сообщения сервера — на порт клиента 68

Нашли ошибку?

Смотрите также