Автореферат

Введение и обоснование актуальности темы

     30 лет назад мультимедиа ограничивалась печатной машинкой "Консул", что не только печатала, но и могла привлечь внимание заснувшего оператора мелодичным треском. Чуть позже компьютеры уменьшились в размерах. Многим любителям дало новый толчок развитие мультимедии (компьютерный гороскоп 1980 года, который с помощью динамика и программируемого таймера синтезировал расплывчатые устные угрозы каждый день еще и перемещал по экрану звезды (зачатки анимации)). Приблизительно в настоящее время появляется понятие мультимедиа. Человечество переживает информационную революцию. И вот мы становимся свидетелями того, как общественная потребность в средствах передачи и отображение информации возводит к жизни новую технологию, за неимением корректного термина называя ее мультимедиа. В наши дни это понятие может целиком заменить компьютер практически в любом контексте. Понятие мультимедиа также успешно можно отнести и к быстро растущей сети Интернет. В начале развития Интернет, web-страницы не представляли собой ничего интересного, речи не могло идти о том, что пользователь может посмотреть TV-трансляцию, послушать FM-радио, скачивать музыкальные композиции, а так же пополнить свою фильмотеку любимыми фильмами.

Цель и задачи работы

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

Планированная практическая ценность

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

Обзор уже существующих методов по теме магистрской работы

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

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

2. Чувствительность трафика к задержкам пакетов

3. Чувствительность трафика к потерям и искаженияим пакетов

     По первому критерию приложения делятся на две большие группы: генерирующие трафик с постоянной битовой скоростью (constant bit rare, CBR), и с переменной битовой скоростью (variable bit rate, VBR). В приложениях первого типа (CBR) верхняя граница битовой скорости потока легко предсказуема. Например, для передачи голосового потока без сжатия в IP-телефонии часто применяется поток с битовой скоростью 64 КБит/сек.

      В приложениях второго типа трафик характеризуется значительными пульсациями (bursts), в результате чего используемая приложением полоса пропускания в процессе работы колеблется от нуля до максимума, обеспечиваемого сетью. К этой группе, например, относятся приложения для передачи файлов. Коэффициент пульсаций (отношение максимальной мгновенной скорости к средней) здесь может достигать 100:1. По чувствительности к задержкам пакетов приложения также можно разделить на две большие группы: асинхронные и синхронные. При этом асинхронные приложения либо вовсе нечувствительны к задержкам, либо не теряют своей функциональности в случае их появления. К этой группе относится большая часть традиционного трафика компьютерных сетей – передача файлов и электронной почты. Мультимедийные приложения, в свою очередь, относятся к группе синхронных. Задержка сетью очередного пакета с замерами голоса более чем на 100..150 мс относительно ожидаемого времени его прибытия ведет к резкому снижению качества воспроизведения речи.

Третий критерий классификации – чувствительность к потерям пакетов. Большинство традиционных приложений относятся именно к этому типу. Потери и искажения пакетов делают принимаемую информацию непригодной к использованию, и приходится производить повторную передачу потерянных фрагментов. Между тем, приложения, передающие информацию об инерционных физических процессах (например, речь человека), устойчивы к потерям, так как недостающие данные можно определить на основе уже принятых. К примеру, при потере одного пакета с несколькими замерами голоса можно восстановить недостающие замеры по уже принятым, пользуясь аппроксимацией на основе соседних значений. Однако тут необходимо отметить два практически важных обстоятельства. Во-первых, доля потерь не может быть большой. Во- вторых, аудио- и видеоинформация часто передается в сжатом виде, и в силу отсутствия в ней избыточности она чувствительна к потерям.

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

