Видеопотоки. Протоколы : Программирование для всех. Языки программирования, программирование баз данных, технологии. Статьи для програмиста скачать бесплатно учебники книги документация форум : Статьи

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

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

Сегодня для сквозной (из конца в конец) доставки мультимедийного трафика в режиме реального времени существует набор взаимосвязанных протоколов. В этом наборе RTP (Real-Time Transport Protocol) является основным транспортным протоколом, который устанавливает и разрывает сессии. Каждая из таких сессий несет один вид мультимедиатрафика для данного потока. RTP не обеспечивает QoS и не гарантирует корректную доставку данных.

С ним связан протокол управления передачей RTCP (Real-Time Control Protocol), выполняющий для потоковых технологий ту же роль, что и TCP при передаче пакетов. Он поддерживает службы QoS, однако сам по себе не может гарантировать необходимый уровень качества сервиса при сквозной передаче.

QoS предоставляется совместно с протоколом RSVP (Resource Reservation Protocol), который, как видно из его названия, резервирует ресурсы по всему маршруту для своевременного и эффективного транспортирования аудио- и видеоданных. С этой целью он рассылает необходимые запросы на полосу пропускания коммутаторам, маршрутизаторам и другим сетевым устройствам.

И наконец, последним протоколом в этой связке является RTSP (Real-Time Streaming Protocol). Он не имеет никакого отношения к транспорту данных. Это протокол прикладного уровня, и его назначение заключается в том, чтобы предоставить конечному пользователю возможность осуществлять прямое управление потоком. RTSP обеспечивает интерфейс, как и у видеомагнитофона, который позволяет выполнять такие операции, как перемотка, прокрутка, пауза и останов.

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

Real-Time Transport Protocol

RTP является IP-базированным транспортным протоколом, используемым для передачи мультимедиаданных, таких, как видео и аудио, по сетям с коммутацией пакетов, в частности Internet. В связке с протоколами RTCP и RSVP он способен обеспечить сквозную доставку и необходимый уровень QoS для мультимедиафайлов. RTP не включает функции маршрутизации, поскольку для этого применяется дейтаграммная служба UDP (User Datagram Protocol) из стека протоколов TCP/IP. Хотя протокол TCP, ориентированный на соединение, гарантирует доставку пакетов, причиной для отказа его использования в данном случае служит низкая скорость, что неприемлемо для чувствительного ко времени трафика. Поэтому качество приносится в жертву скорости.

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

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

Хотя RTP является протоколом транспортного уровня, он выполняет ряд функций, свойственных уровню приложений. В их число входят упорядочение пакетов во времени, их реконструкция и синхронизация. Информация, которая позволяет это делать, размещается в RTP-заголовке. Там же находится информация о способе шифрования полезной нагрузки, что является существенным, поскольку метод шифрования может изменяться в зависимости от загрузки сети. Передаваемая полезная нагрузка инкапсулируется в RTP-заголовок, затем данный фрейм помещается в UDP-заголовок и, наконец, все это инкапсулируется в IP-заголовок. Составленный таким образом пакет передается через Internet.

Real-Time Control Protocol

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

мониторинг QoS и управление перегрузками канала;

идентификация источника;

внутренняя синхронизация аудиовизуальной информации;

управление масштабированием.

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

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

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

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

Receiver Report (RR). Эти пакеты создаются участниками сессии, не являющимися активными отправителями. Они содержат такую информацию, как подтверждение получения пакетов, неустойчивость синхронизации между входящими пакетами, задержку, связанную с подтверждением приема.

Sender Report (SR). Такие сообщения посылаются активными отправителями, участвующими в сессии. В дополнение к информации, содержащейся в RR, они включают также данные о внутренней аудиовизуальной синхронизации и количестве отправленных байтов.

Source Description Items (SDES). Пакеты этого типа содержат информацию об участниках сессии.

BYE. "Прощальный" пакет, с помощью которого пользователь отключается от сессии.

APP. В пакет входят сведения о специфических функциях приложения.

Resource Reservation Protocol

Именно этот протокол обеспечивает требуемый для видеоприложений уровень QoS -- от начальной точки до конечной. Он является совместной разработкой известного научного центра Xerox PARC, Массачусетского технологического института (MIT) и Института информатики Калифорнийского университета (Information Science Institute of the University of California). Протокол позволяет резервировать ресурсы маршрутизаторов на всем пути следования мультимедийного трафика.

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

Прежде чем предоставляются требуемые ресурсы, каждый запрос проходит двойную проверку: Policy Control и Admission Control. Первая устанавливает правомочность пользователя резервировать ресурсы, а вторая -- отслеживает имеющиеся ресурсы, чтобы гарантированно предоставить требуемый уровень QoS. Если обе проверки дают положительный результат, то программа-демон RSVP, имеющаяся в составе ПО маршрутизатора, устанавливает необходимые параметры в полях пакетов Packet Classifier и Packet Scheduler. Первое поле определяет QoS для каждого пакета, тогда как второе -- выстраивает пакеты в очередь, для того чтобы обеспечить обещанный уровень QoS для каждого потока данных, проходящих через узел.

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

