RFC 768 J. Postel ISI 28 August 1980
Протокол пользовательских дейтаграмм (UDP)
User Datagram Protocol
Введение
Протокол передачи пользовательских дейтаграмм (User Datagram Protocol или UDP) предназначен для поддержки режима обмена дейтаграммами на основе коммутации пакетов в среде связанных между собой компьютерных сетей. Это протокол предполагает использование IP [1] в качестве протокола нижележащего уровня.
Протокол UDP обеспечивает прикладным программам процедуры для передачи сообщений другим приложениям с минимальным сервисом. Протокол ориентирован на транзакции, не гарантирует доставки сообщений и не предотвращает появление дубликатов. Приложения, требующие гарантированной доставки потоков данных, должны использовать протокол TCP (Transmission Control Protocol) [2].
Формат
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | Октеты данных ... +---------------- ...
Формат заголовка дейтаграммы
Поля
Поле Source Port (порт отправителя) является необязательным и (когда используется) показывает номер порта передающего процесса. При отсутствии другой информации можно предполагать, что отклики должны адресоваться в тот же порт. Если номер порта не задан, значение поля равно 0.
Поле Destination Port имеет значение в контексте адресации отдельного соединения.
Поле Length указывает размер (в октетах) пользовательской дейтаграммы с учетом заголовка и данных. Минимальное значение поля длины составляет 8 (длина заголовка в октетах).
Поле Checksum содержит контрольную сумму, вычисляемую как поразрядное дополнение до 1 суммы поразрядных дополнений до 1 всех 16-битовых слов псевдозаголовка из заголовка IP, заголовка UDP и данных, дополненных при необходимости справа нулями для выравнивания по 2-октетной границе.
Псевдозаголовок, предшествующий заголовку UDP, содержит адреса отправителя и получателя, а также размер пакета UDP. Эта информация позволяет предотвратить ошибочную маршрутизацию дейтаграмм. Контрольная сумма используется так же, как для протокола TCP.
0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | source address | +--------+--------+--------+--------+ | destination address | +--------+--------+--------+--------+ | zero |protocol| UDP length | +--------+--------+--------+--------+
Формат псевдозаголовка
Если рассчитанное значение контрольной суммы равно нулю, все биты поля заполняются единицами (эквивалент нуля в арифметике с дополнением до 1). Передача нулевого значения контрольной суммы означает, что на передающей стороне контрольная сумма не была рассчитана (используется для отладки или для протоколов вышележащих уровней, которые не используют контрольную сумму)
Пользовательский интерфейс
Пользовательский интерфейс должен обеспечивать:
- возможность создания новых приемных портов;
- приема данных через приемные порты, которые возвращают октеты данных и индикацию адреса и порта отправителя;
- операции передачи дейтаграмм с указанием адреса и порта отправителя.
IP-интерфейс
Модуль UDP должен уметь определять IP-адреса отправителя и получателя, а также протокольные поля из заголовка IP. Возможен вариант интерфейса UDP – IP, возвращающий полную дейтаграмму IP со всеми заголовками. Такой интерфейс будет также разрешать протоколу UDP передачу полных дейтаграмм протоколу IP для последующей отправки. Протокол IP проверяет согласованность некоторых полей и вычисляет контрольную сумму заголовка IP.
Применение протокола
Основными приложениями протокола UDP является служба доменных имен Internet [3] и приложения TFTP [4].
Номер протокола
Данный протокол имеет номер 17 (восьмеричное значение 21) в стеке протоколов IP. Номера других протоколов приведены в [5].
Литература
[1] Postel, J., “Internet Protocol,” RFC 7601, USC/Information Sciences Institute, January 1980.
[2] Postel, J., “Transmission Control Protocol,” RFC 7612, USC/Information Sciences Institute, January 1980.
[3] Postel, J., “Internet Name Server,” USC/Information Sciences Institute, IEN 1163, August 1979.
[4] Sollins, K., “The TFTP Protocol,” Massachusetts Institute of Technology, IEN 1334, January 1980.
[5] Postel, J., “Assigned Numbers,” USC/Information Sciences Institute, RFC 7625, January 1980.
Перевод на русский язык
Николай Малых
nmalykh@protokols.ru
3 Этот документ устарел; актуальная спецификация протокола DNS содержится в RFC 1034, RFC 1035. Прим. перев.
4 Этот документ устарел, актуальная спецификация протокола TFTP содержится в RFC 1350. Прим. перев.
5 Документ регулярно обновлялся (последняя копия представлена в RFC 1700), но в соответствии с RFC 3232 документ STD 2 утратил силу. Значения Assigned Numbers следует искать в базе данных, доступной на сайте www.iana.org/numbers.html. Прим. перев.