2.5.1 Протокол udp

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

Заголовок UDP, состоящий из четырех 2-х-байтовых полей, содержит номера пор­тов отправителя и получателя, контрольную сумму и длину дейтаграммы (рис.2.11) [24].

16 бит Порт источника	16 бит Порт приемника
16 бит Длина дейтаграммы	16 бит Контрольная сумма

Рис. 2.11 – Структура UDP-заголовка

Поле Порт источника (Source Port) занимает 2 байта и идентифицирует процесс-от­правитель.

Поле Порт приемника (Destination Port) занимает 2 байта и идентифицирует про­цесс-получатель.

Поле Длина дейтаграммы (Total Length) занимает 2 байта и представляет собой длину UDP-пакета вместе с заголовком.

Поле Контрольная сумма (Checksum) занимает 2 байта.

Ниже приведен пример заголовка UDP с заполненными полями:

1. Source Port = 0x0035 [порт источника].

2. Destination Port = 0x0411 [порт назначения].

3. Total length = 132 (0x84) bytes [длина UDP-заголовка].

4. Checksum = 0x5333 [контрольная сумма].

В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголов­ка, равна 132 байтам, помещено сообщение DNS-сервера. Это можно видеть по номеру порта источника (Source Port = 0x0035), что в шестнадцатеричном фор­мате равно стандартному номеру DNS-сервера 53.

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

Это решение выглядит очень логично и просто, однако оно неработоспособно в ситуации, когда на конечном узле выполняется несколько копий одного и того же приложения. Пусть, например, на одном хосте запущены два DNS-сер­вера, причем оба используют для передачи своих сообщений протокол UDP. DNS-сервер имеет хорошо известный UDP-порт 53. В то же время у каждого из DNS-серверов могут быть свои клиенты, собственные базы данных и настройки. Когда на сетевой интерфейс данного компьютера при­дет запрос от DNS-клиента, в UDP-дейтаграмме будет указан номер порта 53, который в равной степени относится к обоим DNS-серверам. Чтобы снять неоднозначность, используют следующий прием: разным копиям одного приложения, даже установ­ленным на одном компьютере, присваивают различные IP-адреса. В данном примере DNS-сервер₁ имеет IP-адрес IР₁, а DNS-сервер₂ – IP-адрес IР₂. Таким образом однозначно определяет прикладной процесс в сети (а тем более в пределах ком­пьютера) пара (IP-адрес, номер порта UDP), называемая UDP-сокетом (UDP socket), то есть протокол UDP выполняет демультиплексирование на основе сокетов [18].