Как уже упоминалось выше, резервирование ресурсов происходит на всех маршрутизаторах, лежащих на пути от получателя к отправителю. Обработав запрос, отправитель направляет широковещательные сообщения (PATH) группе получателей, чтобы определить обратный маршрут и зарезервировать необходимые ресурсы. В ответ на PATH получатели направляют пакет RESV, который содержит параметры требуемого уровня QoS. Именно с помощью RESV выполняется резервирование ресурсов в каждом маршрутизаторе на пути получатель--отправитель. Он устанавливает на маршрутизаторах так называемое мягкое состояние резервирования, которое предусматривает освобождение зарезервированных ресурсов через определенный отрезок времени. Для того чтобы поддерживать состояние резервирования активным, RSVP-демон должен посылать "освежающие" сообщения. Такой механизм обеспечивает динамику резервирования при изменении состава участников сессии.

Real-Time Streaming Protocol

Это четвертый протокол в рассматриваемом наборе. Как уже упоминалось выше, в отличие от трех предыдущих он представляет собой протокол прикладного уровня, во многом подобный HTTP и FTP в стеке TCP/IP. Его уникальным свойством является то, что он предоставляет пользователю возможность управления медиапотоком. Работает RTSP совместно с протоколами нижнего уровня, такими, как RTP, RSVP, IP и TCP/UDP.

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

RTSP наделен свойствами масштабируемости и взаимодействия, во многом подобными протоколу HTTP. Фактически каждая презентация или мультимедиапоток идентифицируется в протоколе своим URL. Свойства презентации наряду с другими спецификациями сохраняются в файле дескриптора презентации, также имеющего свой собственный URL.

Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP.

Сервис RTSP поддерживается набором инструкций, которыми обмениваются между собой сервер и клиент. Они отсылаются в виде RTSP-пакетов, содержащих установочные параметры для потока. Вот некоторые из них:

DESCRIBE. Клиент требует у сервера описание презентации или медиаобъекта, указанное в URL запроса;

ANNOUNCE. Если эта инструкция посылается от клиента серверу, то в ней содержится описание презентации или медиаобъекта, указанное в URL запроса к серверу. Отправленная в обратном направлении, она обновляет описание сессии в режиме реального времени;

SETUP. Клиент запрашивает у сервера ресурсы и начинает RTSP-сессию;

PLAY. Клиент просит сервер начать передачу данных в потоке, выделенном с помощью SETUP;

PAUSE. Клиент временно приостанавливает доставку данных без освобождения ресурсов;

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

Вначале клиент направляет серверу запрос DESCRIBE, чтобы получить URL файла с описанием медиаданных. После ответа сервера клиент посылает инструкцию SETUP для выделения необходимых ресурсов. Наконец, клиент направляет серверу инструкцию PLAY, чтобы начать воспроизведение.

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

Леонид Бараш

При разработке CMS S.Builder наша команда активно использовала AJAX. Теперь вот решили поделиться накопленным опытом. Начнем с этого хабратопика. Не буду здесь затрагивать различные фреймворки и библиотеки. Свой код всегда роднее. Для работы с AJAX-ом в S.Builder написана библиотека sbAJAX. Можете качать и пользоваться :). В этом файле есть функция sbEvalJS. Для тех, кто не знает, объясню. При подгрузке через AJAX и вставке на страницу HTML-кода, содержащего JavaScript, JavaScript выполняться не будет или полезут баги. Эта функция как раз решает поставленную задачу.

Обзор нового релиза самой мощной Ajax библ....

Хотя наш обзор немного запоздал, оригинальный Dojo 1.2 вышел в релизной версии ещё 6-го октября, но сейчас мы наверстаем упущенное. И так, Dojo Toolkit — это самая мощная и гибкая ajax-библиотека из всех, что есть на рынке, она активно развивается и имеет большое комьюнити. Кстати, это самое комьюнити, совместно с компанией Sitepen, имеет ещё несколько проектов, среди которых и Cometd и некоторые другие, не менее интересные, о которых мы скоро вам расскажем. Сегодня же все внимание на флагманский продукт — Dojo 1.2.

Если вы профессиональный веб-разработчик и постоянно имеете дело с разработкой и отладкой сложных AJAX приложений, то наверняка знаете и используете Firebug — плагин для браузера Firefox, предназначенный для отладки и исследования веб-приложений. Текущая его версия, 1.2х достаточно стабильная и функциональна, чтобы помочь в 99% проблем, которые могут возникнуть при разработке. Но и этот инструмент не лишён если не недостатков, то некоторых фич, которые могли бы облегчить работу. И даже идеальный инструмент можно сделать ещё более идеальным, как бы это не звучало.