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

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

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

Первоначально HTTP был доМинирующим протоколом для передачи имеющихся в Web потоков аудио и видео. Одно из первых исследований мультимедийного содержания в Web было посвящено изучению характеристик видеофайлов, размещенных на Web-серверах [AS98]. Помимо традиционных параметров рабочей нагрузки, таких как размер ресурса, учитываются дополнительные свойства видеоданных, такие как формат кодирования, число кадров в секупду, размеры изображения и требования к средней пропускпой способности. Анализ имеющихся в Web видеоресурсов сопровождается тремя проблемами: обпаружепие видеоресурсов на различных Web-сайтах, получение копий файлов и вычисление статистических показателей на основе содержимого файлов. Теоретически для решения каждой их этих задач может потребоваться разработка нового программного обеспечения. К счастью, для упрощения задач обпаружепия видеофайлов и анализа их содержания может быть использовано существующее программное обеспечение.

Для поиска видеофайлов в Web исследователи используют существующие поисковые машины, которые дают возможность пользователям искать определенные иод- строки в составе URL. Поиск подстроки, например, ".mpg" или ".avi", дает в результате список Web-страниц, содержащих одну или несколько гипертекстовых ссылок с ".mpg" или ".avi" в составе URL. Запрос к поисковой машине выдает список URL для Web-страниц. Затем исследователи написали отдельную программу для загрузки Web-страниц и извлечения всех гиперссылок с нужными расширениями файлов. Поскольку гиперссылки на некоторые видеофайлы могли присутствовать на нескольких Web-страницах, необходимо обработать список для удаления повторяющихся URL.

На основе списка URL отдельная программа пытается извлечь ресурсы путем отправки HTTP-запроса GET для каждого URL. Около половины запросов по той или иной причине оказываются безуспешными. Некоторые запросы возвращают ответ 404 Not Found, если запрошенный ресурс отсутствует на Web-сайте. В других случаях Web-сервер возвращает код 200 OK. Однако это не обязательно подразумевает, что ответ содержит нужный видеофайл. Например, файловое расширение в URL может не соответствовать реальному формату файла. Кроме того, некоторые файлы могут иметь свойства, не отвечающие разумным требованиям. Например, некоторые файлы имеют длительность менее одной секунды или частоту кадров, меньшую, чем четыре кадра в секупду. В ряде случаев попытка воспроизвести содержимое файла показывает, что ресурс представляет собой статическое изображение, а не видеоклип. Отсев некорректных URL и файлов, которые представляются некорректными, приводят к удалению примерно половины URL из исходного списка.

Для обиаружеиия некорректных файлов и вычисления статистических показателей о корректных файлах требуется выполнять синтаксический анализ данных. Создапие программного обеспечения для декодирования видеоданных на практике достаточно затруднительно. К счастью, для тиновых форматов видео, включая MPEG, QuickTime и AVI, имеется общедоступное программное обеспечение. В некоторых случаях программное обеспечение, осуществляющее декодирование, может оказаться не в состоянии обработать данный входной файл из-за проблем с форматом данных. В других случаях программа выдает множество статистических показателей, таких как частота кадров,дпирина и высота окиа и длительность. Эти параметры могут быть использованы для вычисления других показателей, таких как требования к средней пропускной снособиости (битов в секупду) или отношение ширипы к высоте. Файлы с нетипичными параметрами могут быть исключены из дальнейшего рассмотрения. При анализе учитываются значения различных статистических параметров и их представления в разных форматах кодирования. Кроме того, анализирующая программа учитывает, содержит ли файл данные и аудио, и видео.

Хотя исследование дает широкое представление об имеющемся в Web наборе видеоресурсов, статический анализ имеет ряд ограничений. Во-иервых, любая поисковая машипа обладает неполным представлением об имеющихся в Web-pecyp- cax. Некоторые Web-страницы со ссылками на видеоресурсы могли быть не подвергнуты индексированию. Кроме этого, некоторые URL для видеофайлов могут иметь файловые расширения, не использованные при поиске. Во-вторых, что весьма существенно, исследование не может определить популярность различных видеофайлов. Для определения популярности ресурсов требуется наличие трассы или журналов клиентов, извлекающих видеоданные с сервера, или результаты отдельного исследования, выполненного рейтинговой компанией. В-третьих, появление новых протоколов для мультимедийных потоков ограничивает эффективность методов выборки видеофайлов. Для потокового видео вместо HTTP все большее применение паходят протоколы Real-time Transport Protocol (RTP) и Real Time Streaming Protocol (RTSP). Гиперссылки на Web-страницах часто являются указателями на описания сеансов, сценарии или мультимедийные презентации, которые не раскрывают, что URL соответствуют мультимедийному содержанию.

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

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

