Протокол UDP

Протокол UDP (User Datagram Protocol, RFC-768) является одним из основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, немногим отличающиеся от услуг протокола IP. Протокол UDP обеспечивает доставку дейтограмм, но не требует подтверждения их получения. Протокол UDP не требует соединения с удаленным модулем UDP (“бессвязный” протокол). К заголовку IP-пакета udp добавляет поля порт отправителя и порт получателя, которые обеспечивают мультиплексирование информации между различными прикладными процессами, а также поля длина udp-дейтограммы и контрольная сумма, позволяющие поддерживать целостность данных. Таким образом, если на уровне ip для определения места доставки пакета используется адрес, на уровне 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-порты. Эти порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги (сервер), ожидает сообщений, направленных в порт, специально выделенный для этих услуг. Программа-сервер ждет, когда какая-нибудь программа-клиент запросит услугу.

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

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

Рис. 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; Если какой-то номер порта в перечне отсутствует, это не означает, что он не зарезервирован и его можно использовать, просто я сэкономил место)

Десятич. номер портаОбозначение портаОписание
 в Интернетв Unix 
0Зарезервировано
1TCPmuxtcp Мультиплексор
2CompressnetПрограмма управления
3CompressnetПроцесс сжатия
5RJEВход в удаленную задачу
7EchoechoЭхо
9DiscarddiscardСброс
11UserssystatАктивные пользователи
13DaytimedaytimeВремя дня
15NetstatКто работает или netstat
19ChargenchargenГенератор символов
20FTP-dataftp-dataFTP (данные)
21FTPftpПротокол пересылки файлов (управление)
23telnettelnetПодключение терминала
24Любая частная почтовая система
25SMTPsmtpПротокол передачи почтовых сообщений
31MSG-auth Распознавание сообщения (аутентификация)
35Любой частный принт-сервер
37TimetimeВремя
39RLPПротокол поиска ресурсов
41Graphics Графика
42nameservernameСервер имен
43NicnamewhoisКто это? (whois-сервис)
45MPMБлок обработки входных сообщений
46MPM-sndБлок обработки выходных сообщений
48AuditdДемон цифрового аудита
49loginПротокол входа в ЭВМ
50RE-mail-ckПротокол удаленного контроля почтовым обменом
53DomainnameserverСервер имен доменов (dns)
57Любой частный терминальный доступ
59Любой частный файл-сервер
64coviaКоммуникационный интегратор (ci)
66SQL*netOracle SQL*net
67BootpsBootpsПротокол загрузки сервера
68BootpcbootpcПротокол загрузки клиента
69TFTPtftpУпрощенная пересылка файлов
70GopherGopher (поисковая система)
71Netrjs-1Сервис удаленных услуг
77rjeЛюбой частный RJE-сервис
79Fingerfingerfinger
80WWW-HTTP World Wide Web HTTP
81Hosts2-NSСервер имен 2
87Любая частная терминальная связь
88Kerberos Kerberos
92NPPПротокол сетевой печати
93DCPПротокол управления приборами
95SupdupsupdupSupdup протокол
97Swift-rvfswift-протокол удаленных виртуальных файлов
101HostnamehostnamesСервер имен ЭВМ для сетевого информационного центра
102ISO-Tsapiso-tsapISO-Tsap
103GPPitnp Сети точка-точка
104ACR-nema ACR-nema digital IMAG. & comm. 300
108Snagas sna-сервер доступа 
109POP2Почтовый протокол pop2
110POP3Почтовый протокол POP3
111SUNRPCsunrpcSUN microsystem RPC
113AuthauthСлужба распознавания
114Audionews Аудио-новости
115SFTP Простой протокол передачи файлов
117UUCP-pathuucp-pathСлужба паролей uucp
118SQLserv SQL-сервер
119NNTPNNTPПротокол передачи новостей
123NTPNTPСетевой протокол синхронизации
129PWDgen Протокол генерации паролей
130-132  Cisco
133Statsrv Сервер статистики
134Ingres-net Ingres-net-сервис
135LOC-srv Поисковый сервис
137Netbios-SSNСлужба имен Netbios
138Netbios-DGM Служба дейтограмм netbios
139Netbios-SSN Служба сессий Netbios
147ISO-IP ISO-IP
150SQL-net SQL net
152BFTP Протокол фоновой пересылки файлов
156SQLsrv SQL-сервер
158PCmail-srv PC почтовый сервер
161SNMPСетевой монитор SNMP
162SNMP-trapSNMP-ловушки
170Print-srv postscript сетевой сервер печати
179BGP Динамический протокол внешней маршрутизации
191Prospero Служба каталогов Prospero
194IRC Протокол Интернет для удаленных переговоров
201-206  Протоколы сетей Apple talk
213IPX ipx
348CSI-SGWP Протокол управления cabletron
396Netware-IP Novell-Netware через IP
398Kryptolan Kryptolan
414Infoseek Infoseek (информационный поиск)
418Hyper-g Hyper-g
444SNPP Простой протокол работы со страницами
512biff (exec)Unix Comsat (удаленное исполнение)
513WhoUnix Rwho daemon
514syslogДневник системы
515Printer Работа с буфером печати (spooler)
525TimedДрайвер времени

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

Номер портаОбозначениеНазначение
1397Аudio-activmailАктивная звуковая почта
1398Video-activmailАктивная видео-почта
5002RFEРадио-Ethernet
6000-6063X11Система X Window
7008AFS3-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. Следует учитывать, что во многих посылках контрольное суммирование не охватывает адреса отправителя и места назначения. При некоторых схемах маршрутизации это приводит к зацикливанию пакетов в случае повреждения его адресной части (адресат не признает его “своим”).

Так как максимальная длина IP-дейтограммы равна 65535 байтам, максимальная протяженность информационного поля UDP-дейтограммы составляет 65507 байт. На практике большинство систем работает с UDP-дейтограммами с длиной 8192 байта или менее. Детальное описание форматов, полей пакетов и пр. читатель может найти в RFC-768.

citforum.ru