Tcp протокол

Протокол UDP: что это и как работает?

Это Протокол UDP (протокол пользовательских дейтаграмм) является одним из основополагающих протоколов в Интернете, он позволяет приложениям взаимодействовать с гарантиями независимо от нижних уровней модели TCP / IP. Это означает, что маршрутизаторы (сетевой уровень в модели TCP / IP) должны только отправлять дейтаграммы (единица измерения в UDP). UDP поддерживает несколько протоколов прикладного уровня, таких как популярный DNS и даже протокол DHCP, для автоматического получения (и предоставления) IP-адресации.

основные черты

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

Этот протокол не обеспечивает какого-либо типа управления потоком Если одно устройство быстрее другого и отправляет информацию, вполне возможно, что информация будет потеряна, поскольку она будет разрушаться при самой низкой скорости, и нам придется перейти к пересылке информации

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

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

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

Заголовок UDP

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

UDP Port Scanner and Checker:

This tool identifies the available services running on the server. It used raw IP packets to check which ports and operating system are available and running. It also checks for the firewall in case if it blocks the port. Various tools are available in the market to scan the port and check which port is open and close. These tools run on the client and server machine simultaneously. They are available for cross platforms, including Windows, Mac, and Linux.

Check UDP port open in nmap

One of the most popular ways to check UDP port open or not is nmap.

#nmap -sU -p port target

This command is used to scan the UDP port. Ports to be scanned need to be specified where –sU activates UDP port scan.

For e.g. #nmap –sU –p 1-1023 192.168.1.1

In this example, the port range is from 1 to 1023 at the node 192.168.1.1. Also, instead of scanning the range of port, we can specify a specific port number. This will scan the port and check if the port is open or closed.

UDP port scan attack:

UDP port scan attack can occur when some attacker sends packets on your machine. This varies on the destination port. This can let attacker determine which server application service you are running and which operating system you have. You need not worry about this attack unless you have a firewall on your system to protect from the attackers.

Протокол UDP

Первой технологией, которая активно применялась в современном телевещании и с которой связывают термин «низкая задержка», было вещание мультикаст-трафика с MPEG Transport Stream содержимым по UDP. Обычно подобный формат выбирали в закрытых ненагруженных сетях, где вероятность потери пакетов сводилась к минимуму. К примеру, вещание с кодера на модулятор на головной станции — зачастую в рамках одной серверной стойки — либо IPTV-вещание по выделенной линии с усилителями и повторителями. Подобная технология используется повсеместно и показывает отличные показатели задержки. Российские компании достигали задержки на кодирование, передачу данных и декодирование с использованием сети Ethernet не более 80 мс при 25 кадрах/с.

Надёжность и решения проблемы перегрузок

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (Erasure code<span title=»Статья «Erasure code» в русском разделе отсутствует»>ru</span>_en).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Порты

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

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

Структура пакета

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

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

Порт получателя

Это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если хостом-получателем является клиент, то номер порта динамический, если получатель — сервер, то это будет «хорошо известный» порт.

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (232 — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной, превышающей 1500 байт, нужно проверять возможность такой связи опытным путём на конкретном оборудовании.

Контрольная сумма

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

Зачем сравнивать TCP или что с ним не так

• packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
• reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
• jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

RIPE Atlasбеспроводные сети популярны и нестабильны

• Более 80% пользователей используют беспроводной интернет;
• Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
• Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
• Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

• Беспроводные мобильные сети победили и нестабильны.
• TCP не до конца утилизирует канал в нестабильных сетях.
• Потребление контента зависит от скорости интернета: чем выше скорость интернета, тем больше пользователи смотрят, а мы очень любим наших пользователей и хотим, чтобы они смотрели больше.

TCP vs self-made UDP

• С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
• Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
• Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.

• Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
• Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

• бинарный, сжатие заголовков;
• мультиплексирование данных;
• приоритизация;
• возможна отмена загрузки;
• server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

• Профилях сети: Wi-Fi, 3G, LTE.
• Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

• пакеты 1 и 2 уже отправлены, для них получено подтверждение;
• пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
• остальные пакеты находятся в очереди.

Вывод:

Congestion control

• Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
• У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.

• Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
• Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.

• На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения. 
• Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой. 
• Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).

• Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
• BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

• BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор. 
• Cubic дожидается потери пакета и после этого схлопывает окно.

jitterHighLoad++

Какой Congestion control выбрать

Выводы про congestion control:

• Для видео всегда хорош BBR. 
• В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
• С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

SCTP[править]

SCTP (Stream Control Transmission Protocol — протокол передачи с управлением потока) — протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.

Отличия от протоколов TCP и UDP:

Основные преимущества (пояснения к таблице):

• Сохранение границ — в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
• Multihoming (многолинейность, множественная адресация, см. иллюстрацию ниже) — SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.

• Multithreading (многопоточность) — позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется head-of-line blocking, HOL. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
• 4-way handshake — протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: «я хочу установить соединение — ты точно хочешь установить соединение? — да, я точно хочу установить соединение — ну тогда ладно»). Таким образом за короткий промежуток времени нельзя создать много новых соединений.