Разделим все приложения, требующие передачи мультимедийной информации в реальном времени, на два больших класса: интерактивные и неинтерактивные. Приложения первой группы – это IP-телефония и видеоконференции. Их отличительная особенность в том, что участников, как правило, двое или несколько. Каждый участник передает информацию всем остальным. В свою очередь, каждый из получивших ее участников реагирует на нее (например, отвечает на реплику), и информация передается от ответившего всем остальным. Таким образом, получается система с обратной связью. Кроме того, желательно, чтобы обратная связь поступала своевременно, иначе разговор будет некомфортным. Иная ситуация наблюдается в работе неинтерактивных приложений. К этой группе относятся так называемые 'системы аудио и видео по запросу', примеры которых – интернет-радиостанции и цифровое телевещание. Как правило, подобные системы имеют в своей основе клиент-серверную технологию: клиент соединяется с сервером и отправляет ему запрос на выдачу мультимедийного потока. Сервер выдает поток, который клиент может начать раскодировать сразу после получения, не дожидаясь окончания потока. Отличительная особенность неинтерактивных систем в том, что один и тот же поток могут просматривать сразу очень много пользователей, так как обратная связь от каждого из них, предназначенная остальным участникам, не требуется.

Приложения обоих типов, как интерактивные, так и неинтерактивные, важно и нужно исследовать, но неинтерактивные приложения исследовать проще, так как их использование носит массовый характер. Например, работа посвящена исследованию мультимедийного трафика, который потребляли клиенты сети Вашингтонского университета (США). Основные результаты исследований таковы: за одну неделю 4786 клиентов обратилось к 23738 различным объектам по протоколу RTSP, при этом было перенесено 56 ГБайт данных. Кроме того, были получены важные дополнительные результаты: нагрузка, создаваемая на сеть совокупным потоком, была цикличной с периодом в одни сутки, при этом пик пропускной способности приходился на рабочие часы рабочих дней недели и составлял 2,8 Мбит/сек. Большинство сессий длилось меньше 10 минут, и объем перенесенных ими данных составлял меньше 1 МБайт. В то же время, всего лишь 3% сессий передали почти половину совокупного объема информации. Масштабность данного исследования позволяет в достаточной мере экстраполировать его результаты для описания мультимедийных потоков в сетях.

Однако этих результатов еще недостаточно, чтобы отразить структуру мультимедийного трафика. Обратимся к работе, в которой исследовались мультимедийные потоки формата RealAudio от серверов компании 'Broadcast.com' к клиентам (измерительное оборудование находилось на технической площадке компании Broadcast.com). В этом случае использовался транспортный протокол PNA, а не RTSP, как в работе. Указанные выше форматы кодирования и передачи данных являются закрытой разработкой компании 'Real Networks', но их широкая практическая распространенность побуждает к их изучению. В ходе исследования выяснилось, что большая часть сессий (70-80%) использовала два потока: один, по протоколу UDP, для передачи данных, второй, по протоколу TCP, для управления потоком данных. Оставшиеся 20-30% сессий используют только один поток, протокола TCP, и для данных, и для управления. Поток управления служит для создания обратной связи с сервером: по нему пересылаются подтверждения принятых пакетов, а также команды от пользователя, например, на приостановку или прекращение потока. Объем данных, передаваемых обратно к серверу, был очень незначительным, его отношение к объему данных в сторону клиента составляло около 1:28..1:50.

Кроме того, было найдено, что размер пакетов зависит от битовой скорости аудиопотока. Если в качестве мультимедийного содержимого выступает стереозвук, то используется битовая скорость 16 и 20 Кбит/с, а размеры пакетов составляют 293 и 495 байт. В случае передачи голосового потока, доминирует битовая скорость 6,5 Кбит/с с размером пакетов 244 байта.