В то время как Web-сервер записывает информацию о каждом НТТР-запросе, мультимедийный сервер генерирует занись для каждого действия пользователя, такого как обращение к функциям видеомагнитофона. Для форматов журналов Web-серверов имеются определенные стандарты. Для мультимедийных серверов каких-либо строгих требований к форматам нет. Кроме того, журналы мультимедийных серверов не являются широко доступными. Существующие исследования журналов мультимедийных серверов основаны на данных измерений, собранных академическими учреждениями. Многие университеты, имеющие Web-сайты, предоставляют доступ к учебным материалам, таким как курсы лекций, для просмотра в оперативном режиме. Журналы гаких сайтов предоставляют возможность анализировать поведение пользователей при запросах мультимедийных потоков для ограниченного сообщества пользователей, обращающихся за содержимым определенного типа. Большое разнообразие мультимедийных приложений затрудняет получение обобщенных результатов о характеристиках ресурсов и шаблонах доступа. Тем не менее, методология обработки серверных журналов и получения характеристик рабочей нагрузки для этих сайтов может быть применена к другим приложениям и сообществам пользователей.

Исследования двух сайтов дистапциоииого обучения иллюстрируют проблемы, связанные со сбором данных и анализом журналов мультимедийных серверов [PK99, ASP00]. Различаясь форматами, оба журпала содержат информацию одного и того же вида, а именио, традиционные HTTP-запросы на HTML-файлы и изображения вместе с запросами на начало и завершение мультимедийной передачи. Каждая запись содержит метку времени, идентификатор клиента, запрашиваемое действие и имя, ассоциированное с мультимедийным ресурсом. В одном из исследований серверный журнал был подвергнут предварительной обработке для удаления запросов, поступивших от определенного клиента, использованного для целей тестирования; в противном случае запросы от этого клиента могли помешать анализу поведения пользователей [ASP00]. Кроме того, записи журнала, такие как повторяющиеся команды «стоп» от одного и того же клиента, были сжаты до одной записи.

Традиционные параметры рабочей нагрузки имеюг характеристики, сходные с соответствующими характеристиками НТТР-трафика. Оба исследования выявили, что пользователи редко просматривают весь поток целиком. Некоторые пользователи прекращают просмотр потока после просмотра его начальной части; это наводит на мысль, что кэширование первых нескольких минут потока на прокси-сер- вере — достаточно эффективный способ спизить нагрузку на сервер и повысить производительность на стороне пользователя. Другие пользователи часто обращаются к функциям видеомагнитофона, таким как переход, обратная перемотка и ускоренная перемотка. При некоторых операциях обратной перемотки перемещение осуществляется на небольшое число кадров. Это наводит на мысль сохранять небольшое число кадров в буфере клиента, что позволит клиенту обрабатывать эти операции без извлечения кадров с сервера. Операции ускоренной перемотки вперед на небольшое число кадров могут быть осуществлены без задержки, связанной с воспроизведением пользователем кадров, которые уже имеются на клиенте. Однако возможны переходы к произвольному месту в потоке. Такие запросы обычно требуют загрузки новых данных с исходного сервера ценой дополнительной задержки на стороне пользователя.

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

