Протокол UDP

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

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

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

Ниже приведен пример заголовка UDP с заполненными полями: Source Port = 0x0035 Destination Port = 0x0411 Total length = 132 (0x84) bytes Checksum = 0x5333

К протоколу IP

Рис. 19.2. Формирование дейтаграммы протокола UDP

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

Судя по простоте заголовка, протокол UDP очень сложным не является. Дейст­вительно, его функции сводятся к мультиплексированию и демультиплексиро­ванию данных между сетевым и прикладным уровнями.

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

Это решение выглядит очень логично и просто, однако оно неработоспособно в ситуации, когда на одном конечном узле выполняется несколько копий одного и того же приложения. Пусть, например, на одном хосте запущены два DNS-сер­вера, причем оба используют для передачи своих сообщений протокол UDP (рис. 19.3). DNS-сервер имеет хорошо известный UDP-порт 53. В то же время у каждого из DNS-серверов могут быть свои клиенты, собственные базы данных, собственные иастройки. Когда на сетевой интерфейс данного компьютера при­дет запрос от DNS-клиента, в UDP-дейтаграмме будет указан номер порта 53, который в равной степени относится к обоим DNS-серверам — так кому же из них протокол UDP должен передать запрос? Чтобы снять неоднозначность, при­меняют следующий подход. Разным копиям одного приложения, даже установ­ленным на одном компьютере, присваивают разные IP-адреса. В данном примере DNS-сервер 1 имеет IP-адрес 1Р_Ь а DNS-сервер 2 — IP-адрес 1Р₂. Таким образом,
однозначно определяет прикладной процесс в сети (а тем более в пределах ком­пьютера) пара (IP-адрес, номер порта UDP), называемая UDP-сокетом (UDP socket).

Таким образом» протокол UDP выполняет демультиплексирование на основе сокетов,

IP-дейтаграмма

IP-адрес назначения IP2

UDP-дейтаграмма

__________________________________ >

Кадр

Рис. 19.3. Демультиплексирование протокола UDP на основе сокетов

ПРИМЕЧАНИЕ-----------------------------------------------------------------------------------------------------

Здесь мы должны уточнить ту упрощенную картину прохождения пакета вверх по стеку, которая была описана ранее. Действительно, как мы и отмечали в предыдущих главах, по­сле обработки поступившего из сети пакета протоколом IP заголовок этого пакета отбра­сывается, и «наверх» передается содержимое поля данных IP-пакета, например UDP- дейтаграмма. Однако мы упускали одну важную деталь — вместе с содержимым поля дан­ных на транспортный уровень передается извлеченный из заюловкз IP-адрес назначения.