Детальный анализ показал, что пакеты высылаются не через равные промежутки времени, а пачками (bursts). При этом наблюдалось в среднем по 6 пакетов в пачке, после чего следовала пауза на 1,8 с или (реже) кратное ей значение. Это инженерное решение имеет глубокое практическое обоснование. Иногда считается, что, если мультимедийный трафик передается с постоянной битовой скоростью, то на практике следует высылать пакеты через равные промежутки времени. На самом деле, постоянная битовая скорость действительно наблюдается, но на больших интервалах времени (например, с усреднением за минуту). На отсылку каждого пакета приложению-серверу требуется квант времени от планировщика задач операционной системы. Если отсылать пакеты через равные промежутки времени, потребуется частое переключение контекста планировщиком задач, что сопряжено с высокими накладными расходами. Поэтому выгоднее оказывается в выделенный планировщиком квант времени отослать сразу несколько пакетов. В случае, если общая загрузка сервера растет, планировщику не удается плавно распределять время между задачами, что отражается на работе сервера RealAudio: в отличие от обычного режима, когда за пачкой из нескольких пакетов следует короткий интервал, сервер начинает увеличивать длительность интервала между пачками, а в самой пачке получается больше пакетов. Битовая скорость потока при усреднении за минуту останется прежней, но в малых масштабах времени отсылка пакетов уже не будет плавной. Этот пример показывает, что для эффективной работы мультимедийного сервера требуется также и эффективная операционная система. Процессы сервера по своей природе нуждаются в планировке в реальном масштабе времени. Соответствующие расширения для планировщиков задач описываются стандартом POSIX 1003.1b. Некоторые сведение об этом стандарте и его поддержке в ОС Linux и SunOS можно почерпнуть из работы.

В работе была построена модель RealAudio-трафика, после чего она была проверена с помощью системы имитационного моделирования ns-2. Проверка показала хорошее совпадение построенной модели с результатами практических измерений. Интерес представляют и модели мультиплексированных мультимедийных потоков, генерируемых несколькими источниками сразу. Такие модели позволяют получить аналитическое выражение для распределения вероятностей состояния буфера. В частности, описывается марковски-модулированный пуассоновский процесс (MMPP-процесс) поступления пакетов в мультиплексированном потоке. Для этого рассматривается дискретная цепь Маркова с конечным числом состояний M. Принимается также, что если система находится в состоянии m, где m=1..M, на вход обслуживающего устройства поступает пуассоновский поток с интенсивностью m . Простейшим практически интересным случаем будет M=2, то есть два состояния системы: например, большая и малая нагрузка, создаваемая мультиплексированным потоком и соответствующая двум различным значениям интенсивности: 1 и 2 . Однако составление модели с помощью MMPP-процесса требует решения системы нелинейных уравнений для нахождения параметров марковской цепи. В таком случае можно воспользоваться марковски-модулированной моделью жидкого потока (fluid-flow). Эта модель предполагает, что каждый активный в данный момент источник генерирует одну единицу данных в одну единицу времени, а обслуживающее устройство получает на входе данные со скоростью C единиц данных в единицу времени от C активных в данный момент источников. Тогда для описания потока от M источников, часть которых может быть активна в любой момент времени, потребуется марковская цепь с M состояниями. После составления и решения системы линейных дифференциальных уравнений, можно найти распределение вероятностей состояний буфера Fi x - вероятность того, что в установившемся режиме при активности i источников в буфере будет находиться не более x единиц данных.

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

Исследование компьютерной сети на пригодность к передаче мультимедийной информации

Обзор существующих метрик в IP-сетях

Для изучения процессов измерений в IP-сетях была образована группа IP Performance Metrics (IPPM) в составе комитета IETF . С 1998 года группа выпускает так называемые 'черновики стандартов' (drafts), которые пересматриваются каждые полгода. Часть этих документов уже получила статус 'предполагаемых стандартов' (proposed standard) и закреплена в системе RFC (Requests For Comments) под собственными номерами. Основная задача группы IPPM заключается в том, чтобы разработать метрики, которые позволят объективно оценить параметры компьютерной сети, дав возможность пользователям и провайдерам говорить на одном языке.

Руководящим документом является [15]. В нем дается следующее описание термина 'метрика': 'Метрика – аккуратно специфицированный количественный параметр, относящийся к производительности и надежности сети Internet'. Метрики задержек и потерь пакетов описаны в [17, 18, 19]. При проведении измерений задержек и потерь пакетов производят отсылку тестирующего потока от одного хоста сети к другому, после чего оценивают измеренные параметры. Указывается, что интервалы времени между измерениями следует брать распределенными по экспоненциальному закону. Если же промежутки времени между измерениями будут равными, и то явление в сети, которое мы хотим наблюдать, тоже будет проявляться через равные промежутки времени, то измерения зафиксируют явление только в случае совпадения их периодов. Экспоненциальное распределение свободно от этого недостатка: если при измерениях явление наблюдалось в M случаях из N, то и в действительности это явление будет наблюдаться в доле случаев M/N при N? [11]. Данная техника получила название 'Poisson sampling', так как поток измерений является пуассоновским потоком.

