stringtranslate.com

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

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

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

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

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

Атрибуты

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

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

Порты

Приложения могут использовать сокеты датаграмм для установления связи между хостами. Приложение привязывает сокет к своей конечной точке передачи данных, которая представляет собой комбинацию 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 только поле порта источника является необязательным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

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

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

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

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

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

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

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

Стандарты

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

Рекомендации

  1. ^ abc Куросе, JF; Росс, К.В. (2010). Компьютерные сети: нисходящий подход (5-е изд.). Бостон, Массачусетс: Pearson Education. ISBN 978-0-13-136548-3.
  2. ^ Кларк, член парламента (2003). Сети передачи данных IP и Интернет, 1-е изд . Западный Суссекс, Англия: John Wiley & Sons Ltd.
  3. ^ [email protected] (15 августа 2006 г.). «Обзор протокола UDP». IPv6.com . Проверено 17 августа 2011 г.{{cite web}}: CS1 maint: numeric names: authors list (link)
  4. ^ abcde Форузан, бакалавр (2000). TCP/IP: набор протоколов, 1-е изд . Нью-Дели, Индия: Tata McGraw-Hill Publishing Company Limited.
  5. ^ Стивенс, В. Ричард (1994). TCP/IP в иллюстрациях: протоколы . Том. 1 (2-е изд.). Аддисон-Уэсли. ISBN 978-0-20-163346-7.
  6. ^ Д. Борман; С. Диринг ; Р. Хинден (август 1999 г.). Джамбограммы IPv6. Сетевая рабочая группа. дои : 10.17487/RFC2675 . РФК 2675. Предлагаемый стандарт. Устаревший RFC 2147.
  7. ^ аб С. Диринг ; Р. Хинден (июль 2017 г.). Спецификация Интернет-протокола версии 6 (IPv6). IETF . дои : 10.17487/RFC8200 . СТД 86. RFC 8200. Интернет-стандарт 86. Устаревший RFC 2460.
  8. ^ abcd Постел, Дж. (август 1980 г.). Протокол пользовательских датаграмм. Рабочая группа по интернет-инжинирингу. дои : 10.17487/RFC0768 . РФК 768.
  9. ^ «Вычислить дополнительную сумму 16-битных единиц» . mathforum.org . Джон. 20 марта 2002 г. Архивировано из оригинала ( электронная почта ) 17 ноября 2020 г. Проверено 5 ноября 2014 г.
  10. ^ Спецификация Интернет-протокола версии 6 (IPv6). п. 27-28. дои : 10.17487/RFC8200 . РФК 8200.
  11. ^ Спецификация Интернет-протокола версии 6 (IPv6). п. 23. дои : 10.17487/RFC8085 . РФК 8085.
  12. ^ Значение поля «Следующий заголовок» — это значение протокола для UDP.
  13. ^ «Влияние UDP на приложения данных». Network Performancedaily.com. Архивировано из оригинала 31 июля 2007 года . Проверено 17 августа 2011 г.
  14. ^ «QUIC, передача мультиплексированного потока через UDP» . хромиум.орг . Проверено 17 февраля 2021 г.

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

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