stringtranslate.com

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

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

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

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

Протокол был разработан Дэвидом П. Ридом в 1980 году и официально определен в RFC  768.

Атрибуты

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

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

Порты

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

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

Структура датаграммы UDP

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

Использование полей Checksum и Source Port необязательно в IPv4 (светло-фиолетовый фон в таблице). В IPv6 необязательно только поле Source Port . Если не используется, эти поля следует установить равными нулю. [7]

Исходный порт: 16 бит
Это поле определяет порт отправителя, когда используется, и должно предполагаться как порт для ответа при необходимости. Если исходный хост — клиент, номер порта, скорее всего, будет эфемерным портом. Если исходный хост — сервер, номер порта, скорее всего, будет известным номером порта от 0 до 1023. [6]
Порт назначения: 16 бит
Это поле определяет порт получателя и является обязательным. Подобно номеру порта источника, если клиент является хостом назначения, то номер порта, скорее всего, будет эфемерным номером порта, а если хост назначения является сервером, то номер порта, скорее всего, будет общеизвестным номером порта. [6]
Длина: 16 бит
Это поле указывает длину в байтах UDP-дейтаграммы (поля заголовка и поле данных) в октетах . Минимальная длина составляет 8 байт, длина заголовка. Размер поля устанавливает теоретический предел в 65 535 байт (8-байтовый заголовок + 65 527 байт данных) для UDP-дейтаграммы. Однако фактический предел для длины данных, который налагается базовым протоколом IPv4 , составляет 65 507 байт (65 535 байт − 8-байтовый заголовок UDP − 20-байтовый заголовок IP ). [8]
Используя джумбограммы IPv6 , можно иметь датаграммы UDP размером более 65 535 байт. Поле длины устанавливается в ноль, если длина заголовка UDP плюс данные UDP больше 65 535. [9]
Контрольная сумма : 16 бит
Поле контрольной суммы может использоваться для проверки ошибок заголовка и данных. Это поле необязательно в IPv4 и обязательно в большинстве случаев в IPv6. [10]
Данные: переменные
Полезная нагрузка пакета UDP.

Вычисление контрольной суммы

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

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

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

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

Различия между IPv4 и IPv6 заключаются в псевдозаголовке, используемом для вычисления контрольной суммы, и в том, что контрольная сумма не является необязательной в IPv6. [12] При определенных условиях приложению UDP, использующему IPv6, разрешено использовать нулевой режим UDP с нулевой контрольной суммой с туннельным протоколом. [13]

Псевдозаголовок IPv4

Когда UDP работает поверх IPv4, контрольная сумма вычисляется с использованием псевдозаголовка , который содержит часть той же информации из реального заголовка IPv4 . [7] : 2  Псевдозаголовок не является реальным заголовком IPv4, используемым для отправки пакета IP, он используется только для вычисления контрольной суммы. Вычисление контрольной суммы UDP является необязательным для IPv4. Если контрольная сумма не используется, ее следует установить на нулевое значение.

Контрольная сумма рассчитывается по следующим полям:

Исходный адрес: 32 бита
Исходный адрес из заголовка IPv4.
Адрес назначения: 32 бита
Адрес назначения из заголовка IPv4.
Нули: 8 бит; Нули == 0
Все нули.
Протокол: 8 бит
Значение протокола для UDP: 17 (или 0x11 ).
Длина UDP: 16 бит
Длина заголовка UDP и данных (измеряется в октетах).

Псевдозаголовок IPv6

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

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

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

Контрольная сумма вычисляется по следующим полям:

Исходный адрес: 128 бит
Адрес в заголовке IPv6.
Адрес назначения: 128 бит
Конечный пункт назначения; если пакет IPv6 не содержит заголовка маршрутизации, TCP использует адрес назначения в заголовке IPv6, в противном случае на исходном узле он использует адрес в последнем элементе заголовка маршрутизации, а на принимающем узле он использует адрес назначения в заголовке IPv6.
Длина UDP: 32 бита
Длина заголовка UDP и данных (измеряется в октетах).
Нули: 24 бита; Нули == 0
Все нули.
Следующий заголовок: 8 бит
Значение протокола транспортного уровня для UDP: 17 .

Надежность и контроль перегрузок

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

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

Приложения

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

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

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

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

Сравнение UDP и TCP

Transmission Control Protocol — это протокол, ориентированный на соединение, который требует установления связи для установки сквозной связи. После установки соединения пользовательские данные могут отправляться по нему в двух направлениях.

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

Стандарты

Смотрите также

Ссылки

  1. ^ Справочник по сетевым продажам и услугам . 2003. ISBN 9781587050909.
  2. ^ Командная строка Windows: персональный тренер для Windows 8.1 Windows Server 2012 и Windows Server 2012 R2 . 2015. ISBN 9781627164139.
  3. ^ abc Куроуз, Дж. Ф.; Росс, К. В. (2010). Компьютерные сети: подход сверху вниз (5-е изд.). Бостон, Массачусетс: Pearson Education. ISBN 978-0-13-136548-3.
  4. ^ Кларк, MP (2003). Сети передачи данных IP и Интернет, 1-е изд . Западный Сассекс, Англия: John Wiley & Sons Ltd.
  5. ^ [email protected] (15 августа 2006 г.). "Обзор протокола UDP". Ipv6.com . Получено 17 августа 2011 г. .{{cite web}}: CS1 maint: numeric names: authors list (link)
  6. ^ abcde Forouzan, BA (2000). TCP/IP: Protocol Suite, 1-е изд . Нью-Дели, Индия: Tata McGraw-Hill Publishing Company Limited.
  7. ^ abcde J. Postel , ред. (28 августа 1980 г.). Протокол пользовательских датаграмм. IETF . doi : 10.17487/RFC0768 . STD 6. RFC 768. Стандарт Интернета 6.
  8. ^ Стивенс, В. Ричард (1994). TCP/IP Illustrated: The protocols . Том 1 (2-е изд.). Addison-Wesley. ISBN 978-0-20-163346-7.
  9. ^ D. Borman; S. Deering ; R. Hinden (август 1999). IPv6 Jumbograms. Сетевая рабочая группа. doi : 10.17487/RFC2675 . RFC 2675. Предложенный стандарт. Отменяет RFC 2147.
  10. ^ ab S. Deering ; R. Hinden (июль 2017 г.). Спецификация интернет-протокола версии 6 (IPv6). IETF . doi : 10.17487/RFC8200 . STD 86. RFC 8200. Интернет-стандарт 86. Устаревший RFC 2460.
  11. ^ "Вычислить 16-битную сумму с дополнением до единиц". mathforum.org . John. 20 марта 2002 г. Архивировано из оригинала ( электронная почта ) 17 ноября 2020 г. Получено 5 ноября 2014 г.
  12. ^ Спецификация протокола Интернета версии 6 (IPv6). стр. 27-28. doi : 10.17487/RFC8200 . RFC 8200.
  13. ^ Спецификация протокола Интернета версии 6 (IPv6). стр. 23. doi : 10.17487/RFC8085 . RFC 8085.
  14. ^ "Влияние UDP на приложения данных". Networkperformancedaily.com. Архивировано из оригинала 31 июля 2007 г. Получено 17 августа 2011 г.
  15. ^ "QUIC, мультиплексный потоковый транспорт по UDP". chromium.org . Получено 17 февраля 2021 г. .

Внешние ссылки

В Викиверситете есть обучающие ресурсы по протоколу пользовательских датаграмм