Функции и принципы работы протокола UDP
В этом разделе мы детально рассмотрим функции и принципы работы протокола UDP. При необходимости мы рекомендуем вам вернуться к разделу «Принципы работы протоколов прикладного уровня» в главе 2, где приведен обзор модели обслуживания UDP, а также к разделу «Программирование UDP-сокетов», в котором приведен пример приложения, использующего протокол UDP.
Представьте себе, что вам необходимо разработать максимально простой, без лишних функций, протокол транспортного уровня. Как бы вы стали решать эту задачу? Наиболее простым мыслимым способом является создание такого протокола, который не производит никаких действий с данными. На передающей стороне сообщения приложений без изменений передаются сетевому уровню, а на приемной стороне выполняется передача сообщений от сетевого уровня прикладному. Ясно, что такой протокол не является жизнеспособным: из предыдущего раздела следует, что протоколу как минимум необходимо выполнять операции мультиплексирования и демультиплексирования, обеспечивающие корректный обмен данными между сетевым уровнем и прикладными процессами.
Протокол UDP, описанный в документе RFC 768, выполняет минимум действий, необходимых для протокола транспортного уровня. Фактически функции UDP сводятся к операциям мультиплексирования и демультиплексирования, а также несложной проверке наличия ошибок в данных. Таким образом, при использовании U DP приложение почти напрямую взаимодействует с протоколом сетевого уровня IP.
UDP получает сообщения от прикладного уровня, добавляет к ним поля номеров портов отправителя и получателя для демультиплексирования приемной стороной, а также два других специальных поля и передает полученный сегмент сетевому уровню. Сетевой уровень заключает сегмент в дейтаграмму и «по возможности» передает ее хосту назначения. Если последний успешно получает сегмент, протокол UDP с помощью поля номера порта получателя направляет данные сегмента нужному процессу. Обратите внимание на то, что протокол UDP не предусматривает процедуры рукопожатия перед началом передачи сегментов. Поэтому говорят, что UDP осуществляет передачу данных без установления соединения.
Примером протокола прикладного уровня, использующего службы протокола UDP, является DNS. Когда DNS-приложение генерирует запрос, оно создает DNS-сообщение и передает его протоколу UDP. Не выполняя рукопожатия с хостом назначения, UDP добавляет к сообщению заголовочные поля и передает его сетевому уровню. Сетевой уровень заключает сообщение в дейтаграмму и передает ее серверу имен. DNS-приложение, создавшее запрос, ожидает ответа и в случае, если ответ не приходит (возможно, по причине потери запроса или ответа), генерирует запрос другому серверу имен либо информирует вызывающее приложение о том, что получение IP-адреса невозможно.
После приведенных выше рассуждений вполне уместным становится вопрос: есть ли у протокола UDP такие преимущества перед TCP, которые могут заставить разработчика создавать свое приложение с поддержкой UDP, а не TCP? Не удивительно, что ответ на этот вопрос положителен, и ниже перечислены четыре главные достоинства протокола UDP.
□ Отсутствие процедуры установления соединения. Как мы увидим позднее, протокол TCP перед началом передачи данных требует тройного рукопожатия. Протокол UDP освобожден от подобной «формальности» и поэтому не вносит дополнительную задержку в процесс передачи. Это является главной причиной для применения UDP прикладным протоколом DNS. Если бы DNS использовал службы TCP, процесс доставки IP-адресов был бы значительно более медленным. Протокол HTTP, напротив, задействует TCP, поскольку при доставке web-страниц, содержащих текстовую информацию, важно отсутствие искажений в передаваемых данных. Стоит заметить, что необходимость в установлении TCP-соединений вносит немалый вклад в задержку доставки необходимых объектов.
□ Отсутствие информации о состоянии соединения. Протокол TCP поддерживает информацию о состоянии TCP-соединения, что вызывает необходимость в наличии буферов для промежуточного хранения информации о приеме и передаче, параметров контроля перегрузки, порядковых номеров и номеров квитанций. Как мы увидим в разделе «Протокол TCP — передача с установлением соединения», информация о состоянии соединения необходима для реализации протоколом TCP служб надежной передачи данных и контроля перегрузки. UDP не поддерживает информацию о состоянии соединения, а следовательно, не требует учета перечисленных параметров. Это позволяет UDP-серверу одновременно обслуживать гораздо больше клиентов, чем ТСР-серверу.
□ Небольшой размер заголовка. Заголовок UDP-сегмента имеет длину всего лишь 8 байт, в то время как длина заголовка TCP составляет 20 байт.
□ Улучшенный механизм управления передачей данных приложением. При использовании протокола UDP данные, поступающие от приложения, сразу же упаковываются в сегмент и передаются сетевому уровню. Протокол TCP, располагая средствами контроля перегрузки, может приостановить процесс передачи сегмента вниз по стеку протоколов в случае, если на пути между отправителем и получателем имеются перегруженные линии связи. Кроме того, пересылка сегмента осуществляется протоколом до тех пор, пока не будет получено подтверждение о том, что адресат получил его (при этом затрачиваемое на пересылку время не учитывается). Поскольку приложения, работающие в реальном времени, обычно налагают ограничения на минимальную скорость передачи данных, не допускают значительных задержек сегментов, но в то же время то-лерантны к потере данных, службы протокола TCP малопригодны для таких приложений. Напротив, службы протокола UDP значительно лучше отвечают требованиям приложений реального времени, которые используют UDP в сочетании с собственными средствами обмена данными между процессами.
В таблице 3.1 представлены сведения о протоколах прикладного и транспортного уровней, используемых популярными Интернет-приложениями. Как и следовало ожидать, приложения электронной почты, web-приложения и приложения для передачи файлов строятся на основе протокола TCP, поскольку им необходима надежная передача данных. В сферу применения UDP входит протокол RIP, предназначенный для обновления информации таблиц маршрутизации, поскольку обновления, когда потерянная информация заменяется новой, носят периодический характер (сообщения генерируются приблизительно каждые 5 мин). UDP также используется для поддержки протокола сетевого администрирования SNMP выбор UDP в этом случае объясняется тем, что администрирующие приложения должны нормально функционировать при отклонениях от нормы в работе сети, то есть в ситуациях, когда надежная передача данных и контроль перегрузки могут серьезно ухудшить качество обслуживания. Протоколом UDP также поддерживается протокол DNS, поскольку UDP позволяет избежать дополнительных задержек на установление соединения. Кроме того, UDP используется почти всеми мультимедиа-приложениями: Интернет-телефонией, видеоконференциями в реальном времени, а также потоковыми аудио и видео.
Мультимедиа-приложения более детально рассматриваются в главе 6, здесь же только заметим, что эти приложения допускают потери небольшой доли пакетов, поэтому надежная передача данных не является для них необходимой. Кроме того, из-за затрат на контролирование перегрузки протоколом TCP значительно ухудшается качество функционирования приложений реального времени (видеоконференций и Интернет-телефонии). Эти причины обусловливают выбор протокола UDP для поддержки перечисленных приложений.
Несмотря на широкое применение протокола UDP для мультимедиа-приложений, вопрос о его рациональности, как минимум, остается открытым. Как известно, в UDP не предусмотрен контроль перегрузки. Контролирование перегрузки позволяет предотвратить возникновение такого состояния сети, когда большая часть ее работы выполняется «вхолостую». Например, если все пользователи Интернета одновременно станут просматривать потоковое видео с высоким качеством изображения, то процент потерянных вследствие перегрузки пакетов окажется таким большим, что в результате никто ничего не увидит. Таким образом, отсутствие механизмов контроля перегрузки потенциально представляет собой весьма серьезную проблему. Многие исследователи предлагают ввести механизмы, принуждающие все источники, передающие информацию (в том числе и приложения, поддерживаемые протоколом UDP), выполнять адаптивный контроль перегрузки.
Перед тем как перейти к изучению структуры UDP-сегмента, отметим, что надежная передача данных приложения возможна даже при использовании UDP. Это достигается путем включения механизмов обеспечения надежной передачи (например, квитирования и повторных передач, которые мы рассмотрим чуть позже) в само приложение. На практике данная задача часто оказывается весьма нетривиальной, и для создания корректно функционирующего приложения может потребоваться много времени. Вместе с тем обеспечение надежной передачи данных приложением позволяет «убить двух зайцев», удовлетворяя требование к обслуживанию процесса и предоставляя возможность преодолеть недостатки протокола TCP (например, более низкую скорость передачи). Подобным образом строится большинство современных потоковых приложений.