previous up next index search
Previous: 4.4.1 IP-протокол    UP: 4.4 Интернет
    Next: 4.4.3 Протокол TCP

4.4.2 Протокол UDP

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)


Область использования UDP
Формат UDP-дейтограмм
Стандартные номера портов UDP
Схема вычисления контрольных сумм

Протокол UDP (User Datagram Protocol, RFC-768) является одним из основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтограмм, но не требует подтверждения их получения. Протокол UDP не требует соединения с удаленным модулем UDP ("бессвязный" протокол). К заголовку IP-пакета UDP добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина UDP-дейтограммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне IP для определения места доставки пакета используется адрес, на уровне UDP - номер порта.

В RFC-768 говорится, что поле "Порт отправителя" является опционным, что вроде бы, позволяет его не заполнять. Действительно, если UDP-дейтограммы используются для передачи цифровой ТВ-программы через Интернет, номер порта отправителя получателю знать не обязательно. Но за 40 лет, прошедших с написания RFC-769 перечень приложений, использующих протокол UDP существенно расширился. Например, для многопользовательских видеоконференций стало важно, в какое из открытых окон следует адресовать содержимое UDP-дейтограммы, а это может зависеть от номера порта отправителя.

Область использования UDP

Примерами сетевых приложений, использующих UDP, являются NFS (Network File System), TFTP (Trivial File Transfer protocol, RFC-1350), RPC (Remote Procedure Call, RFC-1057) и SNMP (Simple Network Management Protocol, RFC-1157). Малые накладные расходы, связанные с форматом UDP, а также отсутствие необходимости подтверждения получения пакета, делают этот протокол наиболее популярным при реализации приложений мультимедиа, но главное его место работы - локальные сети и мультимедиа.


Хотя протокол UDP не гарантирует доставки, по умолчанию предполагается, что вероятность потери пакета достаточно мала.

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

Например, сервер SNMP всегда ожидает сообщения, адресованного в порт 161. Если клиент snmp желает получить услугу, он посылает запрос в UDP-порт 161 на машину, где работает сервер. На каждой машине может быть только один агент SNMP, т.к. существует только один порт 161. Данный номер порта является общеизвестным, т.е. фиксированным номером, официально выделенным в сети Internet для услуг SNMP. Общеизвестные номера портов определяются стандартами Internet (см. табл. 4.4.2.1).

Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процесс-отправитель производит 5 записей в порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части. Формат UDP-сообщений представлен ниже на рис. 4.4.2.1:


Формат UDP-дейтограмм

Рис. 4.4.2.1 Формат UDP-дейтограмм

Длина сообщения равна числу байт в UDP-дейтограмме, включая заголовок. Поле UDP контрольная сумма содержит код, полученный в результате контрольного суммирования UDP-заголовка и поля данные. Не трудно видеть, что этот протокол использует заголовок минимального размера (8 байт). Таблица номеров UDP-портов приведена ниже (4.4.2.1). Номера портов от 0 до 255 стандартизованы и использовать их в прикладных задачах не рекомендуется. Но и в интервале 255-1023 многие номера портов заняты, поэтому прежде чем использовать какой-то порт в своей программе, следует заглянуть в RFC-1700. Во второй колонке содержится стандартное имя, принятое в Internet, а в третей - записаны имена, принятые в UNIX.

Таблица 4.4.2.1 Номера UDP-портов (более полный перечень в RFC-1700; Если какой-то номер порта в перечне отсутствует, это не означает, что он не зарезервирован и его можно использовать, просто я сэкономил место). См. IANA, а также Приложения.


Стандартные номера портов UDP

Десятич. номер порта Обозначение порта Описание
  в Интернет в Unix  
