Протокол пользовательских датаграмм

В компьютерной сети , то User Datagram Protocol ( UDP ) является одним из основных членов набора протоколов Internet . Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определен в RFC  768 . С помощью UDP компьютерные приложения могут отправлять сообщения, в этом случае называемые дейтаграммами , на другие узлы в сети Интернет-протокола (IP). Предварительная связь не требуется для настройки каналов связи или трактов передачи данных.

UDP использует простую модель связи без установления соединения с минимумом протокольных механизмов. UDP предоставляет контрольные суммы для целостности данных и номера портов для адресации различных функций в источнике и получателе дейтаграммы. Он не имеет диалоговых окон для подтверждения установления связи и, таким образом, подвергает программу пользователя любой ненадежности базовой сети; нет гарантии доставки, заказа или защиты от дублирования. Если средства исправления ошибок необходимы на уровне сетевого интерфейса, приложение может использовать протокол управления передачей (TCP) или протокол передачи управления потоком (SCTP), которые предназначены для этой цели.

UDP подходит для целей, где проверка и исправление ошибок либо не нужны, либо выполняются в приложении; UDP позволяет избежать накладных расходов на такую ​​обработку в стеке протоколов . Чувствительные ко времени приложения часто используют UDP, потому что отбрасывание пакетов предпочтительнее, чем ожидание пакетов, задержанных из-за повторной передачи , что не может быть вариантом в системе реального времени . ^[1]

Атрибуты [ править ]

UDP - это простой протокол транспортного уровня, ориентированный на сообщения , который задокументирован в RFC 768 . Хотя UDP обеспечивает проверку целостности (с помощью контрольной суммы ) заголовка и полезной нагрузки ^[2], он не дает никаких гарантий протоколу верхнего уровня для доставки сообщений, а уровень UDP не сохраняет состояние отправленных сообщений UDP. По этой причине UDP иногда называют протоколом ненадежных датаграмм . ^[3] Если требуется надежность передачи, она должна быть реализована в приложении пользователя. 

Ряд атрибутов UDP делают его особенно подходящим для определенных приложений.

• Он ориентирован на транзакции и подходит для простых протоколов запроса-ответа, таких как система доменных имен или протокол сетевого времени .
• Он предоставляет дейтаграммы , подходящие для моделирования других протоколов, таких как IP-туннелирование или удаленный вызов процедур, а также сетевая файловая система .
• Он прост , подходит для начальной загрузки или других целей без полного стека протоколов , таких как DHCP и Trivial File Transfer Protocol .
• Он не имеет состояния , подходит для очень большого числа клиентов, например, в приложениях потокового мультимедиа, таких как IPTV .
• Отсутствие задержек ретрансляции делает его пригодным для приложений реального времени , таких как Voice Over IP , онлайн - игр , и многие протоколы с использованием Real Time Streaming Protocol .
• Поскольку он поддерживает многоадресного , он подходит для широковещательной информации , таких , как во многих видах обнаружения службы и общей информации , такие как Time Protocol Precision и Протокол информации о маршрутизации .

Порты [ править ]

Приложения могут использовать сокеты дейтаграмм для установления связи между хостами. Приложение привязывает сокет к своей конечной точке передачи данных, которая представляет собой комбинацию IP-адреса и порта . Таким образом, UDP обеспечивает мультиплексирование приложений . Порт - это программная структура, которая идентифицируется номером порта , 16-битным целым числом, допускающим номера портов от 0 до 65535. Порт 0 зарезервирован, но является допустимым значением порта источника, если отправляющий процесс не ожидает сообщений в отклик.

Управление по присвоению номеров в Интернете (IANA) разделило номера портов на три диапазона. ^[4] Номера портов от 0 до 1023 используются для общих, хорошо известных услуг. В Unix- подобных операционных системах для использования одного из этих портов требуется разрешение суперпользователя . Номера портов с 1024 по 49151 - это зарегистрированные порты, используемые для служб, зарегистрированных IANA. Порты с 49152 по 65535 являются динамическими портами, которые официально не предназначены для какой-либо конкретной службы и могут использоваться для любых целей. Они также могут использоваться как временные порты , которые программное обеспечение, работающее на хосте, может использовать для динамического создания конечных точек связи по мере необходимости. ^[4]

