Резервирование ресурсов и протоколы управления потоком данных

Протокол UDP

UDP – это протокол, который работает поверх IP и предназначен для обслуживания доставки дейтаграмм. Поэтому протокол UDP не устанавливает виртуального соединения, не осуществляет никаких повторных передач, не выполняет переупорядочивания пакетов и не управляет потоком данных. Все эти функции возложены на приложения (или протоколы более высокого уровня). При этом некоторые приложения реализуют их весьма неэффективно. Например, протокол TFTP, который обычно используется для передачи конфигурационной информации на сетевые устройства (например, маршрутизаторы), имеет очень упрощенные алгоритмы повторной передачи и управления потоком данных – в случае возникновения проблем его действия сводятся к следующему принципу – «остановиться и ждать».

Протокол UDP активно используется в многофункциональных сетях, например, мультимедийными приложениями. А так как такие приложения не могут тратить время на повторную передачу, они используют функцию восстановления ошибок протокола TCP. Использование же протокола TCP вызывает трудности из-за того, что при этом не может быть обработан групповой трафик, и такие алгоритмы, как «Медленный старт» и «Предотвращение перегрузки», не подходят для трафика в реальном времени. Поэтому для передачи мультимедийной информации обычно применяется стандартный протокол RTP, работающий поверх UDP. Протокол RTP не исправляет ошибки и не участвует в управлении потоком данных, хотя имеет механизм обратной связи, организуемый с помощью протокола RTCP (он нужен для того, чтобы уменьшить скорость передачи при обнаружении ошибок). Механизм обратной связи первоначально используется приложением для того, чтобы получить часть полосы пропускания.

Отсутствие у протокола UDP механизмов управления потоком данных и обратной связи должно быть учтено для избежания появления различного рода проблем. К сожалению, зависимость протокола UDP исключительно от протоколов более высокого уровня типа RTP/RTCP не всегда приводит к достижению необходимых результатов, а порой просто ухудшает ситуацию. Это связано с тем, что упомянутые протоколы во многом схожи с протоколом TCP, то есть стремятся захватить как можно большую часть полосы пропускания.

Поскольку трафик проходит через сетевые устройства и соединения, большинство из которых имеют различные характеристики и скорости передачи, то его параметры могут быть искажены. Современные сети характеризуются высокоскоростной связью (например, локальные сети) на своих границах и магистралями малого быстродействия (например, региональные сети связи) в центре сети, в отличие от первых реализаций сетей с единьм достаточно низким диапазоном скоростей. Именно для таких сетей первоначально разрабатывалось большинство используемых сегодня транспортных протоколов. Современные сети можно представить в виде иерархии устройств. На нижнем уровне иерархии расположены многочисленные конечные станции, которые пересылают информацию на средний уровень иерархии, состоящий в основном из коммутаторов, а те, в свою очередь, передают информацию на еще более высокий уровень иерархии, реализованный на маршрутизаторах. При этом граничные устройства (коммутаторы и маршрутизаторы) могут не справляться с потоками данных, сгенерированными конечными станциями.

Трафик, проходящий от высокоскоростного уровня к более медленному, должен быть обработан устройством, расположенным на границе этих уровней. Если трафик прибывает слишком быстро, граничное устройство попытается сообщить источнику, что его скорость слишком велика и ее необходимо уменьшить. Эта идея и была первоначально заложена в сообщение «Source Quench» (подавление источника) протокола ICMP, которое теперь практически не используется. Такая схема оказалась слишком несправедливой, неэффективной и грубой при практическом применении. А без использования тех или иных механизмов сигнализации маршрутизаторы и коммутаторы в IP-сети вынуждены или отказываться от трафика, который не вписывается в канал с малым быстродействием, или пытаться временно буферизировать такой трафик.

Непрерывное управление потоком данных необходимо и для того, чтобы управлять передачей, если узкое место появляется на промежуточном переходе. Алгоритм протокола TCP «Предотвращение перегрузки» был разработан как раз для таких случаев, а именно, для ограничения скорости передачи и приведения ее в соответствие с эффективной шириной полосы пропускания наиболее нагруженного перехода. Но этот метод, применительно к широкополосным магистралям, стабилизирует скорость передачи слишком медленно и не использует полосу пропускания совместно с другими потоками.

Не так давно появились новые методы, реализованные, например, в протоколе резервирования ресурсов (RSVP). Они были разработаны для того, чтобы для определенных потоков трафика заранее запрашивать необходимый объем буферной памяти и требуемую ширину полосы пропускания, уменьшая вероятность переполнения буферного пространства или потерь пакетов. Однако эти методы не нашли применения в крупномасштабных сетях и имеют достаточное количество различного рода ограничений и проблем, которые сложно решить. Действительно, в сентябре 1997 года в документе RFC (ftp://ds.intemic.net/rfc/ rfc2208.txt) заявлено, что «...проблемы с масштабируемостью делают в настоящее время невозможным развертывание протокола RSVP в широкополосных сетях».

Дата добавления: 2015-07-13