Еще одно важное требование к измерениям заключается в том, что размеры IP-пакетов в тестирующем потоке должны быть меньше минимального значения MTU (Maximum Transfer Unit) всех интерфейсов каждого устройства сетевого уровня вдоль маршрута, чтобы избежать фрагментирования IP-пакетов и связанного с этим искажения результатов измерений. Узнать MTU вдоль маршрута можно с помощью утилиты tracepath, входящей в пакет iputils в GNU/Linux.

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

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

При достаточной для практических целей точности результатов методика должна обладать минимальной стоимостью постановки эксперимента и анализа результатов. Поэтому в ходе работы было применено свободно распространяемое программное обеспечение: ОС GNU/Linux и программы, входящие в ее состав. Один из хостов, участвующих в измерении, находился в сети СПбГПУ, а второй – в сети Петродворцового телекоммуникационного центра СПбГУ. Ядром программного комплекса является программа MGEN [8] – генератор и приемник тестового трафика, которая была создана специалистами военного ведомства США специально для анализа компьютерных сетей. Программа MGEN, установленная на одном компьютере сети, генерирует тестовый трафик, а такая же програма на другом компьютере принимает его и записывает в файл журнала информацию о принятых пакетах, которая включает в себя: время отправки пакета по локальным часам отправителя, порядковый номер отправленного пакета (два этих значения пересылаются в каждом пакете), а также время его приема по локальным часам приемника. Работа MGEN управляется файлом сценария. Схема эксперимента изображена на рис. 1.

На хосте 'Master' в среде ОС GNU/Linux на основе команды at (1) была создана инфраструктура, которая через интервалы времени, имеющие экспоненциальное распределение, запускала скрипт test_mgen_two_way. Этот скрипт выполнял следующие задачи:

1. Читал из файла конфигурацию измерительной системы

2. Запускал на хосте 'Slave' скрипт listen_mgen

3. Проверял, был ли он запущен на хосте 'Master' или на хосте 30 'Slave'. Если был запущен на 'Master', то запускал свою копию test_mgen_two_way на хосте 'Slave'

4. Запускал MGEN со сценарием send.mgn для отправки тестового трафика удаленному хосту

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

Скрипт listen_mgen выполнял следующие задачи:

1. Читал из файла конфигурацию измерительной системы

2. Запускал MGEN со сценарием receive.mgn для приема тестового трафика от удаленного хоста

3. После окончания приема тестового трафика отсылал файл с результатами измерений на адрес электронной почты запустившего его пользователя, после чего записывал файл в каталог для хранения

Автоматический запуск программ на удаленном компьютере происходил с использованием протокола SSH и его открытой реализации OpenSSH [10]. В результате совместной работы описанной системы хост 'Master' передавал тестовый трафик хосту 'Slave' и наоборот. Таким образом, оба хоста совершенно равноправны при отправке трафика, и один из компьютеров назван 'Master' потому, что он инициирует измерение. После окончания измерения на каждом из хостов оказывался файл журнала, который отсылался по электронной почте (совокупность двух файлов журнала, по одному с каждого хоста, в дальнейшем будет называться 'след эксперимента'). Далее результаты измерений анализировались и делались выводы о качестве того сегмента компьютерной сети, который соединял два хоста.

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

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

