Автореферат

Введення й обґрунтування актуальності теми

     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. Частка втрат пакетів протягом одного виміру також обчислювалася для обох напрямків потоку. Після обчислень для кожного сліду результати відображалися на графіку у вигляді погодинної залежності протягом доби. Інтервали між прибуттями пакетів відхиляються від свого середнього значення через природу мережі з пакетною комутацією: чим більше зайняті проміжні маршрутизатори, чим длиннее в них черги, тим більше затримуються пакети в порівнянні зі своїми сусідами. Робастной оцінкою для відхилень інтервалів між прибуттями від середнього значення є интерквантильный проміжок вибірки. Тому при заданому типі трафика зміна интерквантильного проміжку із часом характеризує завантаженість мережі.

Висновки

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

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

2. Art M. and Heidemann John. "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. Schulzrinne H. , Rao A., Lanphier R.. 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, Heidemann J.. "Structural Modeling of RealAudio traffic". USC/Information Sciences Institute, 2001.

7. Maureen C., Wolman A., Geoffrey M., 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. Wolff R., "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. Mills D. March 1992.

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

13.RFC2330. Framework for IP Performance Metrics. Paxson V., Almes G., Mahdavi J., Mathis M.. 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. PaxsonVern, "Measurements and Analysis of End-to-End Internet Dynamics". University of California, Berkeley, 1997.

21.Paxson Vern. "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 с., ил.