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

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

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

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

Атрибуты

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

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

Порты

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

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

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

Заголовок дейтаграммы UDP
СмещенияОктет0123
ОктетКусочек 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0Исходный портПорт назначения
432ДлинаКонтрольная сумма

Дейтаграмма 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
СмещенияОктет0123
ОктетКусочек012345678910111213141516171819202122232425262728293031
00Исходный IPv4-адрес
432IPv4-адрес назначения
864НулиПротоколДлина UDP
1296Исходный портПорт назначения
16128ДлинаКонтрольная сумма
20160+Данные

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

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

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

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

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

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

Формат псевдозаголовка IPv6
СмещенияОктет0123
ОктетКусочек012345678910111213141516171819202122232425262728293031
00Исходный IPv6-адрес
432
864
1296
16128IPv6-адрес назначения
20160
24192
28224
32256Длина UDP
36288НулиСледующий заголовок = Протокол[10]
40320Исходный портПорт назначения
44352ДлинаКонтрольная сумма
48384+Данные

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

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

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

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

Приложения

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

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

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

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

Смотрите также: Транспортный уровень

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

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

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

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

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

Примечания и ссылки

Примечания

  1. ^ а б c Kurose, J. F .; Росс, К. В. (2010). Компьютерные сети: подход сверху вниз (5-е изд.). Бостон, Массачусетс: Образование Пирсона. ISBN  978-0-13-136548-3.
  2. ^ Кларк, М. (2003). Сети передачи данных IP и Интернет, 1-е изд.. Западный Суссекс, Англия: John Wiley & Sons Ltd.
  3. ^ [email protected]. «Обзор протокола UDP». Ipv6.com. Получено 17 августа 2011.
  4. ^ а б c d е ж Форузан, Б.А. (2000). TCP / IP: Protocol Suite, 1-е изд.. Нью-Дели, Индия: Tata McGraw-Hill Publishing Company Limited.
  5. ^ RFC  2675
  6. ^ а б Диринг С. и Хинден Р. (декабрь 1998 г.). «Спецификация Интернет-протокола версии 6 (IPv6)». Инженерная группа Интернета. RFC  2460.
  7. ^ а б c d Постел, Дж. (Август 1980 г.). Протокол пользовательских датаграмм. Инженерная группа Интернета. Дои:10.17487 / RFC0768. RFC 768.
  8. ^ «Вычислить 16-битную сумму дополнения до единицы» (электронное письмо ). mathforum.org. Джон. 20 марта 2002 г.. Получено 5 ноября 2014.
  9. ^ Спецификация Интернет-протокола версии 6 (IPv6). п. 27-28. Дои:10.17487 / RFC8200. RFC 8200.
  10. ^ Значение поля Next Header - это значение протокола для UDP.
  11. ^ «Влияние UDP на приложения данных». Networkperformancedaily.com. Архивировано из оригинал 31 июля 2007 г.. Получено 17 августа 2011.

Ссылки на RFC

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

внешняя ссылка