Часы двух хостов, использовавшихся в результате эксперимента, обладают недостатками: во-первых, они не синхронизированны (то есть обладают малой точностью: модуль сдвига не близок к нулю), во- вторых, они идут с разной скоростью: частотный сдвиг не равен нулю. Относительно точности часов можно заключить, что необязательно синхронизировать часы обоих хостов с некоторыми 'точными' часами. Вместо этого можно синхронизировать часы одного хоста с часами другого. Это дало бы возможность определять задержку передачи пакета в одну сторону. Однако в случае наших измерений было недоступно даже это. Синхронизация часов по протоколу NTP [13] не годится, так как он предназначен для синхронизации времени с точностью нескольких десятков миллисекунд на протяжении интервалов времени в несколько дней. В нашем же случае требовалась синхронизация с точностью около 1 мс на небольшом отрезке времени, определяемом продолжительностью измерения. Кроме того, использование протокола NTP хотя бы на одном из хостов может привести к неожиданным эффектам во время измерений, так как таймер хоста, использующего NTP, сдвигается в ходе измерения вперед или назад [24]. Кардинальным решением синхронизации показаний двух часов является система глобального позиционирования GPS, созданная военным ведомством США. Организация RIPE NCC (Европейский сетевой координационный центр) создала программно-аппаратный комплекс для измерения параметров IP-сетей [22]. Измерительная станция представляет собой компьютер, соединенный с приемником системы GPS. Во время работы таймер компьютера выдает показания, синхронизируясь с системой GPS. Точность показаний GPS- приемника настолько велика, что точность временных меток в измерительной системе начинает ограничиваться разрешением таймера и составляет около 1 мс, что вполне достаточно для практических целей. Разработанный программно-аппаратный комплекс стоит €2500 и продается фактически по себестоимости. Организации, желающие участвовать в тестировании связи между своей сетью и остальной частью Internet, могут приобрести такой прибор и установить его на своей технической площадке. После установки прибор работает без вмешательства оператора и передает собранную статистику для анализа в RIPE NCC, делая ее доступной для всех участников измерений.

То обстоятельство, что частотный сдвиг между часами не равен нулю, требует обязательного учета. Выражается этот недостаток часов в том, что они идут с другой скоростью (пусть, для определенности, они идут немного быстрее), чем их пара. По абсолютной величине частотный сдвиг невелик, например, в ходе измерений наблюдалось значение сдвига показаний 1 мс за каждые 5,5 с. Но за 180 секунд, которые длится измерение, показания часов сдвигались друг относительно друга на 32 мс. Этой величиной нельзя пренебречь при анализе. Тем не менее, на коротких интервалах времени, сопоставимых с длительностью измерения, частотный сдвиг часто является постоянной величиной (в ходе измерений отклонений от этого правила не было), тогда сдвиг показаний часов будет линейным, и его можно удалить после получения результатов измерений. Удаление частотного сдвига, таким образом, устраняет методическую ошибку измерений.

Выше упоминалось, что несинхронизированность часов сделала прямое использование результатов измерения невозможным. Качественно картина выглядит следующим образом. Если сдвиг между показаниями часов составляет, допустим, 10 с, то измеренная в одну сторону задержка оказывалась равна примерно 10 с, а в другую сторону – примерно -10 с. Реального значения односторонней задержки из этих данных получить невозможно. Тем не менее, можно получить значение задержки в обе стороны.

Обычно под RTT (Round-Trip Time, 'время полного оборота') подразумевают время, которое требуется пакету, чтобы достичь адресата и вернуться обратно. Измерение RTT часто производят с помощью программы ping и подобных ей. Такие программы посылают сообщение протокола ICMP [20] 'echo request', оно достигает адресата, ядро операционной системы которого генерирует ответное сообщение ICMP 'echo reply', которое отправляется обратно. Отправитель, получив ответ на свое собственное сообщение, вычисляет, сколько времени прошло с момента отправки, и полученное значение и называется RTT. Указанный метод обладает недостатком: ICMP-пакеты не обязательно будут обслуживаться на промежуточных и конечных узлах так же, как и пакеты с данными. Часто маршрутизаторы ограничивают пропускную способность, предоставляемую потоку ICMP-пакетов, из соображений безопасности [30]. Кроме того, IP-стек маршрутизаторов и приемника могут работать с ICMP-пакетами как с менее приоритетными и генерировать и продвигать их только в том случае, если на обслуживании нет пакетов с данными [24]. Это приводит к тому, что значения RTT, наблюдаемые при таком тестировании, отражают не время полного оборота пакетов с данными, а время полного оборота ICMP-пакетов, что исследователю вовсе не требуется. Существует улучшенный вариант этого метода, когда на передающем хосте установлен генератор пакетов с данными, но не по протоколу ICMP, а, например, по UDP. На другом хосте находится приемник. При получении пакета приемник немедленно отправляет его обратно. Отправитель получает ответ и вычисляет значение RTT так же, как и в предыдущем случае. Особенность схемы состоит в том, что используются не пакеты ICMP, а пакеты UDP, и наблюдаемое значение RTT лучше отражает условия, в которых бы передавались пользоватльские данные. Кроме того, 'зеркальное отражение' пакета делает не ядро ОС приемника, а приложение на приемнике, поэтому наблюдаемое значение RTT еще немного ближе к тому, которое испытывали бы реальные потоки данных.