Анализ серверных журналов дает возможность определить характерные параметры поведения пользователей. Однако серверные журналы не содержат достаточно данных для изучения транспортировки мультимедийных данных через Internet. В традиционных Web-передачах сервер записывает сообщение-ответ в буфер сокета и оказывается зависимым от базового TCP-соединения нри доставке данных. В противоположность этому, доставка мультимедийных потоков требует от сервера чередовать во времени передачу сэмплов аудио и видеокадров, в результате чего трафик может сильно меняться. Получение характеристик мультимедийного трафика на транспортном уровне требует сбора и анализа детально измеренных параметров потока. В недавно проведенном исследовании был представлен подробный Анализ транспортировки аудиопотоков с сервера RealAudio онлайновой радиостанции [MH00J. В ходе исследования были собраны данные трасс пакетов, проанализированы параметры трафика на уровне пакетов и потоков, разработана модель, описывающая основные параметры рабочей нагрузки.

Для сбора трасс пакетов требуется перехват пакетов и генерирование записей с данными измерений. Трассы пакетов в исследовании собирались на коммутаторе Ethernet путем направления копий пакетов, передаваемых аудиосерверу или от него, в капал, подключенный к монитору, в соответствии с подходом, представленном на рис. 14.1 в. Аудиосервер может направлять иогоки дапных клиенту с использованием UDP, TCP или HTTP поверх TCP. Перехват пакетов требует настройки монитора пакетов, включающей задание фильтра, который идентифицирует IP-адрес, протоколы и номера портов, как описывалось рапее в разделе 14.1.2. Хотя сервер всегда выбирает порт 80 для передач HTTP поверх TCP, нри передаче аудиопотоков но UDP или TCP может использоваться любой незарезервированный порт (т.е. порты с номерами от 1024 до 65535). На практике сервер использует небольшое, фиксированное множество померов портов, которые известны лицам, проводящим исследование. Мопитор пакетов был настроен для перехвата пакетов с этими номерами портов. Монитор записывает первые 90 байт каждого аудиопаке- та, что гарантирует включение в трассу заголовков IP и TCP/UDP, а также заголовка данных аудио. Такая подробная трасса дает возможность сосредоточиться нри анализе на низкоуровневых трапспортных проблемах, связанных с временами передач пакетов от сервера клиентам.

Программа анализа груннирует пакеты, принадлежащие одному TCP- или UDP-ceancy; т.е. пакеты с одними и теми же IP-адресами источника, иолучагеля и номерами портов считаются частью одного аудиопотока. Транспортный механизм потока (UDP, TCP или HTTP поверх TCP) может быть определен на основе протокола и померов портов. Поле протокола указывает, использовался ли протокол UDP или TCP, а номер порта TCP сервера позволяет отличить НТТР-трафик (порт 80) от остального ТСР-трафика. По большей часги трафик состоит из UDP-пакетов. Это важно, поскольку приложения, использующие UDP, необязательно корректируют скорость передачи в качестве реакции на заторы в сети. Вместо этого аудиосервер передает данные на периодической основе. Чтобы разработать модель рабочей нагрузки, анализирующая программа особое внимание должна уделять размерам пакетов и интервалам времени между началом одного потока и запуском следующего потока, а также длительности потоков. Вариации каждого из этих параметров оцениваются с учетом распределений вероятностей.

Распределения вероятностей, полученные из данных измерений, образуют модель трафика аудиоданных на потоковом и пакетиом уровнях. Такая модель способствует проведению экспериментов, оценивающих воздействие трафика аудиоданных на сервер и на сеть. Значения параметров зависят от природы мультимедийного приложения. Онлайновая радиостанция может иметь иные свойства по сравнению с сайтом, предназначенным для прослушивания пользователями аудиоклинов. Немного клиентов прослушивает более одного аудиопотока, а половина потоков имеет длительность более 45 мииут. По большей части потоки имеют несколько различных скоростей передач данных в зависимости от типа аудиоресурсов. Для стереомузыки требуется более высокая скорость передачи, чем для ток-шоу и спортивных репортажей, поскольку речь сжимается лучше, чем музыка. Во всех трех случаях скорость передачи аудиоинформации ограничена 20 Кбит/с, чтобы гарантировать получение потоков пользователями, подключенными к Internet с помощью модемов со скоростыо передачи данных 28,8 Кбит/с. Сервер также использует особые размеры пакетов для UDP-иередач. Изменения в мультимедийном содержании, перемены в сообществе пользователей или появление новых реализаций серверов могут привести к изменениям характеристик рабочей нагрузки.

Многоуровневый мониторинг пакетов

В отличие от традиционных НТТР-нередач, большинство потоковых приложений используют отдельные сеансы для передачи команд и данных. Например, кли- еиг и сервер могут обмениваться RTSP-сообщениями для координации передачи одного или нескольких RTP-потоков; каждый RTP-поток может иметь соответствующий RTCP-поток (RTP Control Protocol) для обмена сигналами обратной связи относительно качества передачи. Детальное определение характеристик мультимедийного трафика может зависеть от наличия информации о каждом из этих протоколов. Запрашиваемые URL, запросы на управление видеопотоком на стороне клиента передаются в RTSP-сообщениях, тогда как данные аудио и видео передаются в RTP-пакетах. Измерение трафика команд и трафика данных песет в себе две проблемы. Во-первых, содержимое управляющих сообщений должно восстанавливаться из базового потока пакетов, подобно восстановлению НТТР-сообще- пий (см. раздел 14.1). Во-вторых, монитор должен идентифицировать трафик данных , ассоциированный с управляющими сообщениями. На практике это сопряжено со значительными проблемами, поскольку при передаче данных используются номера иортов UDP и TCP, которые могут не быть известны заранее. Вместо этого, номера иортов для трафика данных  доставляются через управляющие сообщения. Например, клиент отправляет RTSP-сообщение на мультимедийный сервер, чтобы установить сеанс, состоящий из одного аудиопотока, использующего RTP для передачи данных и RTCP для обрагиой связи. После получения описания сеаиса клиент отправляет RTSP-сообщение SETUP для создания двух транспортных соединений. Сообщение-ответ сервера содержит заголовок Transport, который идентифицирует протокол (UDP или TCP) и иомера портов на клиенте и на сервере, как описывалось рапее в главе 12 (раздел 12.4.3). Клиент, запросивший сеанс с отдельными потоками аудио и видео, выдает два запроса SETUP для создания двух групп соединений, по одной для каждого потока. Каждое соединение упикально идентифицируется по группе из пяти чисел: IP-адресам клиента и сервера, номерам иортов клиента и сервера и протоколу.

Идентификация этих соединений доволыю затруднительна. IP-адреса клиента и сервера соответствуют адресам, используемым для RTSP-соединения, в то время как номера портов и протокол зависят от ответа сервера на сообщение SETUP. Простой подход к решению этой проблемы состоит в том, что монитор захватывает все пакеты в канале или все пакеты, использующие незарезервированные номера иортов (т.е. от 1024 до 65535). Далее отдельная программа может идентифицировать, какие передачи данных ассоциированы с каждым из командных сеансов. Однако это может потребовать от монитора захватывать и хранить чрезвычайно большой объем данных , особенно для высокоскоростных каналов. Например, монитор может захватывать пакеты из передач больших файлов по FTP и сеансов IР-теле- фопии, не связанных с какими-либо командными сеанса ми RTSP.

Вместо этого моиитор может просматривать управляющие сообщения при их поступлении и определять, какие номера портов отслеживать. При этом при поступлении пакетов от монитора требуется выполнение двух основных задач: синтаксический анализ управляющих сообщений для определения померов портов и изменение фильтра пакета для перехвата пакетов данных, использующих эти иорты. Эти задачи выполняет инструмеиталыюе средство mmdump [vCCS00]. оно перехватывает полпое содержимое пакетов, ассоциированных с протоколом управления, идентифицируемого по известному номеру порта (например, 554 для RTSP), и восстанавливает управляющие сообщения. Средство содержит программу для синтаксического анализа различных управляющих протоколов для мультимедиа, таких как RTSP и H.323. После извлечения информации о протоколе, номерах портов и потоках данных, mmdump обновляет фильтр пакета для перехвата пакетов данных. Инструментальное средство может перехватывать полное содержимое этих пакетов или быть настроенным для записи оиределеиного числа байтов из па- чала каждого пакета дапных.

Мониторинг передач команд и данных создает условия для выполнения различного вида анализа. Например, рассмотрим мультимедийную презентацию, в состав которой входят изображения, аудио, видео и текст. Управляющие сообщения содержат URL для различных ресурсов, а пакеты данных песут информацию о размере или скорости передачи для каждого потока. Знание URL гакже дает возможность осуществлять анализ популярности различных мультимедийных ресурсов в Internet. Наличие управляющих сообщений и пакетов дапных полезно для изучения воздействия степени загруженности сети на приложения для доставки мультимедийных потоков. Некоторые управляющие сообщения включают клиентские запросы на изменение скорости передачи, что может привести к изменениям в скорости передачи потока данных. Подобные эффекты, связанные с обратной связыо, очень трудно учитывать без совместного нерехвата трафика команд и трафика данных.

Резюме

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

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100