Протокол передачи данных UDP (User Datagram Protocol) был определен IETF в 1980 году в документе [RFC768], Протокол UDP с точки зрения транспортного уровня является достаточно простым, в нем реализуются только лишь мультиплексирование и демультиплексирование потоков прикладного уровня, а также функция опредления ошибок.

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

• номера портов источника и приемника (source and destination port numbers), кроме адресации используемые, в том числе, и для мультиплексирования и демультиплексирования от/к прикладному уровню;

• поле «длина» (length) определяет длину сегмента UDP в байтах (включая и заголовок, и поле данных);

• поле «контрольной суммы длины сегмента» (checksum), позволяющее определять присутствие ошибок в сегменте, как в поле данных, так и в заголовке; Данные прикладного уровня помещаются в поле «данные».

Рис. 1.1. Структура сегмента UDP

Таким образом, может показаться, что использование протокола UDP для передачи данных (особенно учитывая существование протокола TCP) не востребовано. Однако это не так. UDP обладает рядом достоинств, делающих его очень привлекательным, в первую очередь, для приложений, не имеющих жестких требований по таким параметрам качества обслуживания, как вероятность потери пакета, задержка и джиттер задержки. Среди очевидных достоинств UDP необходимо выделить следующие:

• отсутствие фазы установления соединения: в отличие от TCP (см. ниже) передача данных может быть осуществлена сразу же после их поступления на транспортный уровень;

• отсутствие состояния соединения: UDP не отслеживает передачу сегментов, а просто осуществляет их передачу в той последовательности, в которой данные поступили с прикладного уровня; как только сегмент передан, он удаляется из памяти; кроме того, по сравнению с TCP, в UDP не реализуются такие дополнительные функции, как, например, «управление перегрузками»;

• малые накладные расходы: размер заголовка сегмента UDP равен всего 8 байтам, против 20 байт у TCP.

В табл. 1.1 представлены различные приложения и протоколы прикладного уровня и соответствующие им протоколы транспортного уровня. Как видно, протокол UDP используется в основном служебными протоколами прикладного уровня (SNMP, RIP, DNS и пр.) и мультимедийными услугами (Интернет-телефон, видео/телеконференция и пр.).‘ Применение UDP для потокового мультимедийного трафика предпочтительнее, чем TCP, в первую очередь, в связи с тем, что реакция этих приложений на работу функции «управления перегрузками» может быть неадекватна и грозит существенным ухудшением качества предоставления услуги. Однако, отсутствие каких-либо алгоритмов управления перегрузками в протоколе UDP также потенциально может вызвать проблемы, поэтому был предложен ряд новых механизмов, позволяющих осуществлять адаптивное управление нагрузкой, созаваемой, в том числе, и потоками UDP [Mahdavi97, FloydOO].

Отметим, что на самом деле применение UDP вовсе не накладывает ограничение на применение протоколов гарантированной доставки данных на прикладном уровне (см. п. 1.4.1 данной главы). Как правило, такие протоколы являются разработками фирм-производи-телей программного обеспечения и носят общее название «корпоративных» (proprietary protocols).

Приложения и протоколы прикладного уровня и соответствующие им протоколы транспортного уровня Таблица 1.1

⇐Интерактивные потоковые аудио и видеоприложения | Управление трафиком и качество обслужевания в сети | Протокол tcp⇒