В данной работе планировалось создать методику оценки RTT не одним из указанных выше методов, а путем сложения значений двух односторонних задержек. Для этого следовало поступить так: удалить частотный сдвиг из следа эксперимента, вычислить медиану наблюдаемых значений односторонней задержки от хоста 'Master' к хосту 'Slave', затем аналогичным образом вычислить медиану значений односторонней задержки от 'Slave' к 'Master'. После этого полученные медианы сложить и, согласно методу, суть которого изложена ранее, получить в результате значение RTT для данного эксперимента. Достоинство этого метода перед рассмотренными в том, что в нем RTT вычисляется при нагруженной потоками трафика сети, в то время как измерения с использованием ping и подобных методов часто проводятся на ненагруженной сети, что дает оптимистичные результаты для значений RTT. Однако воспользоваться этим методом не удалось: из-за отсылки пакетов пачками динамика трафика приняла сложный характер, и линейное увеличение односторонней задержки из-за частотного сдвига совершенно не прослеживалось. В результате частотный сдвиг удалялся неверно. Это привело к тому, что полученное методикой значение RTT было значительно (в два-три раза) выше того, которое сообщала для данной сети утилита ping. Чтобы упростить дальнейшие исследования, рекомендуется применять комплекс из двух программ для измерения RTT, аналогичный описанному выше. Запуск программы, отправляющей эхо-запросы, следует производить с началом измерения (то есть когда сеть будет нагружена), а после его окончания производить статистический анализ измеренных значений RTT. В данной работе не удалось реализовать эти дополнительные измерения в связи с техническими проблемами в работе хоста 'Abiturient'.

Значение RTT полезно для оценки характеристик сети. Если две его составляющие – односторонние задержки в каждую сторону – примерно равны, то можно использовать RTT /2 для оценки усредненной односторонней задержки. Сравнив это значение с критическим значением сетевой задержки для данного метода кодирования, после которого качество восприятия мультимедийного потока в интерактивном приложении резко падает, можно оценить качество компьютерной сети.

Так как без синхронизированных часов не существует способа оценить, насколько близки друг к другу значения двух односторонних задержек, а, значит, законно ли использовать RTT /2 как оценку односторонней задержки, можно воспользоваться косвенным методом: построив топологическую карту сети и оценив асимметричность маршрутизации. Метод построения топологической карты сети, который здесь предлагается, по своей природе будет неточным из-за недостатка информации, но пример, приведенный ниже, показывает, что асимметричность с его помощью можно обнаруживать и оценивать. Карта сети строится по результатам анализа данных, выводимых утилитой traceroute [23], при трассировке от одного хоста к другому и затем обратно. Построенная карта отражает состояние сети лишь на момент построения: в любой другой момент времени связи между маршрутизаторами могут измениться, и карту придется строить заново. Однако, маршруты в глобальных сетях обычно либо относительно стабильны (остаются постоянными по крайней мере на несколько дней), либо постоянно имеется более чем один маршрут от источника до приемника, и передаваемые пакеты задействуют все эти маршруты. Более подробные сведения о характеристиках маршрутов глобальных сетей содержатся в [24]. На рис. 3 приведены результаты выполнения traceroute по обоим маршрутам. На рис. 4 представлена построенная на основе этих данных карта сети. [alice04]$ traceroute abiturient.stu.neva.ru traceroute to abiturient.stu.neva.ru (194.85.96.169), 30 hops max, 38 byte packets

