что такое udp порт
UDP протокол — что это такое и как он работает
Обмен данными в интернете происходит по своим правилам, и контролируется специальными протоколами, одним из них является UDP. Если вы часто пользуетесь интернетом, то наверняка могли слышать о нем.
Но не все знают, что он из себя представляет и как вообще работает. Если вам это интересно, и вы хотите значительно расширить свой кругозор знаний в строении сетей — то вы попали по адресу.
Постоянные читатели данного портала уже знают про транспортный tcp протокол, сейчас мы обсудим еще один и называется он — UDP.
UDP протокол — что это
UDP — это транспортный протокол пользовательских датаграмм из набора правил TCP/IP. Позволяет отправлять информацию (датаграммы) по IP-сети без предварительного установления соединения и создания специального виртуального канала или путей данных. Официально был разработан в 1 980 году человеком по имени Дэвид П. Рид. Полностью расшифровывается как — User Datagram Protocol.
Интересно! Любой протокол, который не устанавливает предварительное соединение — называется датаграммным.
Передавая данные по UPD датаграммы могут приходить не по порядку и даже дублироваться, а иногда и просто пропадать. Данный протокол подразумевает, что проверки и, если есть ошибки, их исправления в принципе не нужны, либо это должно ложиться на плечи приложения.
Заголовок UDP весит 8 байтов и состоит всего из четырех значений:
Это порты отправителя и получателя, длина датаграммы и контрольная сумма. Поля, которые помечены на скриншоте желтым цветом — необязательны к использованию в сетях IPv4.
Также, для расширения кругозора рекомендую прочитать статью — как проверить скорость интернета.
Плюсы UDP протокола — кому он полезен?
Доставка пакетов происходит гораздо быстрее, т.к. он просто не тратит время на все те проверки, установку соединения и т.д., как это делает TCP.
Благодаря этому он так популярен на серверах, которые отвечают на небольшие вопросы от большого количества клиентов, те же DNS сервера, онлайн игры, потоковое видео, например, IPTV, приложения видео/аудио связи.
Отличие UDP от TCP — сравнение
Как вы уже знаете, есть два основных протокола в стеке TCP/IP — это TCP и UDP. Многие задаются в чем между ними разница, а разница по большому счету в «гарантии доставки» данных. Так, TCP требует от получателя подтверждения того, что он получил пакеты данных, а для этого необходимо изначально установленное соединение между узлами. Также, он исключает потерю данных, задержки, использует логическое соединение и т.д. А вот ЮДП этого не делает, поэтому его еще часто называют — «протокол ненадежных датаграмм».
Недостатки:
Преимущества:
В заключение
Вот вы и узнали, что такое UDP, чем он отличается от другого транспортного протокола, его преимущества и недостатки. Обучайтесь, изучайте новое и жизнь станет куда интереснее.
Что такое udp порт
User Datagram Protocol
TCP/IP (иногда называют UDP/IP)
Ядра Windows, Linux, UNIX
Ядра Windows, Linux, UNIX
UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — один из ключевых элементов Internet Protocol Suite (более известного как TCP/IP), набора сетевых протоколов для Интернета. С UDP компьютерные приложения могут посылать сообщения (в данном случае называемые датаграммами) другим хостам по IP-сети без необходимости предварительного сообщения для установки специальных каналов передачи или путей данных. Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определен в RFC 768.
UDP использует простую модель передачи, без неявных «рукопожатий» для обеспечения надежности, упорядочивания или целостности данных. Таким образом, UDP предоставляет ненадежный сервис, и датаграммы могут прийти не по порядку, дублироваться или вовсе исчезнуть без следа. UDP подразумевает, что проверка ошибок и исправление либо не необходимы, либо должны исполняться в приложении. Чувствительные ко времени приложения часто используют UDP, так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. При необходимости исправления ошибок на сетевом уровне интерфейса приложение может задействовать TCP или SCTP, разработанные для этой цели.
Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.
Содержание
Служебные порты
IANA разбила номера портов на три группы.
Структура пакета
UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надежная передача в случае необходимости должна реализовываться пользовательским приложением.
Заголовок UDP состоит из четырех полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.
В этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из «хорошо известных».
Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.
Расчёт контрольной суммы
Метод для вычисления контрольной суммы определен в RFC 768.
Перед расчетом контрольной суммы UDP-сообщение дополняется в конце нулевыми битами до длины, кратной 16 битам (псевдозаголовок и добавочные нулевые биты не отправляются вместе с сообщением). Поле контрольной суммы в UDP-заголовке во время расчета контрольной суммы отправляемого сообщения принимается нулевым.
Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.
Нулевое значение контрольной суммы зарезервировано, и означает что датаграмма не имеет контрольной суммы. В случае, если вычисленная контрольная сумма получилась равной нулю, поле заполняют двоичнымим единицами.
При получении сообщения получатель считает контрольную сумму заново (уже учитывая поле контрольной суммы), и, если в результате получится двоичное число из шестнадцати единиц (то есть 0xffff ), то контрольная сумма считается сошедшейся. Если сумма не сходится (данные были повреждены при передаче), датаграмма уничтожается.
Пример расчёта контрольной суммы
Различие между IPv4 и IPv6 в данных, используемых для вычисления контрольной суммы.
Псевдозаголовки
Псевдозаголовок для IPv4
Если UDP работает над IPv4, контрольная сумма вычисляется при помощи псевдозаголовка, который содержит некоторую информацию из заголовка IPv4. Псевдозаголовок не является настоящим IPv4-заголовком, используемым для отправления IP-пакета. В таблице приведен псевдозаголовок, используемый только для вычисления контрольной суммы.
Биты | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Адрес источника | |||||||||||||||||||||||||||||||
32 | Адрес получателя | |||||||||||||||||||||||||||||||
64 | Нули | Протокол | Длина UDP | |||||||||||||||||||||||||||||
96 | Порт источника | Порт получателя | ||||||||||||||||||||||||||||||
128 | Длина | Контрольная сумма | ||||||||||||||||||||||||||||||
160+ | Данные |
Адреса источника и получателя берутся из IPv4-заголовка. Значения поля «Протокол» для UDP равно 17 (0x11). Поле «Длина UDP» соответствует длине заголовка и данных.
Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.
Псевдозаголовок для IPv6
При работе UDP над IPv6 контрольная сумма обязательна. Метод для ее вычисления был опубликован в RFC 2460:
При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:
Биты | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Адрес источника | |||||||||||||||||||||||||||||||
32 | ||||||||||||||||||||||||||||||||
64 | ||||||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||||||
128 | Адрес получателя | |||||||||||||||||||||||||||||||
160 | ||||||||||||||||||||||||||||||||
192 | ||||||||||||||||||||||||||||||||
224 | ||||||||||||||||||||||||||||||||
256 | Длина UDP | |||||||||||||||||||||||||||||||
288 | Нули | Следующий заголовок | ||||||||||||||||||||||||||||||
320 | Порт источника | Порт получателя | ||||||||||||||||||||||||||||||
352 | Длина | Контрольная сумма | ||||||||||||||||||||||||||||||
384+ | Данные |
Надежность и решения проблемы перегрузок
Из-за недостатка надежности, приложения UDP должны быть готовыми к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надежности на прикладном уровне.
Более серьезной потенциальной проблемой является то, что в отличие от TCP, основанные на UDP приложения не обязательно имеют хорошие механизмы контроля и избежания перегрузок. Чувствительные к перегрузкам UDP-приложения, которые потребляют значительную часть доступной пропускной способности, могут поставить под угрозу стабильность в Интернете.
Приложения
Голосовой и видеотрафик обычно передается с помощью UDP. Протоколы потокового видео в реальном времени и аудио разработаны для обработки случайных потерь пакетов так, что качество лишь незначительно уменьшается вместо больших задержек при повторной передаче потерянных пакетов. Поскольку и TCP, и UDP работают с одной и той же сетью, многие компании замечают, что недавнее увеличение UDP-трафика из-за этих приложений реального времени мешает производительности TCP-приложений вроде систем баз данных или бухгалтерского учета. Так как и бизнес-приложения, и приложения в реальном времени важны для компаний, развитие качества решений проблемы некоторыми рассматривается в качестве важнейшего приоритета.
Сравнение UDP и TCP
Протокол пользовательской датаграммы (UDP)
Для UDP используется простая модель передачи данных. Это означает, что не существует гарантии целостности или надежности данных, обеспечивающей незащищенность, неупорядоченность, а иногда и дублирование датаграмм. В отличие от TCP, UDP не сильно полагается на исправление и проверку ошибок при выполнении. Таким образом, UDP хорошо подходит для мультикастинга или отправки всем абонентам, пакетного вещания или отправки всем абонентам в локальной сети. [2] UDP трафик, в отличие от TCP, не обязательно требует ответа и не обязательно устанавливать соединение для отправки. [3]
Cодержание
Функциональность
UDP, в отличие от TCP, посылает пакеты получателю независимо от того, могут ли они получить их полностью или нет. Каждый из пакетов отправляется отправителем получателю напрямую и индивидуально, без установления и подтверждения наличия надежного канала передачи данных. Пользователям не предоставляется возможность запрашивать недостающие пакеты данных после того, как они потеряны при транспортировке. [4] Данный тип протокола используется в основном в тех случаях, когда скорость передачи данных имеет более высокий приоритет, чем надежность успешной передачи данных. Нет внутреннего порядка передачи пакетов данных, и все пакеты передаются по сети независимо друг от друга.
Видео в прямом эфире
Например, пользователи, которые смотрят прямой видеопоток в интернете, полагаются на сервер, который посылает непрерывный поток пакетов данных. Большинство потоков видео в прямом эфире используют UDP, а не TCP. Когда зритель сталкивается с блокировкой экрана или задержкой во время трансляции, это вызвано потерей или обрывом соединения в виде потери пакетов во время передачи данных. Потеря пакетов, хотя и приводит к искажению видео или звука, но при передаче через UDP все равно позволяет воспроизводить видео целиком.
Онлайн игры
Аналогично, онлайн игры реализуют аналогичную концепцию. Символы проигрывателя могут появляться при телепортации по картам, когда вы получаете новые UDP-пакеты при пропуске некоторых из предыдущих передач данных. Игра продолжается, и пользователям не нужно извлекать старые и потерянные пакеты. Отмена коррекции ошибок TCP снижает задержки и улучшает скорость игрового соединения. [5] Отсутствие UDP пакетов во время игры приведет к незначительным сбоям, но не обязательно изменит ее производительность. В то время как игра продолжается в UDP, TCP зависимые игры будут иметь другой результат, который является целым замораживанием игры. В онлайн-играх важно то, что происходит в режиме реального времени. [6]
Эффекты
Как уникальный протокол, протокол User Datagram Protocol имеет свои плюсы и минусы. Некоторые из наиболее распространенных, с которыми вы столкнетесь, объясняются ниже.
Преимущества
Он имеет относительно более высокую скорость передачи данных благодаря небольшому весу пакетов с минимальными заголовками. Так как он не требует ответа, он подходит для видеоконференций, трансляций и игр.
Недостатки
Поскольку последовательность и подтверждение во время передачи данных отсутствуют, UDP считается ненадежной и небезопасной. Поврежденные пакеты удаляются, но не запрашиваются для повторной передачи, после того как они утеряны.
Протоколы и порты
Каждому устройству или компьютеру в Интернете присвоен свой уникальный номер, известный как IP-адрес. Это для конкретного компьютера, который должен быть идентифицирован, когда вы находитесь в Интернете. Информация, передаваемая через Интернет с компьютера, теперь принимается с помощью портов. Как и TCP, UDP также имеет свои специфические функции и порты. Ниже приведены некоторые из наиболее часто используемых для UDP.
Система доменных имен (DNS RFC 1034-1035: порт 53)
Протокол DNS является одним из широко используемых протоколов как в публичных, так и в частных сетях. Его основной целью является преобразование доменных имен в IP-адреса для маршрутизации по сети. широко используется в публичном интернете и частных сетях для преобразования доменных имен в IP-адреса, обычно для маршрутизации сети. DNS-серверы могут быть настроены внутри частной сети, не будучи частью глобальной системы.
Протокол динамической конфигурации хоста (DHCP RFC 2131: порт 67/68)
Этот протокол в основном используется в сетях, не использующих статические назначения IP-адресов. Сервер может быть настроен либо инженером, либо администратором, у которого есть доступный для назначения пул адресов. Клиент может включить устройство и запросить IP-адрес с локального DHCP-сервера, когда есть доступный адрес, он будет назначен устройству. Однако это не является постоянным назначением и истекает через определенный промежуток времени. Срок действия договора аренды истекает, если не подается запрос на продление, и он будет возвращен в пул для передачи другим устройствам.
Тривиальный протокол передачи файлов (TFP RFC 1350: порт 69)
Этот протокол, в отличие от обычного протокола передачи файлов, используемого в TCP, предлагает метод передачи данных без создания сеанса. Использование протокола TFTP не гарантирует, что передача файлов была выполнена должным образом. Этот протокол в основном используется для обновления микропрограммного обеспечения и программного обеспечения устройств.
Простой протокол сетевого управления (SNMP RFC 1901-1908, 3411-3418: порт 161-/162)
Протокол сетевого времени (NTP RFC 5905: порт 123)
Основной целью NTP является синхронизация устройств в Интернете, и считается одним из наиболее игнорируемых протоколов. Для поддержания точных часов в большинстве современных операционных систем используется протокол NTP. Устройство позволяет без особых усилий устранять неполадки на разных устройствах, поскольку часы точны, что делает NTP жизненно важной частью сетевых систем. [7]
В заключение хочу сказать, что на сегодняшний день UDP выполняет свою собственную задачу вместе с различными интернет-протоколами. Он все еще используется во многих основных приложениях, которые мы используем каждый день, например, для потоковой передачи видео и видеоконференций.
4.4.2 Протокол UDP
Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)
В RFC-768 говорится, что поле «Порт отправителя» является опционным, что вроде бы, позволяет его не заполнять. Действительно, если UDP-дейтограммы используются для передачи цифровой ТВ-программы через Интернет, номер порта отправителя получателю знать не обязательно. Но за 40 лет, прошедших с написания RFC-769 перечень приложений, использующих протокол UDP существенно расширился. Например, для многопользовательских видеоконференций стало важно, в какое из открытых окон следует адресовать содержимое UDP-дейтограммы, а это может зависеть от номера порта отправителя.
Область использования 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-дейтограмм
Таблица 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).