Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

Подождите немного. Документ загружается.

420 Часть V. Web-приложения

ций, заложенных в НТТР/1.1. Кроме того, мы остановимся на различиях между

двумя протоколами, чтобы особо выделить коммуникационные требования потоко-

вых приложений. В ходе обсуждения RTSP также будет проиллюстрировано, как

различные мультимедийные протоколы совместно работают при доставке мульти-

медийных потоков.

12.1.

Мультимедийные потоки

Мультимедийные потоки отличаются от традиционных Web-ресурсов форма-

том данных и требованиями к производительности при доставке данных. В этом

разделе мы вкратце познакомимся с представлением аудио- и видеосодержания.

Затем мы рассмотрим различные приложения для работы с мультимедийными по-

токами, популярными в Internet. Затем мы определим общие требования, которые

эти приложения предъявляют к доставке мультимедийных потоков. Более деталь-

ное рассмотрение мультимедийных потоков можно найти в книгах [CHW99,

SROOj.

12.1.1.

Данные аудио и видео

в сравнении с традиционным Web-содержапием, приложения для доставки

мультимедийных потоков характеризуются сложными взаимодействиями между

потоками и внутри потоков. Например, поток видео состоит из последовательно-

сти изображений, или кадров, каждый из которых, в свою очередь, состоит из набо-

ра пикселов, как описано в таблице 12.1. Каждый пиксел, или элемент изображения,

соответствует небольшой прямоугольной области изображения. Размер изображе-

ния выражается в числе пикселов по каждому измерению. Изображение 640x480

имеет ширину в 640 пикселов и высоту в 480 пикселов. Цвет или яркость каждого

пиксела представляется числом. Например, реалистичное цветовоспроизведение

использует минимум 24 бита для каждого пиксела. Интенсивность каждого из ос-

новных цветов: красного, синего и зеленого, которая воспринимаются человече-

ским глазом, представляется восемью битами. Представление каждого пиксела в изо-

бражении требует большого объема дагтых

—

для изображения 640x480 с 24 битами

на пиксел потребуется более 7 мегабайтов (т.е. 640x480x24). К счастью, возможно

сжатие изображений путем устранения избыточности, например, больших облас-

тей,

закрашенных одним цветом. Форматы изображений, использующие сжатие,

такие как GIF или JPEG, весьма распространены в Web.

Таблица 12.1. Иерархия мультимедийного содержания

Термин

Пиксел

Кадр

Поток

Сеанс

Презентация

Описание |

Элемент изобрал<сения 1

Двухмерный набор пикселов |

Последовательность кадров, передаваемых за определенное время |

Синхронизированный набор потоков |

Набор мультимедийных сеансов

Глава

12.

Доставка мультимедийных потоков 421

Каждый кадр в видеопотоке соответствует неподвижному изображению, «вы-

хваченному» в определенный момент времени. Аудиопоток состоит из последова-

тельности звуков (сэмплов). Мультимедийный ноток перед отображением у полу-

чателя проходит через следующие стадии:

• Ввод и преобразование в цифровую форму. Поток аудио или видео должен

быть введен с аналогового устройства, такого как микрофон или видеокамера,

и преобразован в цифровую форму.

• Кодирование. Кодировщик преобразует исходные цифровые дагнпле в опре-

деленный аудио- или видеоформат. Кадры могут кодироваться по мере ввода,

не ожидая, пока будет введен весь поток.

• Хранение. Сервер может сохранять закодированный поток для дальнейшей

передачи.

• Доставка. Поток передается одному или нескольким получателям. «Живой»

ноток может передаваться по мере ввода и кодирования, тогда как сервером

передается записанный ранее поток.

• Декодирование. Получатель декодирует и отображает данные по мере их по-

лучения. Возможен и альтернативный вариант — получатель сохраняет весь

поток до начала его воспроизведения.

Получатель воспроизводит сэмплы или кадры способом, не допускающим обра-

зования паузы между ними. Чтобы отобразить поток видео с частотой 30 кадров

в секунду, медианлейер должен показывать новый кадр каждую 1/30 секунды. Ви-

деопотоки обычно состоят из большого объема дагн1ых. Для отображения тридцати

изображений 640x480 в секунду потребуется скорость передачи 210 Мбит/с. По-

добно изображениям н текстовым данным, мультимедийные потоки допускают

сжатие. Фактически аудио- и видеоданные дают дополнительную возможность для

сжатия — использование избыточной повторяемости в последовательности сэмп-

лов или кадров. Некоторые схемы видеокомпрессии генерируют кадры небольшого

объема, которые представляют собой различия между последовательными изобра-

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

объектов от одного кадра к другому. Эффективные технологии сжатия могут

уменьшить размер видеопотока в 25 или даже в 100 раз. К используемым в Web

видеоформатам относятся RealVideo, AVI (Audio Video Interleave), QuickTime и

MPEG (Moving Pictures Expert Group) [AS98J. Широко используются аудиоформа-

ты RealAudio, AU (Audio), WAV (Waveform Audio) и MPS (MPEG Audio Layer 3).

Кодирование потоков аудио и видео характерр1зуется принципиальным компро-

миссом между объемом данных и качеством их воспроизведения у пользователя.

Подобного компромисса нет при передаче традиционного текстового содержания.

Видеопотоки, доступные в Web, обычно характеризуются потерей качества во мно-

гих отношениях, а именно:

• Низкая частота кадров. Видеопоток с низкой частотой кадров воспринимает-

ся как прерывистая последовательность статических изображений. Частота

кадров меньше 24 или 30 кадров в секунду плохо воспринимается глазами.

Тем не менее, многие мультимедийные потоковые приложения используют

более низкую частоту кадров в пределах от 10 до 15 кадров в секунду.

• Малые размеры кадра. Большинство видеопотоков, доступных в Web, имеют

небольшие размеры кадра, обычно несколько дюймов в высоту и в ширину.

422 Часть V. Web-приложения

• Низкое разрешение. Отдельные кадры могут иметь низкое качество из-за из-

лишней зернистости изображения или вследствие избыточной компрессии

данных.

Потеря качества ведет к уменьшению объема данных в видеопотоке. Схожие ме-

тоды сжатия могут быть применены и к аудиоданным. На практике, однако, люди

более восприимчивы к потере качества аудиоинформации. Аудиопотоки требуют

гораздо меньшей скорости передачи данных, чем видеопотоки, что делает не столь

важной проблему снижения качества при уменьшении объема передаваемых дан-

ных.

Многие мультимедийные приложения работают не с одним потоком, а с не-

сколькими. Например, один мультимедийный сеанс может состоять из потока ау-

дио и потока видео. Хотя два потока могут использовать различные методы коди-

рования и сжатия, они связаны между собой во времени. Воспроизведение потоков

аудио и видео должно быть скоординированным, чтобы сохранить временные

свойства, присущие источнику. Медиаплейер должен воспроизводить каждый но-

ток с соответствующей скоростью, а звук и изображения должны быть синхрони-

зированы друг с другом. Наконец, мультимедийная презентация может состоять из

множества сеансов во времени, использующих различные участки экрана. Допус-

тим, университетский профессор читает лекцию удаленной аудитории через Inter-

net. Презегггация может включать видеоизображение и речь лектора, изображение

текущего поясняемого материала и видеоизображение аудитории, находящейся

в другом месте.

12.1.2.

Приложения для мультимедийных потоков

Имеется множество мультимедийных приложений для воспроизведения аудио

и видео по мере их поступления. Хотя многие из этих приложений существуют от-

дельно от Web, Web-браузеры предоставляют интерфейс для вызова этих прило-

жений. Желание поддерживать мультимедийные приложения оказало прямое

влияние на разработку протоколов для доставки мультимедийных потоков. К по-

пулярным классам мультимедийных потоков относятся следующие:

• Мультимедиа по запросу. В приложениях мультимедиа но запросу клиент

выдает запрос серверу на поток мультимедийного содержания для немедлен-

ного воспроизведения. Например, клиент может запросить видеоклип, ново-

сти или музыкальную композицию, воспроизвести данные по мере их поступ-

ления. Приложения мультимедиа по запросу следуют той же модели кли-

ент-сервер, которая обычно используется в Web. Пользователь может ини-

циировать запрос на мультимедийный сеанс, щелкнув на гипертекстовой

ссылке на Web-странице.

• Intemet-телефония. В технологиях IP-телефонии (IP telephony) и Голос через

IP (Voice over IP) пользователи общаются друг с другом в реальном времени.

Главным побудительным мотивом применения 1Р-телефо11ии является низкая

стоимость передачи аудиоданных через Internet и возможность интегрировать

телефонию с другими IP-приложениями. Как и в традиционной телефонной

сети, одна сторона инициирует вызов другой стороны. После установления со-

единения аудиоданные передаются в обоих направлениях. Каждый участник

исгюльзует приложение, которое кодирует и декодирует аудиоданные и взаимо-

действует с сетью. Пользователи могут говорить и слушать друг друга с помо-

щью своих компьютеров или с помощью обычных телефонных аппаратов.

Глава

12.

Доставка мультимедийных потоков 423

• Телеконференции. Близко связанные с IP-телефонией приложения для теле-

конференций предназначены для организации общения группы участников

между собой. В простейшем случае группа пользователей обменивается ау-

дио-

и, возможно, видеоинформацией в реальном времени. Приложение мо-

жет также поддерживать общее рабочее пространство, например, сетевую дос-

ку объявлений, а также функции управления аудиторией, например, предос-

тавление слова участнику конференции. Приложения для IP-телеконферен-

ций, такие как CU-SeeMe [Dor95J и средства vic/vat, используемые в МВопе

[Eri94J, предшествовали появлению Web.

• Радио/телевидение. Приложения для радио и телевидения дают возможность

пользователю настраиваться на определенную станцию или программу. Мгю-

жество пользователей по всему миру MOI^T одновреме1Н10 смотреть программу.

Подобно тому, как IP-телефония конкурирует с традиционной междугородней

телефонгюй связью, приложения для радио и телевидения в Internet предостав-

ляют альтернативу традиционным сетям радио и ТВ. Internet дает возможгюсть

поставщикам содержания расширить свою аудиторию при относительно низ-

ких затратах и без ограничений, например, на частотные диапазоны.

• Многопользовательские игры. Игровые приложения дают возможность группе

пользователей, находящихся в различных местах, участвовать в игре. Игровые

приложения обычно дают возможность пользователям вюпочаться в игру и вы-

ходить из нее, а также настраивать свое положение в игре. Например, пользова-

тель может перемещаться по игровому полю и взаимодействовать с другими иг-

роками на определенном расстоянии от текущего местонахождения.

• Виртуальная реальность. Подобгю игровым приложениям, виртуальная ре-

альность дает возможность пользователю перемещаться в виртуальном окру-

жении. Например, пользователь может совершить виртуальную прогулку по

городу, встречая на своем пути трехмерные изображения различных зданий.

Действия пользователя, такие как поворот налево или движение вперед, при-

водят к изменению того, что он видит. Некоторые приложения виртуалыюй

реальности позволяют нескольким пользователям участвовать в виртуальной

прогулке.

Протоколы доставки мультимедийных потоков пытаются учесть общие требова-

ния этих приложений, а также поддерживают сервисы, которые объединяют свой-

ственные приложениям различных классов возможности. Например, пользователь

может инициировать воспроизведение видеонотока в видеоконференции.

12,1.3.

Свойства мультимедийных приложений

Мультимедийные приложения обладают определенными характеристиками, ко-

торые имеют важное значение для передачи мультимедийных данных через Internet.

Начальная задержка. Как только получатель начинает воспроизведение муль-

тимедийного потока, последовательность кадров должна поступать к нему своевре-

менно. Однако передача потока через сеть связана с задержкой, которая может

варьироваться от одного пакета или кадра к другому. Получатель обычно вводит

задержку перед воспроизведением первого кадра, чтобы избежать прерывистого

воспроизведения потока, если последующие кадры прибудут с большой задержкой.

Плейер может выделить буфер для хранения поступивших данных. Мультимедий-

ные приложения сильно различаются по величине начальной задержки. Для неко-

торых приложений медиаплейер может ожидать поступления нескольких кадров,

424 Часть V. Web-приложения

прежде чем начать воспроизведение. Пользователь может не возражать относи-

тельно задержки в несколько секунд перед просмотром ранее записанного видеоно-

тока или прямого спортивного репортажа. В некоторых случаях пользователь мо-

жет согласиться подождать несколько часов перед просмотром видеоклипа, чтобы

дать возможность серверу передать данные с меньшей скоростью. Другие приложе-

ния, такие как телефония и распределенные игры, не могут себе позволить дли-

тельных задержек. Для таких интерактивных приложений задержка, превышающая

несколько сотен миллисекугщ, уже становится довольно ощутимой. Терпимость

к величине задержки зависит и от пользователей. Пользователи, активно участвую-

щие в телеконференции, не могут примириться с длительными задержками, тогда

как пользователи, являющиеся лишь слушателями телеконференции, могут пойти

на увеличение задержки до нескольких секунд в обмен на более высокое качество

или более низкую цену.

Создание содержания. Потоки в реальном времени кодируются и передаются

по мере их создания. В противоположность этому предварительно записанный но-

ток вводится и кодируется до начала передачи. Для предварительно записанных

потоков возможно более сильное сжатие, поскольку данные являются доступными

перед их передачей. Предварительно записанные потоки также предоставляют сер-

веру большую гибкость при передаче данных клиенту. Сервер может поддерживать

функции видеомагнитофона, включая паузу, перемотку и ускоренное воспроизве-

дение, которые дают возможность пользователю просматривать различные фраг-

менты предварительно записанных данных. Некоторые приложения комбинируют

содержание в реальном времени и предварительно записанное содержание. Телеви-

зионная станция, ведущая спортивный репортаж, может также осуществить запись

потока для повторного его воспроизведения в дальнейшем. В процессе просмотра

репортажа в реальном времени пользователь может решить записать оставшуюся

часть потока. Кроме того, предварительно записанное содержание, например теле-

визионная реклама, может быть вставлено в «живой» поток.

Число потребителей. Мультимедийные приложения различаются но числу по-

требителей. В простейшем случае пользователь посещает Web-сайт и запрашивает

предварительно записанный мультимедийный сеанс. Мультимедийный сервер пе-

редает запрошенные аудио- и видеонотоки пользователю. Другие приложения пре-

дусматривают двунаправленное взаимодействие. Например, большинство прило-

жений телефонии предполагает наличие двух участников, хотя на каждой стороне

имеется только один потребитель. В то же время трансляция прямого спортивного

репортажа может предназначаться сотням или даже тысячам потребителей. Пере-

дача мультимедийного потока множеству потребителей может вызвать существен-

ное повышение нагрузки на отправителя и на сеть. Групповое вещание (multicas-

ting) позволяет отправителю передавать одну копию потока множеству потребите-

лей. Потребители принимают данные, подписываясь на услугу группового

вещания, идентифицируемую по IP-адресу; сеть обеспечивает получение копии

данных потребителем. Для услуг группового вещания выделяется часть простран-

ства IP-адресов, о чем говорилось в главе 5 (раздел 5.1.3).

Инициирование сеанса. Мультимедийные приложения различаются и по спо-

собу инициирования 1юлучения потока пользователем. В приложениях мультиме-

диа но запросу пользователь может запросить сеанс, щелкнув на гипертекстовой

ссылке; сервер удовлетворяет запрос, инициируя передачу запрошенного потока

(потоков). В приложениях IP-телефонии пользователь может получить сообщение,

которое сигнализирует об установке соединения между двумя компьютерами.

Глава

12.

Доставка мультимедийных потоков 425

В определенный момент перед получением сигнального сообщения пользователь

должен выразить желание получать такие сообщения. Сторона, инициировавшая

вызов, должна иметь возможность обнаружения предполагаемого получателя и об-

мена сигнальными сообщениями. В противоположность этому приложение для те-

левизионного вещания может объявить о наличии группы вещания, ассоциирован-

ной с сеансом. Тем самым пользователям предоставляется необходимая информа-

ция, позволяющая им присоединиться к группе вещания для приема передачи

в соответствующее время.

12.2.

Доставка мультимедийного содержания

в противоположность традиционным дагншпм в виде текста и изображений,

мультимедийные потоки предъявляют строгие временные требования по доставке

информации получателю. В этом разделе рассматриваются требования к произво-

дительности приложений для доставки мультимедийных потоков. Затем мы обсу-

дим, почему эти требования трудно удовлетворить в традиционных IP-сетях. Нако-

нец, мы рассмотрим офаничения в применении HTTP в качестве протокола при-

кладного уровня для потоковых приложений.

12,2.1.

Требования к производительности

Доставка мультимедийных потоков предъявляет жесткие требования к произво-

дительности, отличные от тех, которые имеют место для текста и изображений.

Задержки. Пользователи Web испытывают задержку при загрузке текста и изо-

бражений. В некоторых случаях Web-браузер воспроизводит текст и изображения

по мере их поступления. Несмотря на некоторые неудобства для пользователей, за-

держка не оказывает влияния на качество содержания после его полного получе-

ния. Задержки порядка нескольких десятков или сотен миллисекунд не имеют су-

щественного значения для пользователя. Для мультимедийных потоков ситуация

иная. После начала воспроизведения аудио- или видеонотока последовательные

звуковые сэмплы или кадры должны поступать своевременно. В противном случае

медиаплейер должен компенсировать отсутствующие данные. Например, плейер

может сделать паузу в воспроизведении (ожидая поступления следующего кадра)

или повторить предыдущий кадр. В обоих случаях возникает прерывистое изобра-

жение или звук. Задержка в поступлении аудиопотоков приводит к еще более за-

метному снижению производительности. Медиаплейер обычно буферизует группы

кадров перед началом воспроизведения потока, чтобы компенсировать длительные

задержки при получении последующих кадров.

Потери. Сообщения-запросы и сообщения-ответы HTTP передаются целиком,

если только передача не прерывается. HTTP предполагает, что сообщения достав-

ляются надежным транспортным протоколом, например, TCP. Надежная доставка

не является главной целью для многих мультимедийных приложений, поскольку

повторная передача утерянного пакета может вызвать слишком большую задержку

в получении данных. Повторно переданный пакет вряд ли окажется полезным,

если он поступит после того, как медиаплейер отобразит соответствующий кадр.

Кроме того, медиаплейер не сможет получить последующие данные из буфера со-

кета до тех пор, пока потерянный пакет не будет успешно передан. Протокол User

Datagram Protocol (UDP) часто используется в качестве альтернативы TCP для

426 Часть V. Web-приложения

транспортировки мультимедийных потоков. Многие мультимедийные приложения

могут примириться с небольшими потерями данных. Например, видеоплейер мо-

жет восстановить отсутствующую часть кадра на основе ближайших пикселов

в этом кадре, либо наборов пикселов в предыдущем и последующем кадрах. Одна-

ко поскольку потери или задержки пакетов снижают качество потока, некоторые

приложения все же имеют ограниченную поддержку для восстановления утерян-

ных данных. Это обычно достигается посредством выборочной повторной передачи

потерянных пакетов отправителем или передачи некоторых избыточных данных,

чтобы помочь получателю восстановить потерянную информацию.

Скорость передачи. Большинство Web-ответов являются небольшими и имеют

средний размер от 8 до 12 килобайтов. В то же время потоки аудио и видео обычно

имеют достаточно большой размер. Передача потоков аудио и видео требует высо-

кой пропускной способности. Например, несжатое речевое сообщение телефонного

качества требует скорости передачи данных 64 Кбит/с; эффективная техника сжа-

тия может уменьшить требования к пропускной способности до 10 Кбит/с. Требо-

вания к пропускной способности для видеопотоков сильно варьируются в зависи-

мости от качества, частоты кадров, размера изображения. Высококачественное сжа-

тое видео требует скорости передачи 4-8 Мбит/с, что соответствует передаче

около 200 мегабайтов данных в течение пяти минут. Хотя для традиционного

Web-содержания допустимы короткие периоды снижения скорости передачи, стро-

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

риаций в скорости передачи. Для предварительно записанных потоков сервер может

отправлять дополнительные даьншю в периоды с высокой скоростью передачи дан-

пых в сети, чтобы приспособиться к периодам с более низкой скоростью передачи

в дальнейшем. Для потоков в реальном времени отправитель имеет ограниченные

возможности в использовании периодов с высокой пропускной способгюстью.

12.2.2.

Ограничения, свойственные IP-сетям

Разработчики Internet ничего не знали о мультимедийных приложениях, так

как их в то время не было. Совместное использование IP и TCP обеспечивает оп-

тимальный и надежный транспорт, который хорошо подходит для большинства

Internet-приложений. Ниже перечислены характеристики, которые наиболее кри-

тичны для мультимедийных потоков.

Качество сервиса. IP предоставляет оптимальный сервис без установления логи-

ческих соединений, который допускает потерю, задержку пакетов или доставку их не

в том порядке, как это рассказыва;юсь в главе 5 (раздел 5.1.2). Мультимедийные при-

ложения могут мириться с вариациями в задержке, потерями данных и с изменения-

ми пропускной способности сети. Однако значительные колебания производительно-

сти сети приводят к заметному снижению качества воспроизведения на стороне гюлу-

чателя. Чтобы обеспечить более высокую и более предсказуемую производительность,

необходимо изменить инфраструктуру сети или развернзггь дополнительные мощно-

сти.

Поставщики маршрутизаторов и сетевые провайдеры начали поддерживать диф-

ференциацию трафика в Internet. Это сгюсобствует уменьшению задержек, повыше-

нию скорости передачи данных и снижению потерь в сетях.

Управление пропускной способностью. Рост нопуляргюсти мультимедийных

приложений поднял проблему пересмотра требований, которым должна удовлетво-

рять инфраструктура Internet. Мультимедийные потоки требуют постоянной скоро-

сти передачи на определе1Н1ый период времени. Кроме того, один поток может быть

Глава

12.

Доставка мультимедийных потоков

427

нередан нескольким получателям с гюмощью группового вещания или путем не-

скольких индивидуальных передач. Это еще больше увеличивает нагрузку на сеть.

Мультимедийные приложения обычно используют в качестве базового транспортно-

го протокола UDP. UDP-отправитель не обязательно реагирует на затор в сети сни-

жением скорости передачи. В результате UDP-сообщения могут перегрузить сеть и

вызвать снижение пропускной способности ТСР-соединений. Это уменьшает произ-

водительность приложений, использующих TCP, таких как передача Web-сообще-

ний с помощью HTTP. В последние годы были предприняты значительные усилия

по разработке

дружественных

для TCP методов управления пропускной снособгю-

стью [FF99] для UDP-трафика, в том числе и для группового вещания. Цель друже-

ственного для TCP управления пропускной способностью состоит в том, чтобы

обеспечить «справедливое» ее распределение между мультимедийными гютоками и

другим Internet-трафиком, не заставляя мультимедийные приложения использовать

TCP в качестве транспортного протокола.

Групповое вещание. В противоположность традиционным Internet-нриложени-

ям,

многие мультимедийные приложения передают одни и те же данные множест-

ву получателей. Поддержка группового вещания IP-маршрутизаторами предостав-

ляет возможность значительного сокращения нагрузки на отправителя и сеть. Се-

тевая поддержка группового вещания в течение многих лет является областью

активных исследований. Хотя многие маршрутизаторы имеют встроенную под-

держку группового вещания, оно слабо поддерживается операционными система-

ми.

Групповое вещание на уровне приложений является популярной альтернати-

вой, обеспечивающей эффективное распространение информации среди множества

получателей, не предъявляя при этом к маршрутизаторам требований поддержки

группового вещания. При реализации группового вещания на уровне приложений

отправитель осуществляет индивидуальную передачу па небольшую группу серве-

ров-посредников. Каждый сервер-посредник, в свою очередь, может отправлять

данные другим серверам-посредникам. Серверы-посредники эффективно формиру-

ют

наложенную

сеть, построенную поверх IP-сети. Одним из первых воплощений

наложенной сети стала сеть Multicast Backbone (MBone), используемая для видео-

конференций. В последующие несколько лет групповое вещание на уровне прило-

жений стало стандартным решением для распространения мультимедийного содер-

жания группе получателей. Помимо ретрансляции данных, серверы-посредники

могут выполнять множество других функций, таких как кэширование или адапта-

ция содержания.

12.2.3.

Мультимедиа по запросу по HTTP

Первоначально мультимедийные потоки в Web передавались точно так же, как

традиционные текст и изображения. Клиент отправляет HTTP-запрос на Web-сер-

вер,

а сервер передает запрошенный ресурс клиенту. Заголовок Content-Type в со-

общении-ответе HTTP указывает на формат кодирования (например, Content-

Type: video-mpeg). На основе значения заголовка Content-Type браузер вызывает

соответствующее вспомогательное приложение, чтобы интерпретировать ответ, как

об этом говорилось в главе 2 (раздел 2.4.3). Для данных аудио и видео вспомога-

тельным приложением обычно является медиаплейер, который декодирует и ото-

бражает ответ. Плейер может также предоставить графический интерфейс для ре-

гулирования фомкости и выполнения функций видеомагнитофона, таких как пау-

за, прямая и обратная перемотка. С точки зрения браузера медиаплейер не

428 Часть V. Web-приложения

отличается от любого другого вспомогательного приложения

—

браузер просто на-

правляет данные приложению.

Обработка мультимедийного содержания точно таким же образом, как тексто-

вых данных и изображений, имеет несколько преимуществ. Все данные могут хра-

ниться на Web-сервере и быть доступными с использованием одного протокола

—

HTTP. Кроме того, мультимедийное содержание может быть кэшировано на про-

кси-серверах, расположенных на пути между сервером и клиентом. Однако обслу-

живание мультимедийных потоков как традиционных Web-данных имеет следую-

щие недостатки:

• Начальная задержка. В зависимости от реализации браузер может не активи-

зировать медиаплейер, пока весь HTTP-ответ не будет получен сервером. Это

вносит значительную начальную задержку для больших аудио/видео клипов.

Чтобы избежать этого, браузер должен направить данные па медиаплейер сра-

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

• Копирование данных между браузером и плейером. Мультимедийные дан-

ные должны быть переданы от браузера плейеру но мере их поступления от

сервера. В зависимости от конкретной реализации это может потребовать ко-

пирования большого объема данных между двумя процессами на клиентском

компьютере. Плейер должен получать данные своевременно, чтобы обеспе-

чить плавность воспроизведения.

• Чередование потоков аудио и видео. Вспомогательное приложение работает

с содержимым одного сообщения-ответа. Рассмотрим HTTP-запрос на муль-

тимедийный сеанс, который содержит как аудио-, так и видеоданные. Web-

сервер должен чередовать аудио- и видеосодержание в одном сообщении-от-

вете,

чтобы дать возможность плейеру воспроизводить данные по мере их по-

ступления. В некоторых случаях аудио- и видеоданные уже объединены вме-

сте в одном файле.

• Издержки надежного транспорта. HTTP подразумевает наличие надежного

протокола транспортного уровня, такого как TCP. Передача данных потоково-

го мультимедиа с помощью TCP сама по себе неэффективна. Обнаружение и

повторная передача утеря1П1ых пакетов приводит к дополнительной задержке

при отображении мультимедийного содержания. Это может вызвать прерыви-

стое воспроизведение потока медиаплейером.

• Сложности с функциями видеомагнитофона. Трактовка медиаплейера как

вспомогательного приложения усложняет реализацию функций видеомагни-

тофона. Плейер может обеспечить ограниченную паузу, перемотку назад и ус-

коре1П1ую перемотку вперед путем обращения к данным, полученным с серве-

ра. Воспроизведение с произвольного момента времени в аудио- или видеопо-

токе — еще более сложная задача. Это потребует от плейере выдачи нового

HTTP-запроса для соответствующего диапазона данных.

HTTP не слишком хорошо подходит для передачи но^^оков мультимедийного

содержания; для преодоления указанных выше ограничений были разработаны

другие подходы.

Вместо того чтобы получать данные от браузера, медиаплейер может взаимодей-

ствовать непосредственно с сервером. Это взаимодействие не обязательно должно

осуществляться по HTTP. Плейер может взаимодействовать с мультимедийным сер-

вером с использованием протокола, который лучше подходит для работы с мульти-

медийными потоками. Параллельно с разработкой стандартных протоколов, постав-

щики профаммных продуктов реализовывали свои собственные подходы к коорди-

Глава

12.

Доставка мультимедийных потоков 429

нации действий между плейером и сервером. Как правило, для инициирования

мультимедийной передачи используется HTTP. В ответ на HTTP-запрос сервер воз-

вращает ответ, содержащий метадагн1ые о мультимедийном потоке. Например, тело

HTTP-ответа может включать URL мультимедийного сервера с указанием желаемо-

го содержания (например, pnm://media.foo.com/clip). Браузер активизирует вспо-

могательное приложение, которое обрабатывает ответ, устанавливая свое собствен-

ное соединение с мультимедийным сервером.

Медианлейер должен понимать формат метаданных в теле HTTP-ответа. Кроме

того,

плейер должен знать, как связаться с мультимедийным сервером. Первые

компании, занявшиеся доставкой мультимедийных потоков, например, RealNet-

works, разрабатывали и предлагали мультимедийные серверы, а также бесплатно

предоставляли заингересова1Н1ЫМ пользователям медиаплейеры. Управление как

сервером, так и плейером предполагало использование специфичных для произво-

дителя протоколов для коммуникационного взаимодействия плейера и сервера, а

также для представления метаданных в теле HTTP-ответа. Разработка и распро-

странение стандартных протоколов являются необходимыми этапами в разделении

функций, относящихся к метаданным, а также в разграничении обязанностей меж-

ду плейером и сервером. Различные варианты стандартных протоколов реализова-

ны в некоторых медиаплейерах и серверах.

12.3.

Протоколы для передачи мультимедийных

потоков

к передаче мультимедийных потоков предъявляются особые требования, кото-

рые не могут быть удовлетворены HTTP. В этом разделе мы обсудим протоколы,

которые способны удовлетворить требованиям, относящимся к следующим катего-

риям.

• Передача данных. Потоковое мультимедиа требует доставки да1Н1ых с теми

же временными характеристиками одному или нескольким получателям.

Транспортировка потока обслуживается двумя тесно взаимосвязанными про-

токолами. Протокол Real-time Transport Protocol (RTP) делит ноток на паке-

ты,

каждый из которых содержит отметку времени, порядковый номер и ин-

формацию об отправителе [SCFJ96]. Спецификация RTP также определяет

протокол RTP Control Protocol (RTCP), но которому осуществляется обрат-

ная связь с информацией о качестве передачи и идентификационных данных

участников потока.

• Создание сеанса» Потоковое мультимедиа требует, чтобы отправители и по-

лучатели могли выражать свою заинтересованность в участии в мультимедий-

ном сеансе. Соответствующий протокол зависит от конкретного применения.

Протокол Session Initiation Protocol (SIP) используется для приглашения

пользователя присоединиться к сеансу [SSR99]. Протокол Session Announ-

cement Protocol (SAP) используется для объявления группы вещания, к кото-

рой клиенты могут присоединиться [HPWOO]. Протокол Real Time Streaming

Protocol (RTSP) позволяет клиенту отправлять сообщение-запрос мультиме-

дийному серверу [SRL98].

• Описание сеанса. Участникам сеанса нужно получить метаданные, такие как

параметры передачи и кодирования составляющих потоков, продолжитель-