1 wrk-ptc (195.19.225.65) 1.467 ms 1.320 ms 1.341 ms

2 CH0.LE-PTC.spbu.ru (195.19.224.18) 3.119 ms 5.414 ms 3.280 ms

3 spb-4-gw.runnet.ru (194.190.255.157) 6.063 ms 36.462 ms 16.570 ms

4 spb-gw.runnet.ru (194.85.36.41) 131.024 ms 14.295 ms 19.970 ms

5 RUSnet-gw.runnet.ru (194.190.255.142) 12.401 ms 13.164 ms 7.990 ms

6 filter.stu.neva.ru (194.85.4.8) 12.361 ms 14.536 ms 13.515 ms

7 abiturient.stu.neva.ru (194.85.96.169) 15.062 ms 8.504 ms 7.779 ms

[abiturient]$ traceroute alice04.spbu.ru traceroute to alice04.spbu.ru (195.19.225.94), 30 hops max, 38 byte packets

1 RUSnet-SPbGPU-gw.neva.ru (194.85.96.62) 0.278 ms 0.229 ms 0.162 ms

2 INT-6.100M.le-gw.RUSnet.ru (194.85.4.242) 1.704 ms 1.619 ms 1.661 ms

3 INT-1.100M.le-gw2.RUSnet.ru (194.85.4.12) 0.606 ms 0.632 ms 0.584 ms

4 spb-gw.runnet.ru (194.190.255.141) 2.393 ms 3.076 ms 3.678 ms

5 spb-ix.runnet.ru (194.85.36.42) 3.300 ms 3.033 ms 4.419 ms

6 ptc.spbu.ru (194.190.255.158) 11.430 ms 3.808 ms 3.956 ms

7 PTCgate.spbu.ru (195.19.224.25) 8.756 ms 6.787 ms 7.573 ms

8 alice04.spbu.ru (195.19.225.94) 7.634 ms 21.700 ms 26.742 ms

Рис. 2. Данные утилиты traceroute при трассировке в обе стороны. На рис. 4 прямоугольники обозначают маршрутизаторы, знаками вопроса обозначены те IP-адреса интерфейсов, которые не удалось определить по данным traceroute. Асимметричность наблюдается в сегменте сети провайдера RusNet. Так как разница в числе переходов для маршрутов в обе стороны равна 8-7=1, такая асимметричность вряд ли препятствует использовать значение RTT /2 как оценку для односторонней задержки.

Рис. 3. Топологическая карта сети, построенная на основе данных traceroute

Трафик, генерируемый каждым хостом, формировался следующим образом: генерировалась пачка из 10 пакетов по 1400 байт каждый, затем следовала пауза в 1 с. Этот поток похож на трафик RealAudio, но создает большую нагрузку на сеть. Средняя битовая скорость его составляет около 67 Кбит/сек (в каждую из двух сторон). Этого достаточно для передачи около 10 потоков RealAudio с низким качеством трансляции речи (6,5 Кбит/сек), или около 4 потоков RealAudio с музыкальной информацией в среднем качестве (16 Кбит/сек), или для одного видеопотока со звуком низкого качества. Каждое измерение длилось 180 с. Размер пакета был выбран большим, чтобы можно было оценить битовую скорость узкого места сети (см. далее), но при возможности провести больше измерений следует выбирать размер пакета, типичный для приложения, которое планируется использовать в исследуемой сети. Кроме того, следует устанавливать битовую скорость потока в соответствии с ожидаемой нагрузкой на сеть.

Для каждого следа эксперимента вычислялись следующие параметры компьютерной сети:

1. Интерквартильный промежуток для наблюдаемых значений интервалов между поступлениями пакетов по данным MGEN – вычислялся для обоих направлений потока и являлся мерой проявления 'дрожания' (неравномерности поступления пакетов). Так как пакеты высылались пачками по 10 штук, то интервалы между поступлениями соседних пакетов в пачке были малы и определялись передачей пакетов по сети, а интервал между последним пакетом пачки и первым пакетом следующей пачки составлял около 1 с и определялся паузами между пачками. Поэтому все интервалы более 0,9 с не учитывались при анализе в целях упрощения.

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