Структура дейтаграммы UDP [ править ]

Дейтаграмма UDP состоит из заголовка дейтаграммы и раздела данных . Заголовок дейтаграммы UDP состоит из 4 полей, каждое из которых составляет 2 байта (16 бит). ^[1] Раздел данных следует за заголовком и представляет собой данные полезной нагрузки, переносимые для приложения.

Использование полей контрольной суммы и порта источника необязательно в IPv4 (розовый фон в таблице). В IPv6 только поле порта источника является необязательным.

Номер исходного порта

Это поле идентифицирует порт отправителя, когда оно используется, и должно предполагаться как порт, на который следует ответить в случае необходимости. Если не используется, он должен быть равен нулю. Если исходный хост является клиентом, номер порта, скорее всего, будет временным номером порта. Если исходным хостом является сервер, номер порта, скорее всего, будет хорошо известным номером порта . ^[4]

Номер порта назначения

Это поле определяет порт получателя и является обязательным. Подобно номеру порта источника, если клиент является хостом назначения, то номер порта, скорее всего, будет временным номером порта, а если хост назначения является сервером, то номер порта, скорее всего, будет хорошо известным номером порта. ^[4]

Длина

В этом поле указывается длина в байтах заголовка UDP и данных UDP. Минимальная длина - 8 байтов, это длина заголовка. Размер поля устанавливает теоретический предел 65 535 байтов (8 байтов заголовка + 65 527 байтов данных) для дейтаграммы UDP. Однако фактический предел длины данных, который налагается базовым протоколом IPv4 , составляет 65 507 байтов (65 535 - 8-байтовый заголовок UDP - 20-байтовый заголовок IP ). ^[4]

Используя джумбограммы IPv6 , можно иметь дейтаграммы UDP размером более 65 535 байт. ^[5] RFC 2675 указывает, что поле длины устанавливается в ноль, если длина заголовка UDP плюс данные UDP больше 65 535. 

Контрольная сумма

Поле контрольной суммы может использоваться для проверки ошибок заголовка и данных. Это поле необязательно в IPv4 и обязательно в IPv6. ^[6] Поле содержит все нули, если оно не используется. ^[7]

Вычисление контрольной суммы [ править ]

Метод, используемый для вычисления контрольной суммы, определен в RFC 768 : 

Контрольная сумма - это 16-битное дополнение до единицы суммы дополнения до единицы псевдозаголовка информации из заголовка IP, заголовка UDP и данных, дополненных нулевыми октетами в конце (при необходимости), чтобы кратно двум октетам. . ^[7]

Другими словами, все 16-битные слова суммируются с использованием дополнительной арифметики. Сложите 16-битные значения. При каждом добавлении, если создается перенос (17-й бит), поверните этот 17-й бит переноса и добавьте его к младшему значащему биту промежуточной суммы. ^[8] Наконец, сумма дополняется до значения поля контрольной суммы UDP.

Если вычисление контрольной суммы приводит к нулевому значению (все 16 битов 0), оно должно быть отправлено как дополнение до единицы (все единицы), поскольку контрольная сумма с нулевым значением указывает, что контрольная сумма не была вычислена. ^[7] В этом случае никакой специальной обработки на приемнике не требуется, потому что все нули и все единицы равны нулю в арифметике дополнения до единицы.

Разница между IPv4 и IPv6 заключается в псевдозаголовке, используемом для вычисления контрольной суммы, а контрольная сумма не является необязательной в IPv6. ^[9]

Псевдо-заголовок IPv4 [ править ]

