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

UDP (протокол дейтаграмм пользователя)
Семья: Семейство интернет-протоколов
Область деятельности: Передача
данных через Интернет без установления соединения
UDP в стеке протоколов TCP / IP :
заявление DNS DHCP ...
транспорт UDP
Интернет IP ( IPv4 , IPv6 )
Доступ к сети Ethernet Жетон
автобус 		Маркерное
кольцо 		FDDI ...
Стандарты: RFC 768 ( 1980 )

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

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

функциональность

UDP использует порты, чтобы разрешить отправку данных в правильную программу на целевом компьютере. Для этого каждая дейтаграмма содержит номер порта службы, которая должна принимать данные. Это расширение межсетевой передачи по Интернет-протоколу на межпроцессную передачу известно как мультиплексирование и демультиплексирование приложений.

Кроме того, UDP предлагает возможность проверки целостности путем отправки контрольной суммы . Это означает, что неправильно переданные дейтаграммы могут быть распознаны и отброшены.

характеристики

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

Поскольку соединение не требуется устанавливать до начала передачи, один или оба партнера могут начать обмен данными быстрее. Это особенно важно в приложениях, в которых требуется обмен небольшими объемами данных. Простые протоколы вопросов и ответов, такие как DNS (система доменных имен ), в основном используют UDP для разрешения имен, чтобы снизить нагрузку на сеть и, таким образом, увеличить пропускную способность данных. Трехэтапный как и с TCP ( протокол управления передачей ) для установления соединения будет генерировать ненужную нагрузку в этом случае .

Кроме того, незащищенная передача также предлагает преимущество небольших колебаний задержки передачи: если пакет теряется во время TCP-соединения, он автоматически запрашивается снова. Это требует времени, и поэтому время передачи может колебаться, что плохо для мультимедийных приложений. С VoIP z. B. Произойдут внезапные выпадения или буферы воспроизведения должны быть увеличены. С другой стороны, в случае услуг связи без установления соединения потерянные пакеты не останавливают всю передачу, а только снижают качество.

Теоретически максимальный размер дейтаграммы UDP составляет 65 535 байтов, поскольку длина поля заголовка UDP составляет 16 бит, а наибольшее число, которое может быть представлено 16 битами, составляет 65 535 (= 2 16 -1). Однако такие большие сегменты передаются по IP фрагментированными. На практике максимально возможная длина дейтаграммы UDP подвергается дополнительным ограничениям .

IP удаляет пакеты в случае ошибок передачи или перегрузки. Поэтому дейтаграммы могут отсутствовать. UDP не предлагает для этого никаких механизмов обнаружения или исправления, таких как TCP. В случае нескольких возможных маршрутов к месту назначения IP при необходимости может выбрать новые маршруты. Это означает, что в редких случаях возможно, что данные, отправленные позже, превзойдут данные, отправленные ранее. Кроме того, пакет данных, который был отправлен один раз, может приходить получателю несколько раз.

Дейтаграмма UDP

Помимо передаваемых пользовательских данных, также отправляется другая информация, которая всегда находится в начале сообщения UDP, в так называемом заголовке . Заголовок UDP состоит из четырех полей данных, каждое из которых имеет размер 16 бит :

немного 0 15-е 16 31 год
Исходный порт Порт назначения
длина Контрольная сумма
Данные
Формат заголовка дейтаграммы UDP
Исходный порт
указывает номер порта отправляющего процесса. Эта информация необходима для того, чтобы получатель мог ответить на посылку. Поскольку UDP не поддерживает соединение, исходный порт является необязательным и может быть установлен на значение «0» (в случае, если не ожидается никаких ответных пакетов, а только пакеты должны быть отправлены получателю).
Порт назначения
указывает, какой процесс должен получить пакет.
Längenfeld
определяет длину дейтаграммы, состоящей из данных и заголовка, в октетах . Наименьшее возможное значение - 8 октетов (или байтов). Поле длины определяет теоретический верхний предел 2 16 -1 = 65 535 байтов (8-байтовый заголовок + 65 527 байтов пользовательских данных). Фактически доступная длина пользовательских данных обусловлена ​​лежащим в основе IP-протоколом, однако, 65 507 байтов (65 535 - 8 байтов заголовок UDP - 20 байтов заголовок IP) при использовании IPv4 и 65 487 байтов (65 535 - 8 байтов заголовок UDP - 40 байтов. Заголовок IPv6)) при использовании IPv6 .
Поле контрольной суммы
также может быть отправлена 16-битная контрольная сумма . Контрольная сумма формируется с использованием так называемого псевдозаголовка, заголовка UDP и данных. Контрольная сумма не является обязательной, но почти всегда используется на практике, в противном случае она устанавливается на «0».
Поле данных
он содержит фактическую полезную нагрузку, также известную как полезная нагрузка . Поле является необязательным и теоретически может полностью отсутствовать, чего на практике никогда не бывает. Поле данных всегда состоит из четного числа октетов. Октеты, которые остаются свободными в конце, дополняются нулями.

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

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

Для генерации контрольной суммы UDP части этого IP-заголовка передаются в так называемый «псевдозаголовок». Он используется только для генерации контрольной суммы и не передается.

IPv4

