Состав udp-датаграммы

Первые 64 бита (8 байт) датаграммы представляют собой UDP-заголовок, остальные биты — данные сообщения:

Биты	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-31	Порт отправителя (Source port)																	Порт получателя (Destination port)
32-63	Длина датаграммы (Length)																	Контрольная сумма (Checksum)
64-...	Данные (Data)

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

Максимальная длина данных

Для вычисления максимальной длины данных в UDP-сообщении при передаче в IP сетях необходимо учесть, что UDP-сообщение в свою очередь является содержимым области данных IP-сообщения. Максимальная длина IP-сообщения (с учетом заголовка) равна 65535 октетов. Потому максимальная длина UDP-сообщения (за вычетом минимального IP-заголовка) равна 65535 − 20 = 65515 октетов.

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

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

Для расчета контрольной суммы псевдозаголовок и UDP-сообщение разбивается на слова (1 слово = 2 байта (октета) = 16 бит). Затем рассчитывается поразрядное дополнение до единицы суммы всех слов с поразрядным дополнением. Результат записывается в соответствующее поле в UDP-заголовке.

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

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

Если приложению требуется большая надёжность, то используется протокол TCP или SCTP.

UDP используется в следующих протоколах:

• DNS

• NFS

• DHCP

Протокол DCCP (Datagram Congestion Control Protocol; RFC-4336, -4340) является транспортным протоколом, который использует двунаправленные уникастные соединения с управлением перегрузкой для ненадежной доставки дейтограмм. Протокол DCCP предназначен для приложений, которые реализуют поточную схему TCP, но имеют приоритет для своевременной доставки данных с сохранением порядка кадров или требуют надежности, или которым нужен механизм подавления перегрузки, отличный от TCP. До настоящего времени такие приложения использовали либо TCP, чья надежность и гарантия упорядочения доставки давалась за счет неопределенно большой задержки, или UDP и независимого механизма управления перегрузкой (или вообще с отсутствием подавления перегрузки). Протокол DCCP будет предоставлять стандартный способ управления перегрузкой и позволит использовать механизм ECN (Explicit Congestion Notification).

Протокол DCCP предназначен для приложений, которые не требуют параметров SCTP [Stream Control Transmission Protocol, RFC 2960], таких как упорядоченная доставка при нескольких потоках.

Одной из целей DCCP было максимальное облегчение для UDP приложений перехода на DCCP, когда он будет внедрен. Чтобы облегчить это, DCCP был спроектирован с минимальной избыточностью, как с точки зрения размера заголовка пакета, так и с позиции загрузки ЦПУ машин партнеров. В DCCP была включена минимальная функциональность, при сохранении возможности включения новых функций, таких как FEC (Forward Error Correction), псевдонадежность и множественные потоки, которые могут быть добавлены поверх DCCP, если потребуется.

Протокол DCCP имеет следующие характеристики:

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

• Ненадежный диалог установления и разрыва соединения.

• Надежное согласование параметров.

• Выбор механизмов подавления перегрузки, дружественных по отношению к TCP, включая TCP-подобное управление перегрузкой (CCID 2) и управление потоком, дружественное TCP [RFC 3448] (CCID 3). CCID 2 использует разновидность TCP-механизма управления перегрузкой, и приемлемо для потоков, которые стремятся воспользоваться преимуществами доступной полосы, CCID 3 пригодно для потоков, которые требуют более стабильной скорости передачи.

• Опции, которые говорят отправителю с высокой надежностью, какие пакеты достигли получателя, были ли эти пакеты помечены ECN [RFC 3168 и RFC 3540], повреждены, или отброшены во входном буфере получателя.

• Управление перегрузкой, снабженное встроенной индикацией явной перегрузки ECN (Explicit Congestion Notification).

• Механизмы, позволяющие серверу избежать поддержки состояний неподтвержденных попыток соединений.

• Выявление MTU пути [RFC 1191].