Протокол UDP и UDP-дейтаграммы

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

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

Рис. 17.3. Работа протокола UDP на хосте-отправителе

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

Заголовок UDP состоит из четырех 2-байтных полей:

§ номер UDP-порта отправителя;

§ номер UDP-порта получателя;

§ контрольная сумма;

§ длина дейтаграммы.

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

Source Port - 0x0035

Destination Port - 0x0411

Total length - 132 (0x84) bytes

Checksum - 0x5333

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

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

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

Протокол TCP и ТСР-сегменты

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

При работе на хосте-отправителе протокол TCP рассматривает информацию, поступаю­щую к нему от прикладных процессов, как неструктурированный поток байтов (рис. 17.4). Поступающие данные буферизуются средствами TCP, Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом^[54] и снабжается заголовком.

Рис. 17.4. Формирование TCP-сегментов из потока байтов

 

ПРИМЕЧАНИЕ

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

 

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

Коротко поясним значение однобитных полей, называемых флагами, или кодовыми битами (code bits). Они расположены сразу за резервным полем и содержат служебную информацию о типе данного сегмента. Положительное значение сигнализируется уста­новкой этих битов в единицу:

§ URG — срочное сообщение;

§ АСК — квитанция на принятый сегмент;

§ PSH — запрос на отправку сообщения без ожидания заполнения буфера;

§ RST — запрос на восстановление соединения;

§ SYN — сообщение, используемое для синхронизации счетчиков переданных данных при установлении соединения;

§ FIN — признак достижения передающей стороной последнего байта в потоке пере­даваемых данных.

Рис. 17.5. Формат заголовка ТСР-сегмента