В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.

К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе «пропускать только UDP, TCP» пакеты; для примера можно вспомнить, как это используется в NAT).

Приложения

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

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

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

Как это выглядит у нас внутри?

• Пользователи по одному из протоколов загружают оригинал видео на наши upload-сервера.
• Там мы разворачиваем протокол.
• По RTMP отправляем на один из серверов трансформации видео.
• Оригинал всегда сохраняем в распределенное хранилище, чтобы ничего не пропало.
• После этого все видео поступают на сервер раздачи.

• Upload-сервера распределены по разным дата-центрам, стоят за разными IP.
• Пользователи приходят, по DNS получают IP.
• Upload-сервер отправляет видео на серверы нарезки, те нарезают и отдают серверам раздачи.
• Под более популярные трансляции мы начинаем добавлять большее количество серверов раздачи.
• Все, что пришло от пользователя, сохраняем в хранилище, чтобы потом создать архив трансляций и ничего не потерять.
• Хранилище отказоустойчивое, распределенное по трем дата-центрам.

ZooKeeperЧто при этом произойдет?

• Пользователь на DNS возьмет следующий IP другого upload-сервера.
• К этому времени ZooKeeper поймет, что сервер в том дата-центре умер, и выберет для другой сервер нарезки.
• Download-серверы узнают, кто теперь отвечает за трансформацию этого стрима и будут это раздавать.

Протокол RIST

Через год после появления Альянса SRT компании, имеющие корпоративные решения в области IP-доставки, создали еще один альянс для разработки более продвинутой технологии. Новый протокол получил название Reliable Internet Stream Transport (RIST), как и сам альянс. Он организован в рамках консорциума Video Services Forum, занимающегося разработкой и стандартизацией сетевых технологий для передачи медиа. К слову, в этот альянс в качестве ключевого участника
и Haivision.

RIST задуман как многопрофильный стандарт, однако пока выпущен только базовый профиль. По функциональности он уступает SRT. В частности, не поддерживает мультиплексирование каналов на одном UDP-порту и имеет только один режим установления соединения (Push). В результате для передачи каждого потока приходится открывать по UDP-порту на приемнике и на передатчике. Кроме того, в отличие от SRT, базовый профиль RIST не поддерживает шифрование и файловую передачу. В то же время в протокол заложена передача множественных каналов. Она реализована в двух режимах. Один поддерживает разбиение логического канала на несколько физических, отправляемых разными маршрутами. Второй обеспечивает резервирование потоков и бесшовное переключение с одного на другой.

А схожи SRT и базовая версия RIST в том, что оба используют ARQ с настраиваемым соотношением между задержкой и защищенностью. Кроме того, они практически одинаковы в плане мониторинга потоков и сбора статистики. Однако у RIST есть все шансы опередить конкурента. Уже подготовлен основной профиль протокола, и живую демонстрацию его работы можно было увидеть на IBC-2019. При разработке профиля учитывались разные сценарии его применения, в том числе дистанционные интервью, сбор новостей из удаленных точек, передача видео в облако и передача мультикастовых трансляций.

Перечислим основные усовершенствования, появившиеся в этом профиле. Во-первых, добавилась поддержка мультиплексирования потоков на одном UDP-порту. Во-вторых, реализовано GRE-туннелированние (Generic Routing Encapsulation). GRE-шлюзы могут использоваться для организации двухстороннего обмена между RIST-устройствами базовой версии, умеющими взаимодействовать только в режиме Push. Шлюзы также могут применяться для передачи управляющих данных, например SNMP, для туннелирования мультикастового трафика и решения других задач. В-третьих, добавлены механизмы скремблирования, авторизации и аутентификации. Для скремблирования и авторизации выбран протокол DTLS, другими словами, версия TLS для UDP-протокола. Она адаптирована для приложений, чувствительных к временным задержкам. В рамках TLS могут использоваться разные алгоритмы шифрования, но в качестве основных для RIST предложены AES 128/256 бит.

Из других улучшений отметим оптимизацию транспортной полосы за счет исключения нулевых пакетов. Они не несут информации, но нужны для сохранения синхронизации. Поэтому перед передачей они заменяются метками и восстанавливаются на приемной стороне. Кроме того, добавлена возможность расширить заголовок RTP для увеличения цикла нумерации пакетов. Эта нумерация используется в ARQ при запросе потерянных пакетов, а при высокой скорости передачи стандартного цикла может не хватить.

Перспективы сосуществования SRT и RIST пока непонятны. С учетом того, что Haivision оказался одним из основных участников RIST, не исключен вариант слияния протоколов. Но может быть, каждый из них найдет свою нишу. Ясно одно — транспортные технологии для передачи видео через IP-сети с негарантированным качеством будут и дальше активно развиваться, а их доля во всех сегментах передачи медиа будет расти.

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

Метод, используемый для вычисления контрольной суммы, определен в RFC   :

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

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

Разница между IPv4 и IPv6 заключается в псевдозаголовке, используемом для вычисления контрольной суммы, а контрольная сумма не является необязательной в IPv6.

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

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

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

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

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

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

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

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