0 - - Зарезервировано
1 TCPmux - TCP Мультиплексор
2 Compressnet - Программа управления
3 Compressnet - Процесс сжатия
5 RJE - Вход в удаленную задачу
7 Echo echo Эхо
9 Discard discard Сброс
11 Users systat Активные пользователи
13 Daytime daytime Время дня
15 - Netstat Кто работает или netstat
19 Chargen chargen Генератор символов
20 FTP-data ftp-data FTP (данные)
21 FTP ftp Протокол пересылки файлов (управление)
23 telnet telnet Подключение терминала
24 - - Любая частная почтовая система
25 SMTP SMTP Протокол передачи почтовых сообщений
31 MSG-auth   Распознавание сообщения (аутентификация)
35 - - Любой частный принт-сервер
37 Time time Время
39 RLP - Протокол поиска ресурсов
41 Graphics   Графика
42 nameserver name Сервер имен
43 Nicname whois Кто это? (whois-сервис)
45 MPM - Блок обработки входных сообщений
46 MPM-snd - Блок обработки выходных сообщений
48 Auditd - Демон цифрового аудита
49 login - Протокол входа в ЭВМ
50 RE-mail-ck - Протокол удаленного контроля почтовым обменом
53 Domain nameserver Сервер имен доменов (dns)
57 - - Любой частный терминальный доступ
59 - - Любой частный файл-сервер
64 covia - Коммуникационный интегратор (ci)
66 SQL*net - Oracle SQL*net
67 Bootps Bootps Протокол загрузки сервера
68 Bootpc bootpc Протокол загрузки клиента
69 TFTP tftp Упрощенная пересылка файлов
70 Gopher - Gopher (поисковая система)
71 - Netrjs-1 Сервис удаленных услуг
77 - rje Любой частный RJE-сервис
79 Finger finger finger
80 WWW-HTTP   World Wide Web HTTP
81 Hosts2-NS - Сервер имен 2
87 - - Любая частная терминальная связь
88 Kerberos   Kerberos
92 NPP - Протокол сетевой печати
93 DCP - Протокол управления приборами
95 Supdup supdup Supdup протокол
97 Swift-rvf - swift-протокол удаленных виртуальных файлов
101 Hostname hostnames Сервер имен ЭВМ для сетевого информационного центра
102 ISO-Tsap iso-tsap ISO-Tsap
103 GPPitnp   Сети точка-точка
104 ACR-nema   ACR-nema digital IMAG. & comm. 300
108 Snagas   sna-сервер доступа
109 POP2 - Почтовый протокол pop2
110 POP3 - Почтовый протокол POP3
111 SUNRPC sunrpc SUN microsystem RPC
113 Auth auth Служба распознавания
114 Audionews   Аудио-новости
115 SFTP   Простой протокол передачи файлов
117 UUCP-path uucp-path Служба паролей UUCP
118 SQLserv   SQL-сервер
119 NNTP NNTP Протокол передачи новостей
123 NTP NTP Сетевой протокол синхронизации
129 PWDgen   Протокол генерации паролей
130-132     Cisco
133 Statsrv   Сервер статистики
134 Ingres-net   Ingres-net-сервис
135 LOC-srv   Поисковый сервис
137 Netbios-SSN - Служба имен Netbios
138 Netbios-DGM   Служба дейтограмм netbios
139 Netbios-SSN   Служба сессий Netbios
147 ISO-IP   ISO-IP
150 SQL-net   SQL net
152 BFTP   Протокол фоновой пересылки файлов
156 SQLsrv   SQL-сервер
158 PCmail-srv   PC почтовый сервер
161 - SNMP Сетевой монитор SNMP
162 - SNMP-trap SNMP-ловушки
170 Print-srv   postscript сетевой сервер печати
179 BGP   Динамический протокол внешней маршрутизации
191 Prospero   Служба каталогов Prospero
194 IRC   Протокол Интернет для удаленных переговоров
201-206     Протоколы сетей Apple talk
213 IPX   ipx
348 CSI-SGWP   Протокол управления cabletron
396 Netware-IP   Novell-Netware через IP
398 Kryptolan   Kryptolan
414 Infoseek   Infoseek (информационный поиск)
418 Hyper-g   Hyper-g
444 SNPP   Простой протокол работы со страницами
512 - biff (exec) Unix Comsat (удаленное исполнение)
513 - Who Unix Rwho daemon
514 - syslog Дневник системы
515 Printer   Работа с буфером печати (spooler)
525 - Timed Драйвер времени

Зарегистрировано ряд портов для стандартного применения и в диапазоне 1024-65535. Например:

Номер порта Обозначение Назначение
1397 Аudio-activmail Активная звуковая почта
1398 Video-activmail Активная видео-почта
5002 RFE Радио-Ethernet
6000-6063 X11 Система X Window
7008 AFS3-update Сервер-сервер актуализация

Схема вычисления контрольных сумм

Модуль IP передает поступающий IP-пакет модулю UDP, если в заголовке этого пакета указан код протокола UDP. Когда модуль UDP получает дейтограмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, это означает, что отправитель ее не подсчитал. ICMP, IGMP, UDP и TCP протоколы имеют один и тот же алгоритм вычисления контрольной суммы (RFC-1071). Но вычисление контрольной суммы для UDP имеет некоторые особенности. Во-первых, длина UDP-дейтограммы может содержать нечетное число байт, в этом случае к ней добавляется нулевой байт, который служит лишь для унификации алгоритма и никуда не пересылается. Во-вторых, при расчете контрольной суммы для UDP и TCP добавляются 12-байтные псевдо-заголовки, содержащие IP-адреса отправителя и получателя, код протокола и длину дейтограммы (см. рис. 4.4.2.2). Как и в случае IP-дейтограммы, если вычисленная контрольная сумма равна нулю, в соответствующее поле будет записан код 65535.


Рис. 4.4.2.2. Псевдозаголовок, используемый при расчете контрольной суммы

Если контрольная сумма правильная (или равна 0), то проверяется порт назначения, указанный в заголовке дейтограммы. Если прикладной процесс подключен к этому порту, то прикладное сообщение, содержащиеся в дейтограмме, становится в очередь к прикладному процессу для прочтения. В остальных случаях дейтограмма отбрасывается. Если дейтограммы поступают быстрее, чем их успевает обрабатывать прикладной процесс, то при переполнении очереди сообщений поступающие дейтограммы отбрасываются модулем UDP. Следует учитывать, что во многих посылках контрольное суммирование не охватывает адреса отправителя и места назначения. При некоторых схемах маршрутизации это приводит к зацикливанию пакетов в случае повреждения его адресной части (адресат не признает его "своим").

Может возникнуть вопрос, зачем вычислять и проверять контрольную сумму, если подтверждение доставки и повторная пересылка в рамках протокола не предусмотрены. Дело в том, что UDP используется не только для мультимедийных задач но и некоторыми другими протоколами (DNS, SNMP и др.), где повторные запросы и отклики могут выполняться на прикладном уровне.

Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее (Ethernet допускает 1508 байт). Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768. Смотри также RFC-2147 (IPv6 Jumbo), RFC-2508 (компрессия заголовков) и RFC-3828 (Lightweight UDP).

Нашел применение UDP и в протоколе Teredo (туннелирование IPv6 для систем NAT).


Previous: 4.4.1 IP-протокол    UP: 4.4 Интернет
    Next: 4.4.3 Протокол TCP