Выводы

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

понятие мультимедиа. Скорее всего, он служил ширмой, которая ограждала лаборатории от взглядов непосвященных ("А что это у тебя там звенит". "Так это мультимедиа"). Человечество переживает информационную революцию. И вот мы становимся свидетелями того, как общественная потребность в средствах передачи и отображение информации вызывает к жизни новую технологию, за неимением более корректного термина называя ее мультимедиа. В наши дни это понятие может целиком заменить компьютер практически в любом контексте. Понятие мультимедия также успешно можно отнести и к быстро возрастающей паутине Интернет. В начале развития Интернет web-страницы не представляли собой ничего интересного, речи не могло идти о том, что пользователь может посмотреть, TV-трансляцию, послушать FM-радио, скачивать музыкальные композиции, а так же пополнить свою фильмотеку любимыми фильмами

Цель и задачи работы

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

Планируемая практическая ценность

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

Обзор уже существующих методов по теме магистрской работы

1. Anna Watson and M. Angela Sasse. "The Good, the Bad, and the Muffled: the Impact of Different Degradations on Internet Speech". University Colledge London, 2000.

2. Art Mena and John Heidemann. "An Empirical Study of Real Audio Traffic", in Proceedings of the IEEE Infocom, Tel-Aviv, Israel, Mar. 2000, USC/Information Sciences Institute, pp. 101-110, IEEE

3. H. Schulzrinne, A. Rao, R. Lanphier. Real Time Streaming Protocol (RTSP). April 1998.

4. Internet Engineering Task Force, http://www.ietf.org/

5. ITU-T P.800 Methods for subjective determination of transmission quality. http://www.itu.int/publications/itu-t/iturec.htm

6. Kun-chan Lan, John Heidemann. "Structural Modeling of RealAudio traffic". USC/Information Sciences Institute, 2001.

7. Maureen Chesire, Alec Wolman, Geoffrey M. Voelker, and Henry M. Levy. "Measurement and Analysis of a Streaming-Media Workload", 2001.

8. Network Simulator ns-2, http://www.isi.edu/nsnam/ns/

9.R.Wolff, "Poisson Arrivals See Time Averages", Operations Research, 30(2), pp. 223-231, 1982.

10.RealNetworks, "RealNetworks documentation library", http://service.real.com/help/library/

11.RFC1305. Network Time Protocol (Version 3). Specification, Implementation. D. Mills. March 1992.

12.RFC2205. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997.

13.RFC2330. Framework for IP Performance Metrics. V. Paxson, G. Almes, J.Mahdavi, M. Mathis. May 1998.

14.RFC2474. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, D. Black. December 1998.

15.RFC2679. A One-way Delay Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999.

16.RFC2680. A One-way Packet Loss Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999.

17.RFC2681. A Round-trip Delay Metric for IPPM. G. Almes, S. Kalidindi, M.Zekauskas. September 1999.

18.RFC777. Internet Control Message Protocol. J. Postel. Apr-01-1981.

19.RFC791. Internet Protocol. J. Postel. Sep-01-1981.

20.Vern Paxson, "Measurements and Analysis of End-to-End Internet Dynamics". University of California, Berkeley, 1997.

21.Vern Paxson, Sally Floyd. "Why we don't know how to simulate the Internet". Proceedings of the 1997 Winter Simulation Conference.

22.А.Г.Жданов, Д.А.Рассказов, Д.А.Смирнов, М.М.Шипилов. "Передача речи по сетям с коммутацией пакетов (IP-телефония)". Санкт-Петербургский государственный университет телекоммунникаций им. проф. М.А.Бонч-Бруевича. 2001 г.

23.В.Г.Олифер, Н.А.Олифер. "Новые технологии и оборудование IP- сетей". СПб.: БХВ-Петербург, 2001 г.- 512 с., ил.

24.В.Г.Олифер, Н.А.Олифер. Компьютерные сети. Принципы, технологии, протоколы. СПб: Питер, 2001. - 672 с., ил.