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

Протокол пользовательских датаграмм
Протокол связи
Аббревиатура	UDP
Разработчик(и)	Дэвид П. Рид
Введение	1980
Под влиянием	ВОЗ
Уровень OSI	Транспортный уровень (4)
RFC(ы)	РФК 768

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

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

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

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

Атрибуты

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

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

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

Порты

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

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

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

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

Заголовок датаграммы UDP
Смещения	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Исходный порт																Порт назначения
4	32	Длина																Контрольная сумма

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

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

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

Метод, используемый для вычисления контрольной суммы, определен в RFC 768, and efficient calculation is discussed in RFC 1071 :

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

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

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

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

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

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

Формат псевдозаголовка IPv4
Смещения	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Исходный IPv4-адрес
4	32	IPv4-адрес назначения
8	64	Нули								Протокол								Длина UDP
12	96	Исходный порт																Порт назначения
16	128	Длина UDP																Контрольная сумма
20	160+	Данные

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

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

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

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

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

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

Формат псевдозаголовка IPv6
Смещения	Октет	0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Исходный IPv6-адрес
4	32
8	64
12	96
16	128	IPv6-адрес назначения
20	160
24	192
28	224
32	256	Длина UDP
36	288	Нули																								Следующий заголовок = Протокол ^{[ 14 ]}
40	320	Исходный порт																Порт назначения
44	352	Длина																Контрольная сумма
48	384+	Данные

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

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

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

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

Приложения

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

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

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

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

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

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

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

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

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

Стандарты

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

См. также

Сравнение протоколов транспортного уровня
Безопасность транспортного уровня дейтаграмм (DTLS)
Список номеров портов TCP и UDP
Микротранспортный протокол (μTP)
Надежный протокол передачи данных (RDP)
Надежный протокол пользовательских датаграмм (RUDP)
Протокол передачи данных на основе UDP
UDP-флуд-атака
Адрес помощника UDP
Пробивка отверстий UDP
UDP-Lite – вариант, который доставляет пакеты, даже если они искажены.

Ссылки

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

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

[1] Справочник по сетевым продажам и услугам . 2003. ISBN 9781587050909 .

[2] Командная строка Windows: персональный тренер для Windows 8.1, Windows Server 2012 и Windows Server 2012 R2 . 2015. ISBN 9781627164139 .

[kuroseross-3] Jump up to: ^а ^б ^с Куросе, Дж. Ф.; Росс, К.В. (2010). Компьютерные сети: нисходящий подход (5-е изд.). Бостон, Массачусетс: Pearson Education. ISBN 978-0-13-136548-3 .

[clark-4] Кларк, член парламента (2003). Сети передачи данных IP и Интернет, 1-е изд . Западный Суссекс, Англия: John Wiley & Sons Ltd.

[5] [адрес электронной почты защищен] (15 августа 2006 г.). «Обзор протокола UDP» . IPv6.com . Проверено 17 августа 2011 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )

[forouzan-6] Jump up to: ^а ^б ^с ^д ^и Форузан, бакалавр (2000). TCP/IP: набор протоколов, 1-е изд . Нью-Дели, Индия: Tata McGraw-Hill Publishing Company Limited.

[7] Стивенс, В. Ричард (1994). TCP/IP в иллюстрациях: протоколы . Том. 1 (2-е изд.). Аддисон-Уэсли. ISBN 978-0-20-163346-7 .

[rfc2675-8] Д. Борман; С. Диринг ; Р. Хинден (август 1999 г.). Джамбограммы IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC2675 . РФК 2675 . Предлагаемый стандарт. Устаревшие РФК 2147 .

[rfc8200-9] Jump up to: ^а ^б С. Диринг ; Р. Хинден (июль 2017 г.). Спецификация интернет-протокола версии 6 (IPv6) . IETF . дои : 10.17487/RFC8200 . СТД 86. RFC 8200 . Интернет-стандарт 86. Устарел . РФК 2460 .

[rfc768-10] Jump up to: ^а ^б ^с ^д Постел, Дж. (август 1980 г.). Протокол пользовательских датаграмм . Рабочая группа по интернет-инжинирингу. дои : 10.17487/RFC0768 . РФК 768 .

[11] «Вычисление дополнительной суммы 16-битных единиц» . mathforum.org . Джон. 20 марта 2002 г. Архивировано из оригинала ( электронная почта ) 17 ноября 2020 г. Проверено 5 ноября 2014 г.

[12] Спецификация интернет-протокола версии 6 (IPv6) . п. 27-28. дои : 10.17487/RFC8200 . РФК 8200 .

[13] Спецификация интернет-протокола версии 6 (IPv6) . п. 23. дои : 10.17487/RFC8085 . РФК 8085 .

[14] Значение поля «Следующий заголовок» — это значение протокола для UDP.

[15] «Влияние UDP на приложения данных» . Network Performancedaily.com. Архивировано из оригинала 31 июля 2007 года . Проверено 17 августа 2011 г.

[Chromium-16] «QUIC, передача мультиплексированного потока через UDP» . хром.орг . Проверено 17 февраля 2021 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]