Мультимедиа в Internet

ТЕХНОЛОГИИ

Нелегко определить, какая сеть  -  TCP/IP или ATM  -  окажется оптимальной средой для мультимедиа

Чтобы облегчить управление сетью и ее обслуживание, проведение видеоконференций и совместных разработок в группах, многие компании надеются использовать свои обычные сети обмена данными также и для передачи голоса и видеосигналов. Но разве может какая-либо одна сеть удовлетворить радикально отличающиеся потребности этих видов связи?

С одной стороны, набор протоколов TCP/IP  -  это основа жизни Internet. Но поскольку он спроектирован так, чтобы обеспечивать надежную доставку информации в правильной последовательности, входящие в TCP/IP механизмы контроля ошибок и управления потоком могут вносить искажения при передаче аудиоинформации и других мультимедиа-данных в реальном времени, для обеспечения которой необходимо посылать поток данных с задержками всего в несколько миллисекунд.

С другой стороны, технология ATM предлагает возможность передачи как мультимедиа-информации, так и компьютерных данных по одной и той же сети. Ее архитектура, ориентированная на соединения, позволяет приложениям задавать требуемую для передачи пропускную способность и характеристики обслуживания, после чего сеть соответствующим образом распределяет доступную полосу пропускания. В результате, учитывая сегодняшнюю популярность TCP/IP, объем инсталлированной базы TCP/IP-сетей, а также затраты на переход к сетям ATM, компании предпочитают максимально использовать тот потенциал, который у них уже есть.

Используя возможности TCP/IP

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

Если данные прибывали в неправильном порядке, нужно было применить специальные протоколы, чтобы расположить их в должной последовательности. Когда данные терялись, источнику передавались запросы на повторную передачу недостающих фрагментов.

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

Некоторые мультимедиа-пакеты, например приложения для работы с потоками аудио- и видеоданных, предлагаемые такими компаниями, как Progressive Networks, Xing Technology и VDONet, обладают возможностями, необходимыми для обеспечения работы в сети TCP/IP. Но чтобы эффективно работать в ней, эти приложения вынуждены сжимать данные для передачи и до минимума снижать потребность в полосе пропускания, а это, в свою очередь, влияет на качество звука и/или изображения. Для увеличения пропускной способности такие приложения также используют в сочетании с IP протокол UDP (User Datagram Protocol  -  протокол пользовательских дейтаграмм), а не TCP, что позволяет им обходиться без обязательного подтверждения приема.

До настоящего времени технологии передачи потоков, используемые этими компаниями, не могли работать совместно. Однако благодаря недавно предложенному протоколу RTSP (Real Time Streaming Protocol  -  протокол передачи потоков в реальном времени) положение, вероятно, изменится. RTSP, предназначенный для управления несколькими сеансами доставки данных, обеспечивает возможность выбора каналов доставки  -  UDP, UDP с многоадресной передачей (multicast UDP) и TCP  -  и механизмов доставки, основанных на стандарте RTP (Real-time Transport Protocol  -  протокол транспорта реального времени).

Об IETF, TCP/IP и ATM

Другой, более гибкий подход к совместной работе продуктов был принят IETF (Internet Engineering Task Force  -  группой инженерной поддержки Internet) в разработанной ею модели IIS (Internet Integrated Services  -  интегрированные службы Internet).

Наряду с протоколом RTP, поддерживающим правильную последовательность пакетов в процессе передачи, эта модель охватывает также другие протоколы, связанные с мультимедиа, в том числе RTCP (Real-time Transport Control Protocol  -  протокол управления транспортом реального времени) и RSVP (Resource Reservation Protocol  -  протокол резервирования ресурсов).

Протокол RTCP, дополняющий RTP, обеспечивает обратную связь и дает информацию о текущем состоянии сети, что позволяет приложениям адаптироваться к проблемам полосы пропускания или задержкам. Например, если пользователь подключен по каналу

ISDN, приложение видеоконференции может "попросить" использовать при передаче сигнала более эффективный алгоритм сжатия, чем тот, что применяется пользователями, связанными сетью Ethernet.

RSVP ориентирован на динамическое резервирование для сеанса сетевых ресурсов, например полосы пропускания. Именно этот протокол нужен, чтобы гарантировать уровень QoS (Quality of Service  -  качество обслуживания) в Internet аналогично тому, как гарантии качества QoS предлагает пользователям ATM-технология.