Когда UDP работает через IPv4, контрольная сумма вычисляется с использованием «псевдозаголовка», который содержит часть той же информации, что и настоящий заголовок IPv4 . ^{[7] : 2} Псевдозаголовок не является настоящим заголовком IPv4, используемым для отправки IP-пакета, он используется только для вычисления контрольной суммы.

Адреса источника и назначения указаны в заголовке IPv4. Протокол тот же, что и для UDP (см. Список номеров IP-протоколов ): 17 (0x11). Поле длины UDP - это длина заголовка и данных UDP. Поле data обозначает переданные данные.

Вычисление контрольной суммы UDP не является обязательным для IPv4. Если контрольная сумма не используется, ей следует установить нулевое значение.

Псевдо-заголовок IPv6 [ править ]

Когда UDP работает через IPv6, контрольная сумма обязательна. Метод, используемый для его вычисления, изменен, как описано в RFC 2460 : 

Любой транспортный или другой протокол верхнего уровня, который включает адреса из заголовка IP при вычислении контрольной суммы, должен быть модифицирован для использования через IPv6, чтобы включить 128-битные адреса IPv6. ^[6]

При вычислении контрольной суммы снова используется псевдозаголовок, имитирующий настоящий заголовок IPv6 :

Исходный адрес - это адрес в заголовке IPv6. Адрес назначения - это конечный пункт назначения; если пакет IPv6 не содержит заголовка маршрутизации, это будет адрес назначения в заголовке IPv6; в противном случае на исходном узле это будет адрес в последнем элементе заголовка маршрутизации, а на принимающем узле это будет адрес назначения в заголовке IPv6. Значение поля Next Header - это значение протокола для UDP: 17. Поле длины UDP - это длина заголовка и данных UDP.

Решения по обеспечению надежности и контроля перегрузок [ править ]

Не обладая надежностью, приложения UDP должны быть готовы принять некоторую потерю пакетов, переупорядочение, ошибки или дублирование. При использовании UDP приложения конечного пользователя должны обеспечивать любое необходимое квитирование, например подтверждение в реальном времени, что сообщение было получено. Приложения, такие как TFTP , могут при необходимости добавлять элементарные механизмы надежности на прикладной уровень. ^[4] Если приложение требует высокой степени надежности, вместо него можно использовать такой протокол, как протокол управления передачей .

Чаще всего в приложениях UDP не используются механизмы надежности, и они могут даже мешать им. Потоковое мультимедиа , многопользовательские игры в реальном времени и передача голоса по IP (VoIP) - вот примеры приложений, которые часто используют UDP. В этих конкретных приложениях потеря пакетов обычно не является фатальной проблемой. В VoIP, например, задержка и дрожание являются основными проблемами. Использование TCP вызовет дрожание, если какие-либо пакеты были потеряны, поскольку TCP не предоставляет последующие данные приложению, когда оно запрашивает повторную отправку отсутствующих данных.

Приложения [ править ]

Многие ключевые интернет-приложения используют UDP, в том числе: систему доменных имен (DNS), где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа, простой протокол управления сетью (SNMP), протокол информации о маршрутизации ( RIP) ^[1] и протокол динамической конфигурации хоста (DHCP).

Голосовой и видеотрафик обычно передается по протоколу UDP. Протоколы потоковой передачи видео и аудио в реальном времени предназначены для обработки случайных потерянных пакетов, поэтому при повторной передаче потерянных пакетов происходит только небольшое ухудшение качества, а не большие задержки. Поскольку и TCP, и UDP работают в одной и той же сети, многие компании обнаруживают, что недавнее увеличение трафика UDP из этих приложений реального времени снижает производительность приложений, использующих TCP, таких как точки продаж , системы бухгалтерского учета и базы данных. Когда TCP обнаруживает потерю пакета, он ограничивает использование скорости передачи данных. Поскольку для бизнеса важны как приложения реального времени, так и бизнес-приложения, повышение качества обслуживаниянекоторые считают решающим. ^[11]

Некоторые системы VPN , такие как OpenVPN, могут использовать UDP и выполнять проверку ошибок на уровне приложений при реализации надежных соединений.

