37. Протокол транспортного рівня udp
Протокол 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
В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 - 8) байт, помещено сообщение DNS-сервера. Это можно видеть по номеру порта источника (Source Port = 0x0035), что в шестнадцатеричном формате равно стандартному номеру DNS-сервера — 53.
Судя по простоте заголовка, протокол UDP очень сложным не является. Действительно, его функции сводятся к мультиплексированию и демультиплексированию данных между сетевым и прикладным уровнями.
Рис. 19.2. Формирование дейтаграммы протокола UDP
Давайте рассмотрим, как протокол UDP решает задачу демультиплексирования.
Казалось бы, для этой цели достаточно использовать номера портов. Кадры, несущие UDP-дейтаграммы, прибывают на сетевой интерфейс хоста, последовательно обрабатываются протоколами стека и, наконец, поступают в распоряжение протокола UDP. UDP извлекает из заголовка номер порта назначения и передает данные на соответствующий порт соответствующему приложению, то есть выполняет демультиплексирование.
Это решение выглядит очень логично и просто, однако оно неработоспособно в ситуации, когда на одном конечном узле выполняется несколько копий одного и того же приложения. Пусть, например, на одном хосте запущены два DNS-сервера, причем оба используют для передачи своих сообщений протокол UDP (рис. 19.3). DNS-сервер имеет хорошо известный UDP-порт 53. В то же время у каждого из DNS-серверов могут быть свои клиенты, собственные базы данных, собственные настройки. Когда на сетевой интерфейс данного компьютера придет запрос от DNS-клиента, в UDP-дейтаграмме будет указан номер порта 53, который в равной степени относится к обоим DNS-серверам — так кому же из них протокол UDP должен передать запрос? Чтобы снять неоднозначность, применяют следующий подход. Разным копиям одного приложения, даже установленным на одном компьютере, присваивают разные IP-адреса. В данном примере DNS-сервер 1 имеет IP-адрес IP1, a DNS-сервер 2 — IP-адрес IР2. Таким образом, однозначно определяет прикладной процесс в сети (а тем более в пределах компьютера) пара (IP-адрес, номер порта UDP), называемая UDP-сокетом (UDP socket).
Таким образом, протокол UDP выполняет демультиплексирование на основе сокетов.
Рис. 19.3. Демультиплексирование протокола UDP на основе сокетов
Примечание. Здесь мы должны уточнить ту упрощенную картину прохождения пакета вверх по стеку, которая была описана ранее. Действительно, как мы и отмечали в предыдущих главах, после обработки поступившего из сети пакета протоколом IP заголовок этого пакета отбрасывается, и «наверх» передается содержимое поля данных IP-пакета, например UDP-дейтаграмма. Однако мы упускали одну важную деталь — вместе с содержимым поля данных на транспортный уровень передается извлеченный из заголовка IP-адрес назначения.