Четыре класса обслуживания RSVP напоминают три из четырех категорий скорости ATM. RSVP-класс Guaranteed Delay (гарантированная задержка), сходный с ATM-категорией CBR (Constant Bit Rate  -  постоянная скорость передачи) для приложений реального времени, задает максимальную задержку передачи данных по сети. Предназначенные для приложений, допускающих позднее прибытие некоторых пакетов, RSVP-классы Controlled Delay (управляемая задержка) и Predictive Service (обслуживание с прогнозированием) предлагают многие возможности ATM-категории VBR (Variable Bit Rate  -  переменная скорость передачи), например позволяют задать определенные временные рамки задержки. Четвертый класс обслуживания, Controlled Load (управляемая нагрузка), обеспечивает обслуживание с "максимальным усилием" при передаче данных по незагруженным сетям. Он похож на ATM-категорию UBR (Unspecified Bit Rate  -  неопределенная скорость передачи).

Стоит отметить, что RSVP не содержит класса обслуживания, эквивалентного новейшему варианту обслуживания в ATM  -  ABR (Adjustable Bit Rate  -  регулируемая скорость передачи). ABR позволяет сетям ATM максимально использовать свободную полосу пропускания для соединений, не требующих постоянной полосы пропускания. Однако для управления ABR-трафиком необходима сложная система обеспечения обратной связи, реализовать которую, так же как и управлять ею, скорее всего, окажется делом весьма трудным.

Поскольку реализация RSVP в маршрутизаторах началась лишь недавно, способная поддерживать этот протокол инфраструктура распространена пока не очень широко. Хост-компьютеры и маршрутизаторы нелегко модифицировать для поддержки RSVP, если они не в состоянии поддерживать несколько очередей данных так, чтобы данные с низким приоритетом сохранялись во время передачи данных реального времени. Это означает, что широкое развертывание RSVP, вероятно, потребует замены многих сетевых устройств.

Чтобы технологии мультимедиа смогли работать в Internet, необходимо еще одно условие  -  многоадресная передача (multicasting). Занимая промежуточное положение между одноадресной передачей (unicasting) потока данных каждому из определенных получателей и общей передачей (broadcasting) всех данных всем пользователям, многоадресная передача подразумевает одновременную передачу данных заданному подмножеству пользователей в сети.

Построение инфраструктуры

Но хотя многоадресная передача сводит к минимуму расход полосы пропускания на передачу мультимедиа-трафика, в Internet пока не полностью развернута сетевая инфраструктура, которая позволяла бы пользователям подключаться к сеансам передачи, а ведущим (leaders)  -  динамически управлять участниками этих сеансов. Работа над некоторыми протоколами, помогающими маршрутизаторам работать с множественной передачей, пока не закончена, а поддержка этого типа передачи в ATM также еще разрабатывается.

В связи с началом реализации протоколов, поддерживающих мультимедиа в Internet, разработчики приложений спешат ввести в свои программы поддержку этих протоколов и удовлетворить другие требования, предъявляемые при работе с мультимедиа.

До недавнего времени программы могли использовать лишь закрытые интерфейсы для управления QoS как в ATM, так и в RTP/RSVP. Сегодня в роли великого интегратора для поддержки сетевых приложений мультимедиа, скорее всего, выступит спецификация Winsock 2.0. Она избавляет разработчиков от необходимости вызывать, скажем, функции QoS, специфические для ATM или RSVP. Winsock 2.0 поддерживает RSVP, ATM и любую другую схему управления QoS, отображая их на обобщенный интерфейс QoS уровня приложения.

Сосуществование ATM и RTP/ RSVP позволило бы мультимедиа-приложениям работать в сетях IP и ATM, опираясь не только на спецификации ATM. Это также сделало бы не столь необходимой модернизацию всех маршрутизаторов для поддержки RSVP, потому что данные, попадающие в ATM-сеть, использовали бы полосу пропускания QoS, установленную ATM-соединением.

Консолидация и интеграция

Сейчас развертывание мультимедиа-систем реального времени в Internet сдерживается в основном из-за отсутствия необходимой инфраструктуры и возможностей взаимодействия различных схем.

Современные технологии передачи потоков данных, особенно разработанные для World Wide Web, в большинстве своем  -  частные. Однако предложенный протокол RTSP, а также архитектура RealMedia Architecture фирмы Progressive Networks представляют собой очередные шаги в направлении совершенствования совместной работы систем. Их преимущества должны стать очевидными в ближайшие полгода-год.

Реализация инфраструктуры маршрутизаторов для поддержки RSVP начинается лишь сейчас. Скорее всего, администраторы внутрикорпоративных сетей и поставщики услуг Internet уже в этом году первыми развернут новый протокол в ограниченном числе сетей. Обеспечить сопряжение использующих RSVP передач с сетями ATM не так то просто, здесь еще остается много проблем, так что интегрировать эти две технологии удастся, вероятно, не ранее чем через год.

Дэйв Косиур

Дэйв Косиур  -  независимый консультант по вопросам бизнеса и сетевых технологий из Рестона (шт. Виргиния). С ним можно связаться по адресу drkosiur@ix.netcom.com.