В IPv4 псевдозаголовок имеет размер 12 октетов (96 бит) и состоит из IP-адреса источника (32 бита), IP-адреса назначения (32 бита), 8-битного пустого поля и 8-битного идентификатора протокола. (UDP имеет ID 17 ) и длина дейтаграммы UDP (16 бит):

немного 0 32 64 72 80 96
Исходный IP-адрес IP-адрес получателя 00000000 ID протокола Длина дейтаграммы UDP
Псевдо-заголовок IPv4

IPv6

В IPv6 псевдозаголовок имеет размер 40 октетов (320 бит). Он состоит из следующего:

немного 0 128 256 288 312 320
Исходный IP-адрес IP-адрес получателя Длина пакета верхнего уровня 0
(24 бит) 		Следующий заголовок
Псевдо-заголовок IPv6

Расчет контрольной суммы

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

  1. Установите поле контрольной суммы в заголовке UDP на 0000 0000 0000 0000.
  2. Сгенерируйте 32-битное число без знака для контрольной суммы, инициализируйте его нулями.
  3. Объедините непосредственно соседние байты пакета UDP в 16-битные блоки. Если последний блок меньше 16 бит, то заполняйте его нулями с конца, пока он не станет 16 битов.
  4. Сохраните результат сложения всех 16-битных блоков с переносом контрольной суммы.
  5. Объедините непосредственно соседние байты псевдозаголовка в 16-битные блоки.
  6. Сохраните результат сложения этих 16-битных блоков и предыдущую контрольную сумму с переносом контрольной суммы.
  7. Объедините непосредственно соседние байты контрольной суммы в два 16-битных блока, сложите их и сохраните результат с переносом контрольной суммы до тех пор, пока не закончится перенос в сложении.
  8. Старшие 16 бит 32-битной контрольной суммы теперь нули. Менее значимые биты - это фактическая контрольная сумма; сохраните это как 16-битное число без знака.
  9. Если это 16-битное число не все единицы, то сохраните его дополнение в заголовке UDP (как 1111 1111 1111 1111, так и его дополнение 0000 0000 0000 0000 символизируют число 0). В IPv4 UDP 0000 0000 0000 0000 также используется для сигнализации о том, что контрольная сумма не вычислена. Пакеты IPv6 UDP с контрольной суммой 0000 0000 0000 0000 недействительны ( RFC 6935 ).

Получатель сначала проверяет, состоит ли поле контрольной суммы полученного пакета только нулями. Если это так, он может оценить пакет как правильно полученный, поскольку контрольная сумма отсутствует. В противном случае он применяет алгоритм, описанный выше, к полученному пакету и связанному псевдозаголовку, пропускает последний шаг и добавляет самосчитанную контрольную сумму к контрольной сумме, полученной в поле контрольной суммы, что соответствует вычитанию из- за представления дополнения до единицы. . Если получатель получает 0 в результате сложения (или вычитания), он оценивает полученные данные как такие же, как отправленные.

UDP-Lite

Протокол облегченных пользовательских дейтаграмм (UDP-Lite) в соответствии с RFC 3828 является разновидностью UDP, особенно для передачи данных, где важна малая задержка, но допускаются меньшие ошибки. Так обстоит дело, например, с передачами аудио и видео в реальном времени , которые часто используют UDP в качестве транспортного протокола. Если бит в пакете данных UDP неисправен, все данные в пакете, т.е. ЧАС. до нескольких тысяч бит, отброшенных. Если, с другой стороны, использовался пакет с ошибочным битом, ошибка была бы неслышной или невидимой , в зависимости от кодека . Использование UDP-Lite должно подавлять проверку определенных частей пакетов данных нижними уровнями, эффективно только для пакетов UDP-Lite. На уровне Ethernet это влияет на проверку CRC пакетов.

UDP-Lite совместим с UDP, но интерпретирует поле длины как длину, по которой вычисляется контрольная сумма ( покрытие контрольной суммы ). Обычный пакет UDP всегда соответствует спецификациям UDP-Lite. И наоборот, это не обязательно так, поскольку UDP-Lite определяет более высокую степень свободы. Длина пакета UDP или UDP-Lite может быть рассчитана с использованием информации уровня Интернет-протокола ; длина IP - это сумма размера заголовка IP и размера пакета UDP. Если IP-заголовок в UDP-Lite длиннее, чем в поле длины заголовка UDP (-Lite), пакет содержит дополнительные непроверенные данные. Например, поле длины восемь означает, что контрольная сумма вычисляется только с использованием заголовка. При нулевом значении контрольная сумма вычисляется по всему пакету. Значения 1,…, 7 недопустимы, т.е. ЧАС. заголовок UDP-Lite всегда включается в контрольную сумму. Ограничение максимального размера пакета от UDP (65 535 байт) больше не применяется. В этом случае контрольная сумма может быть вычислена либо для всего пакета, либо, самое большее, для первых 65 535 байт.

Характеристики

  • RFC 768 Протокол пользовательских дейтаграмм
  • RFC 3828 Протокол облегченных дейтаграмм пользователя (UDP-Lite)

Смотри тоже

веб ссылки

Индивидуальные доказательства

  1. ↑ RFC 5405 - Рекомендации по использованию одноадресного UDP.
  2. ↑ RFC 768 - Протокол дейтаграмм пользователя. (Английский, PDF: tools.ietf.org ).