QUIC - это транспортный протокол, построенный на основе UDP. QUIC обеспечивает надежное и безопасное соединение. HTTP 3 использует QUIC в отличие от более ранних версий HTTPS, которые используют комбинацию TCP и TLS для обеспечения надежности и безопасности соответственно. Это означает, что HTTP 3 использует одно рукопожатие для установки соединения, а не два отдельных рукопожатия для TCP и TLS, а это означает, что общее время установления соединения сокращается. ^[12]

Сравнение UDP и TCP [ править ]

Протокол управления передачей - это протокол, ориентированный на установление соединения и требующий квитирования для установки сквозной связи. Как только соединение установлено, пользовательские данные могут быть отправлены двунаправленно по соединению.

• Надежный - TCP управляет подтверждением сообщений, повторной передачей и тайм-аутом. Сделано несколько попыток доставить сообщение. Если данные будут потеряны по пути, данные будут отправлены повторно. В TCP либо отсутствуют недостающие данные, либо, в случае нескольких тайм-аутов, соединение разрывается.
• Упорядоченный - если по соединению последовательно отправляются два сообщения, первое сообщение сначала достигнет принимающего приложения. Когда сегменты данных прибывают в неправильном порядке, TCP буферизует неупорядоченные данные до тех пор, пока все данные не будут должным образом переупорядочены и доставлены в приложение.
• Heavyweight - TCP требует трех пакетов для установки сокетного соединения, прежде чем какие-либо пользовательские данные могут быть отправлены. TCP обеспечивает надежность и контроль перегрузки .
• Потоковая передача - данные читаются как поток байтов , отличительные признаки не передаются на границы сигнального сообщения (сегмента).

Протокол пользовательских дейтаграмм - это более простой протокол без установления соединения на основе сообщений . Протоколы без установления соединения не устанавливают выделенное сквозное соединение. Связь достигается путем передачи информации в одном направлении от источника к месту назначения без проверки готовности или состояния получателя.

• Ненадежный - при отправке сообщения UDP нельзя узнать, достигнет ли оно места назначения; он мог потеряться по пути. Нет концепции подтверждения, повторной передачи или тайм-аута.
• Не упорядочено - если два сообщения отправлены одному и тому же получателю, порядок их доставки не может быть гарантирован.
• Легковесный - сообщения не упорядочиваются, не отслеживаются соединения и т. Д. Это очень простой транспортный уровень, разработанный поверх IP.
• Датаграммы - пакеты отправляются индивидуально и проверяются на целостность по прибытии. Пакеты имеют определенные границы, которые соблюдаются при получении; операция чтения в сокете-получателе даст все сообщение в том виде, в котором оно было изначально отправлено.
• Нет контроля перегрузки - UDP сам по себе не избегает перегрузки. Меры по контролю за перегрузкой должны быть реализованы на уровне приложений или в сети.
• Широковещательные рассылки - протокол UDP не требует установления соединения - отправленные пакеты могут быть адресованы для приема всеми устройствами в подсети.
• Многоадресная рассылка - поддерживается режим многоадресной рассылки, при котором один пакет дейтаграммы может автоматически маршрутизироваться без дублирования группе подписчиков.

См. Также [ править ]

Примечания и ссылки [ править ]

Заметки [ править ]

Ссылки на RFC [ править ]

• RFC  768 - протокол дейтаграмм пользователя
• RFC  2460 - Спецификация Интернет-протокола версии 6 (IPv6)
• RFC  2675 - Джумбограммы IPv6
• RFC  4113 - База управляющей информации для UDP
• RFC  8085 - Рекомендации по использованию UDP

Внешние ссылки [ править ]

В Викиверситете есть учебные ресурсы о протоколе дейтаграмм пользователя.

• Назначение портов IANA
• Проблемы со сканированием UDP (PDF)
• Разбивка кадра UDP
• UDP в гнездах журнала MSDN и WCF
• UDP-соединения