Содержание к диссертации
Введение
ГЛАВА 1. Обзор измерительных механизмов производительности IP сетей 13
1.1 Метрики производительности IP сетей в стандартах RFC 13
1.2 Способы измерения односторонней и двухсторонней сетевых задержек, джиттера и потерь сетевых пакетов 17
1.3 Синхронизация времени для измерения односторонней сетевой задержки 19
1.4 Измерение доступной пропускной способности сетевого канала 22
Выводы по главе 1 30
ГЛАВА 2. Разработка программно-аппаратного комплекса для измерения односторонней сетевой задержки 31
2.1 Требования к аппаратной части комплекса 31
2.2 Требования к программной части комплекса 36
2.3 Измерение метрик производительности IP-сетей 42
2.4 WEB-интерфейс для онлайн-доступа к экспериментальным данным 44
Выводы по главе 2 52
ГЛАВА 3. Оценка точности измерений метрик производительности IP-сетей 53
3.1 Точность программной реализации серверов точного времени 53
3.2 Анализ основных компонентов односторонней сетевой задержки 56
3.3 Принцип измерения доступной пропускной способности сетевого канала 61
Выводы по главе 3 62
ГЛАВА 4. Результаты измерений и их обсуждение 63
4.1 Построение функции распределения сетевой задержки на основе экспериментальных данных 63
4.2 Джиттер 65
4.3 Данные о потерях пакетов 88
4.4 Доступная пропускная способность пакетов 92
Выводы по главе 4 93
Заключение 94
Список сокращений 95
Список литературы 97
- Способы измерения односторонней и двухсторонней сетевых задержек, джиттера и потерь сетевых пакетов
- Требования к программной части комплекса
- Анализ основных компонентов односторонней сетевой задержки
- Доступная пропускная способность пакетов
Введение к работе
Актуальность темы
В конце 1990х было создано семейство стандартов IETF RFC, описывающих качество связи в сети Интернет, эти стандарты объединены под общим названием метрики производительности IP-сетей (IP Performance Metrics, IPPM). К основным метрикам производительности IP-сетей относятся: временная задержка пакетов (одно- и двухсторонняя), вариация задержки (сетевой джиттер), величина потери пакетов и доступная пропускная способность канала. Разработчиками указанных стандартов являются специалисты рабочей группы по сетям (Network Working group): V. Paxson, G. Almes, S. Kalidindi, M. Zekauskas, A. Morton, C. Demichelis, P. Chimento.
Диагностика сетей является важнейшей задачей для операторов связи, она помогает находить и устранять недостатки различной природы. При этом сетевая задержка является базовой метрикой, остальные метрики рассчитываются на основе величины сетевой задержки.
Односторонняя задержка пакетов (one-way delay, OWD) является одной из ключевых метрик производительности IP-сетей и описана в RFC 7679. Согласно стандарту ITU-T Y.154 эта метрика является определяющей для приложений реального времени, интерактивных приложений, а также систем управления с использованием глобальной сети. Односторонняя сетевая задержка является инструментом для выявления асимметричных IP-каналов в глобальной сети, когда пути сетевого пакета в прямом и обратном направлениях различаются. Возможность отслеживания изменений сетевых маршрутов позволяет отказаться от использования утилиты traceroute, результаты работы которой с трудом поддаются автоматизированной обработке. Основная трудность при измерении односторонней задержки заключается в необходимости синхронизации системного времени на удаленных устройствах.
Высокая точность измерений является результатом синхронизации времени измерительных узлов, что позволяет использовать созданный инструмент для поиска статистических зависимостей. Одним из наиболее важных требований, предъявляемых к сетям нового поколения, является низкая задержка передачи, другими словами, малое время отклика системы. Например, новейшая беспроводная концепция «Тактильный интернет» была выдвинута ITU в августе 2014, как сеть, обеспечивающая сверхмалую задержку, а также высокую работоспособность и надежность. Измерение таких задержек возможно только с помощью новых измерительных механизмов, так как точность традиционной утилиты ping ограничена величиной 0,1мс.
Степень разработанности темы исследования
Для анализа сетевой задержки предложены различные классификационные схемы. Первый подход состоит в анализе природы сетевой задержки (L. Carbone, F. Coccetti, C.J. Bovy, H.T. Mertodimedjo, S. Donnelly, I. Graham, R. Wilhelm). Второй подход исследует задержку как переменную величину, носящую случайный характер (B.-Y. Choi, S. Moon, K. Papagiannaki, T. Elteto, S. Molnar, G. Hooghiemstra, P. van
Mieghem).
Основными инструментами по измерению односторонней сетевой задержки являются RIPE NCC Test Traffic Measurement (RIPE TTM) и One-Way ping (OWAMP). В настоящее время оба этих проекта не поддерживаются. Вместо них при поддержке IETF запущен проект RIPE Atlas. Он позволяет работать в сетях стандартов IPv4 и IPv6 и собирать информацию только о величине двусторонней сетевой задержки (RTT) в соответствии со стандартом RFC 2678. Существенным недостатком данного подхода является невозможность выявления асимметричных каналов связи. Данный проект существенно отличается от RIPE TTM использованием максимально доступных и простых в первичной настройке (использована идеология plug-and-play) измерительных узлов. В связи с этим измерение односторонних задержек в глобальной сети является актуальной научной проблемой.
Целью работы является исследование принципов построения и разработка программно-аппаратного комплекса для измерения метрик производительности IP сетей, а также анализ экспериментальных данных, полученных в процессе тестовой эксплуатации.
Для достижения поставленной цели в диссертационной работе решаются следующие основные задачи:
-
Разработка измерительных механизмов, основанных на временной синхронизации, позволяющих находить основные метрики производительности IP-сетей.
-
Разработка методик, позволяющих оценить точность созданных методов измерения метрик производительности IP-сетей.
-
Уточнение типа функции распределения для односторонней задержки, справедливого для больших временных интервалов.
-
Разработка программно-аппаратного комплекса, позволяющего измерять одностороннюю сетевую задержку и исследовать природу ее составных компонентов.
Объект исследования – односторонняя сетевая задержка, природа основных компонентов и математическое описание (тип распределения случайной величины).
Предмет исследования – механизмы синхронизации времени на устройствах, подключенных к глобальной сети, для измерения сетевой задержки, статистические параметры для величины односторонней задержки.
Результаты исследования соответствуют пунктам 2, 4, 11, 14 паспорта научной специальности 05.12.13 – Системы, сети и устройства телекоммуникаций.
Методы исследования
В диссертационной работе для подтверждения гипотезы о типе функции распределения односторонней сетевой задержки используются методы теории вероятности и математической статистики. Методы синхронизации системного времени измерительных узлов, а также подходы к измерению метрик производительности базируются на основе стандартов IETF RFC, а критерии оценки качества сети на основе стандартов ITU-T.
Основные положения диссертации, выносимые на защиту
-
Показано, что разработанный измерительный механизм на основе временной синхронизации от спутниковых систем глобального позиционирования позволяет находить основные метрики производительности IP-сетей, в том числе, одностороннюю задержку с микросекундной точностью.
-
Предложенная методика позволяет оценить точность временной синхронизации на основе отклонений от эталонного сигнала PPS (pulse per second).
-
Комбинированная функция распределения для односторонней сетевой задержки позволяет найти ее генерирующую функцию и справедлива на больших временных интервалах.
-
Формула полезной модели программно-аппаратного комплекса, позволяющего измерять основные метрики производительности IP-сетей на основании разработанных измерительных механизмов.
Научная новизна диссертационного исследования заключается в следующем:
-
Предложен и разработан измерительный механизм, основанный на временной синхронизации по сигналам систем глобального позиционирования, позволяющий находить основные метрики производительности IP-сетей и отличающийся от существующих реализацией сервера точного времени с наибольшей точностью синхронизации.
-
Предложена новая методика, позволяющая оценить точность разработанных методов измерения и отличающаяся от существующих тем, что в качестве ошибки принято отклонение от эталонного сигнала PPS.
-
Предложена и исследована комбинированная функция распределения, позволяющая описать поведение односторонней сетевой задержки на больших временных интервалах, отличающаяся от существующих использованием весового коэффициента.
Теоретическая и практическая значимость работы
Проведена оценка точности синхронизации времени с помощью различных реализаций серверов точного времени и сделан вывод о целесообразности использования NTP-сервера chrony.
Предложена комбинированная функция распределения односторонней сетевой задержки, позволяющая генерировать ее значения на основе заданного набора параметров.
Разработан программно-аппаратный комплекс NetTestBox, позволяющий измерять основные метрики производительности IP-сетей и отличающийся компактными размерами и невысокой стоимостью.
Основные результаты диссертационной работы внедрены в АНО "Российский НИИ развития общественных сетей" для измерения основных метрик производительности IP-сетей, а также в учебном процессе ФГАОУ ВО «Самарский национальный исследовательский университет имени академика С.П. Королева», что подтверждается соответствующими актами о внедрении.
Достоверность и обоснованность научных результатов работы базируется на использовании научных положений и методов исследования, апробации созданного программно-аппаратного комплекса и подтверждается соответствием результатов теоретических и экспериментальных исследований.
Личный вклад автора заключается в том, что все основные научные положения, выводы и рекомендации, составляющие содержание диссертационного исследования, разработаны автором лично.
Апробация работы
Результаты диссертации докладывались и обсуждались на международных конференциях IEEE «Telfor 2015» и «Telfor 2016» в г. Белград, Сербия; на международной научной технической конференции «Перспективные информационные технологии» (г. Самара, 2015), на VII Всероссийской научно-практической конференции «Проблемы передачи информации в инфокоммуникационных системах» (г. Волгоград, 2016), на XVII Международной научно-технической конференции «Проблемы техники и технологий телекоммуникаций» (ПТиТТ-2016) в рамках первого научного форума «Телекоммуникации: теория и технологии» 3Т-2016 (г. Самара, 2016 г.).
Работа была поддержана грантами РФФИ 13-07-00381а и 16-07-00218а и проектной частью Государственного задания Минобрнауки России (2.974.2017/ПЧ): 2017—2019 гг.
Публикации
По теме диссертации опубликованы одиннадцать работ, три из которых в изданиях, рекомендованных ВАК Минобрнауки России. Получен патент на полезную модель. Одна статья опубликована в научном журнале, индексируемом международной базой цитирования «Сеть науки» (WoS). Две статьи на английском языке по итогам докладов, представленных на конференциях IEEE, опубликованы в электронной библиотеке IEEEXplore и индексируются международными базами цитирования WoS и Scopus. 5 работ – в материалах и трудах Международных и Всероссийских конференций.
Структура и объём диссертации
Диссертация состоит из введения, четырех глав, заключения и списка литературы. Работа изложена на 106 страницах машинного текста, содержащих 50 рисунков и 12 таблиц. Список использованных источников насчитывает 76 наименований.
Способы измерения односторонней и двухсторонней сетевых задержек, джиттера и потерь сетевых пакетов
В 1986 году была создана международная организация IETF (Internet Engineering Task Force) – Инженерный Совет Интернета [6]. Это открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, в задачи которой входят:
Идентификация проблем и предложение решений в технических аспектах организации Интернета; Разработка спецификаций, стандартов и соглашений по общим архитектурным принципам протоколов Интернет; Вынесение рекомендаций относительно стандартизации протоколов на рассмотрение Internet Engineering Steering Group (IESG); Содействие широкому распространению технологий и стандартов, разрабатываемых в Internet Research Task Force (IRTF); Организация дискуссии для обмена информации в сообществе Интернета между учёными, разработчиками, пользователями, производителями оборудования и услуг, сетевыми администраторами и т. д.
Результатом решения задач поставленной перед организацией является разработка рабочих предложений RFC (Request for Comments), выносимых на обсуждение интернет-сообщества [7]. В настоящее время такие документы используются в качестве стандартов в сети Интернет, они охватывают многие аспекты, такие как протоколы, процедуры, программы, мнения об отдельных актуальных вопросах отрасли.
В связи с расширяющейся областью применения современных компьютерных сетей и быстрым ростом объема трафика, передаваемого в глобальной сети Интернет, оценка качества сетевых соединений становится все более насущной проблемой для провайдеров, крупных компаний, организаций, учреждений и других категорий пользователей. В конце 1990х было создано целое семейство стандартов, описывающих качество связи, эти стандарты объединены под общим названием IP Performance Metrics [8,9]. Помимо документов, описывающих общие подходы в оценке производительности сетевого соединения, были предложены отдельные стандарты, описывающие следующие метрики: двухсторонняя сетевая задержка (Round Trip Time, RTT) [12], односторонняя сетевая задержка (One Way Delay, OWD) [10], сетевой джиттер (Jitter, вариация задержки) [13], величина потерь пакетов (Packet loss) [14] и доступная пропускная способность канала (Available bandwidth) [15]. Рассмотрим каждую из них подробнее.
Двухсторонняя сетевая задержка описана в стандарте RFC 2681 [12] и определяется как время, необходимое на передачу пакета между сетевыми узлами плюс время на получение подтверждения доставки пакета удаленным узлом. Иными словами, это временной промежуток между отправкой первого бита пакета от источника к приемнику и получением последнего бита ответного пакета от приемника к источнику.
Односторонняя сетевая задержка является одной из ключевых метрик IPPM и описана в RFC 7679 [10]. Значение этой метрики находиться как время передачи пакета определенного типа между двумя узлами сети. Под определенным типом понимается пакет, который имеет набор заранее заданных признаков; стандарт жестко не оговаривает эти признаки, но указывает, что ими могут быть, например, размер пакета, тип приложения, сгенерировавшего пакет, тип протокола транспортного уровня, доставившего пакет, а также некоторые другие. Смысл используемого набора признаков состоит в том, чтобы выделить из общего потока пакетов, приходящего в узел назначения, те пакеты, характеристики которых интересуют специалиста, проводящего измерения.
Две указанные метрики удобно сравнить между собой, выделив их достоинства и недостатки в практическом применении. Двусторонняя сетевая задержка обладает следующими достоинствами: Простота реализации процесса измерения- в большинстве случаев не требуется установка измерительного оборудования и специального программного обеспечения на стороне приемника сетевых пакетов. Разработанная Майком Мууссом в декабре 1983 года [16] утилита Ping и изначально включенная в состав ядра операционной системы BSD UNIX в последующем была скомпилирована и включена в состав большинства современных операционных систем.
Простота интерпретации: часто практический интерес представляет именно время оборота сетевого пакета от источника к приемнику и обратно.
Недостатки двусторонней задержки более существенны: сетевые каналы передачи данных во многих случаях являют асимметричными, и величина двусторонней задержки становится малоинформативной метрикой для оценки производительности сети; даже если сетевой канала является симметричным, производительность в прямом и обратном направлениях может кардинально различаться из-за использования механизмов ассиметричного массового обслуживания в сетевых роутерах на пути IP-пакета; производительность сетевого прикладного приложения может существенно зависеть от передачи данных только в одном из двух направлений. в сетях, использующих механизмы QoS (Quality-of-Service) выделение ресурсов в одном из направлений может существенно отличаться от выделения ресурсов в противоположном направлении, что также делает двустороннюю сетевую задержку малоинформативной метрикой.
Требования к программной части комплекса
Этот раздел хотелось бы начать с обзора популярной утилиты ping, измеряющей двухстороннюю задержку. Стандартная системная утилита ping состоит из двух частей: серверной и клиентской. Серверная часть, включенная в ядро операционной системы Linux, которая получает ICMP запросы и отвечает на них. Клиентская программа, запускаемая пользователем, отправляет запросы к удаленному сетевому узлу, затем получает ответы и накапливает статистику.
По сравнению со стандартной утилитой ping для измерения односторонней задержки необходимо знать время отправки пакета клиентом, время приёма сервером, время отправки сервером и время приёма ответа клиентом. На основе этих данных не трудно вычислить значение односторонней задержки в каждую сторону.
В протоколе ICMP заложена возможность отправки метки времени в запросе, но, к сожалению, это поле ограничено длиной 32 бита [60]. Системное время в ОС Linux задается с точностью до 1нс. Временная метка с такой точностью в формате Epoh занимает 64 бита. Следовательно, при написании новой утилиты часть данных о времени придётся отбросить, например, дату, месяц и год. C сервера должен поступить пакет с двумя датами: время получения и отправки. Такое поведение не описано в протоколе ICMP.
Кроме эхо-запросов в стандарте ICMP время можно передавать в специальных запросах метки времени. Там уже предусмотрены три поля для времени, каждое 32 бита: начальное время, время приёма и время отправки. Но формат этих пакетов не соответствует обычным эхо запросам, и они могут иначе обрабатываться сетевым оборудованием, а самое главное – иметь другой маршрут. Кроме того, часть информации о дате будет также потеряна.
Есть и ещё одна причина, по которой этот способ запросов, примененный при реализации утилиты ping, не подходит. Она заключается в том, что запросы метки времени не предполагают посылку пакетов разного размера. Для проведения измерений доступной полосы необходимо осуществлять тестирование сети пакетами различного размера.
Согласно стандарту ICMP [42] существует возможность задать собственный тип пакетов для исследований, но в данном случае также могут быть проблемы совместимости сетевого оборудования и программного обеспечения.
Наилучшим выходом из данной ситуации является добавление метки времени в тело сообщения ping. Минимальный размер Ethernet пакета по стандарту IEEE 802.3 – 64 байта. В случае отправки пакета меньшего размера на физическом уровне он дополняется нулями. Заголовки Ethernet (с контрольной суммой), IP и ICMP в сумме занимают 46 байт. Оставшиеся 18 байт можно использовать для передачи полных меток времени от сервера к клиенту. На рисунках 2.2, 2.3 показана получившаяся структура пакета.
Сигнатура – это ключевое слово, которое позволяет серверу понять, что запрос сделала не обычная программа ping, а специализированная программа для измерения односторонней задержки owping. Это поле введено для совместимости со стандартной утилитой ping, ведь в обычном случае сервер должен полностью скопировать нагрузку из пришедшего пакета в ответный пакет, а в случае с owping сервер должен вставить время приёма и отправки. Кроме того, в этом идентификаторе указывается версия протокола, что позволит в будущем не иметь проблем с совместимостью различных версий программы owping. В актуальной версии программы эта строка следующая: «owpingsignatura1». Структура запроса
Номер последовательности – это поле, дублирующее поле «номер последовательности» в ICMP протоколе для UDP протокола. Дело в том, что каждый ICMP эхо пакет распознаётся по идентификатору последовательности и номеру пакета в последовательности. В UDP протоколе в качестве идентификатора выступает порт, а номер последовательности не учитывается.
Таким образом, если запрос делается обычной ping программой, то и ответ будет обычным, а если программой owping, которая распознаётся по идентификатору, то в ответ будут отправлены метки времени.
Как клиентская часть программы, так и серверная написаны с нуля на языке программирования С. Это было сделано исходя из тех соображений, что модификация части ядра Linux крайне затруднительна как с точки зрения совместимости, так и трудозатрат. Ведь в этом случае на уровне ядра придётся работать с точными метками времени, с сетью, а также необходимо заставить эту часть программы выполняться в режиме реального времени. И всё это должно функционировать в крайне разнородной Linux среде и быть удобно в установке и использовании.
Режим реального времени, в данном случае, необходим для того, чтобы быть уверенным, что пакеты будут приняты и отправлены без задержек, влияющих на измерения. Такие задержки могут возникнуть, если другая программа прервёт процесс выполнения owping.
Анализ основных компонентов односторонней сетевой задержки
В таблицу внесены только важнейшие этапы, длительность которых может быть измерена при выполнении программного кода. Формирование пакета программой-клиентом выполняется до начала отсчета односторонней задержки. Обработка полученного пакета, формирование ответного пакета на сервере осуществляется после получения временной отметки о прибытии пакета и до отметки об начале измерения обратной задержки. То есть эти этапы не должны учитываться при анализе сетевой задержки. Не оказывают влияния на задержку и обработка пакета на клиентской стороне после его возвращения.
Анализ данных, приведенных в Таблице 3.2 показывает, что время выполнения программного кода и время выполнения соответствующего этапа измерительного механизма не совпадают. Поэтому использовать метод временных меток программного кода для анализа длительности этапов измерительного механизма не представляется возможным.
Стоит указать, что, начиная с версии 2.6.30, ОС Linux поддерживает опцию сетевого сокета SO_TIMESTAMPING, которая позволяет пользовательскому сокету получать временные метки для отправляемых и принимаемых пакетов. Временные метки могут быть сняты самим ядром, драйвером или сетевым устройством. Данная опция при должной поддержке аппаратным обеспечением позволит в дальнейшем модернизировать утилиту owping и уточнить величины временных задержек, возникающих на стадии отправки и получения сетевых пакетов [68].
Следующая особенность полученных результатов измерений, которая нуждается в обсуждении, состоит в том, что задержка на участке клиент-сервер всегда больше, чем в обратном направлении. Это замечание справедливо не только для эксперимента в локальной сети, но также для любой пары измерительных узлов, задействованных в эксперименте.
Выше было показано, что процессы передачи пакетов от клиента к серверу и обратно полностью идентичны за исключением последнего этапа. Процедура получения пакета на сервере включает копирование пакета в ядро, проверку его целостности и передаче в программу owping. При приеме пакета на клиенте время фиксируется сразу по получению последнего бита. Ряд операций осуществляется после этого момента и их длительность не входит в задержку на обратном пути. При этом основной вклад вносит процесс передачи данных из ядра ОС в программу owping, длительность этого процесса составляет 20-25 мкс (см. таблицу 3.2). То есть задержка обратного пути пакета должна быть короче на это время.
Рассмотренные в Главе 1 способы измерения доступной пропускной способности сетевого канала наделены различными недостатками. При разработке программно-аппаратного комплекса была поставлена задача практической реализации альтернативного способа активного измерения метрики доступной пропускной способности (ДПС) сетевого канала - максимальной пропускной способности уровня IP сетевого канала, которая может быть предоставлена потоку данных в конкретной ситуации загруженности маршрута конкурирующим трафиком [21]. Данный метод был предложен в статьях [38,39,40] и базируется на методе тестирования сети пакетами различного размера (Variable Packet Size). Изначально данная технология использовалась [30] для оценки полной пропускной способности (ППС) сетевого канала, но в статьях [69,70] математически обоснована возможность измерения ДПС с помощью указанной технологии. Как было показано в разделе 3.2, в составе односторонней сетевой задержки можно выделить физическую и телекоммуникационную компоненты: D = D+ — + dvm min т-j v3r Именно телекоммуникационная компонента определяет ДПС в каждый момент времени. На основе приведенной формулы выражения для пакетов размером W1 и W2 примут вид: А = А + j + d D = D +lf + d Для большого количества измерений можно принять, что dvar1=dvar2, тогда получим: ж, -ж А-А- в Окончательно в статье [69] предложена следующая формула расчета доступной пропускной способности: и2 — их где Wi, W2 - размеры первого и второго сетевых пакетов, Di, D2 соответствующие односторонние сетевые задержки первого и второго пакетов. В этом случае размеры пакетов W1 и W2 должны различаться на наибольшую величину в пределах максимального размера блока передачи MTU (Maximum Transfer Unit) .
В данной главе рассмотрены вопросы оценки точности измерений односторонней сетевой задержки пакетов с помощью аппаратно-программного комплекса NetTestBox. Проведены измерения точности синхронизации системного времени измерительного узла с помощью различных программных реализаций серверов NTP и сделан вывод о целесообразности использования сервера chrony в составе программного обеспечения комплекса. При отсутствии регулярной синхронизации каждые 40 минут системное время будет отклоняться от эталонного на 0,5 с. Проведен анализ и дана интерпретация основный составляющих односторонней сетевой задержки в локальной и глобальной сетях, определены их длительности, а также влияние на величину общей задержки сетевого пакета. Отдельное внимание уделено механизму измерения доступной пропускной способности сетевого канала с помощью пакетов различного размера, приведены теоретические основания о возможности использования в составе программно-аппаратного комплекса NetTestBox.
Доступная пропускная способность пакетов
Как видно из таблицы 4.6 характеристики глобальной сети в период с 2006 по 2016 годы улучшились более чем на порядок. В настоящее время сетевой канал характеризуется как отличный, если величина потерянных пакетов не превышает 0,5 % по отношению к общему количеству переданных пакетов.
Для уточнения величины потерь пакетов на реальных сетевых маршрутах были проведены эксперименты по измерению величин односторонних сетевых задержек и оценке количества потерянных пакетов за выбранный период. Эксперимент был проведен в феврале 2017 года на 12 реальных сетевых маршрутах, период проведения измерения равнялся одним суткам. Измерения проводились с темпом 1 измерение в 30 секунд. В сеть передавались пакеты протоколов ICMP и UDP, размер пакетов составлял 18 байт и 1018 байт. За время наблюдения было отправлено 2880 тестовых пакетов. Расчет величины потерь пакетов в процентах был выполнен по следующей формуле: N all-N rcvd х100О/о где Nan-общее количество отправленных пакетов по каждому из маршрутов, Nrcvd-количество успешно полученных пакетов узлом-получателем. Результаты проведенных расчетов приведены в таблицах 4.7 и 4.8.
Для эксперимента, в котором использовался тестовый пакет размером 18 байт, средняя величина потерь пакетов по всем маршрутам составляет 1,105%, для второго эксперимента с размером тестового пакета 1018 байт средняя величина потерь пакетов составила 0,503%. Двукратную разницу в величине потерь пакетов для пакетов малого и большого размера можно объяснить особенностями настройки маршрутизации и сетевой безопасности на оборудовании интернет-провайдеров. Сетевые пакеты минимального размера могут восприниматься как злонамеренные (особенно, это касается пакетов протокола ICMP) и блокироваться брандмауэрами на маршрутизаторах между двумя удаленными измерительными точками. Приложения онлайн-телефонии, видеоконференций, удаленного управления промышленными объектами, предъявляющие высокие требования к качествe IP-сетей, чаще используют пакеты большого размера и в этом случае величина потерь пакетов не превышает величины 0,5%, что может характеризовать сетевые маршруты как отличные по качеству передачи данных. Таблица
В разделе 3.3 приведены теоретические положения о возможности расчета четвертой метрики производительности IP-сетей – доступной пропускной способности сетевого канала (ДПС).
Практический способ измерения доступной пропускной способности сетевого канала реализован с помощью программно-аппартного комплекса NetTestBox. Каждые 30 секунд на каждом измерительном узле запускается скрипт, выполняющий измерение односторонней сетевой задержки до всех, заранее заданных, удаленных узлов. Полученные данные сохраняются во внутреннюю память NetTestBox и запускается независимый процесс передачи данных на центральный сервер сбора, обработки и хранения статистики. Для расчета доступной пропускной способности сетевого канала выполняется усреднение по ста одному значению измерений односторонней сетевой задержки - выборка пятидесяти значений сетевых задержек до исследуемого момента и пятьдесят значений после него. Это позволяет пренебречь величиной dvar при проведении расчетов. Для выполнения расчетов задержек размеры IP-пакетов жестко заданы и равны 64 байта для пакета минимального размера и 1064 байта для пакета максимального размера. Тестирование маршрута осуществляется как пакетами протокола ICMP, так и пакетами UDP, что является существенным для случаев преднамеренного блокирования пакетов протокола ICMP или при наличии на оборудовании интернет – провайдеров «особых» таблиц маршрутизации для пакетов указанного протокола.
Как было показано ранее, программно-аппаратный комплекс NetTestBox обеспечивает абсолютную погрешность измерения односторонней сетевой задержки D не хуже 2 мкс [66]. Для оценки области применимости предложенного метода расчета доступной пропускной способности на основе приведенных данных о размере пакетов и точности измерения односторонних сетевых задержек использовалась формула, приведенная в статье [69] для расчета верхней границы измерения доступной пропускной способности: _ ш -Ш В 2 1 AD где -относительная погрешность измерения ДПС. При величине =10%, что является достаточной величиной для большинства практических применений получаем: В = (1064 64)х8 х 01 = 400Мбит / с
Полученное значение выражает максимальную величину доступной пропускной способность сетевого канала в конкретных условиях загруженности конкурирующим трафиком, которая может быть измерена с помощью разработанного программно-аппаратного комплекса NetTestBox.
В данной главе предложена и экспериментально проверена комбинированная функция распределения для односторонней задержки. Проведены практические эксперименты на трех реальных сетевых маршрутах в глобальной сети Интернет между городами Ростов-на-Дону - Самара, Самара - Колумбия (Миссури, США) и Колумбия (Миссури, США) - Ростов-на-Дону. В ходе экспериментов гипотеза о комбинированной функции распределения была подтверждена с помощью критерия Хи-квадрат Пирсона для временных промежутков до 9 часов. Для указанных маршрутов величина вариации задержки (джиттера) была рассчитана тремя различными способами и подтверждена их тождественность при вычислении коэффициентов функции распределения односторонней сетевой задержки. Проведен эксперимент по вычислению средней величины потерь пакетов на трех указанных выше маршрутах за период наблюдения 24 часа, отправлено 2880 измерительных пакетов в обоих направлениях для каждого из маршрутов при этом величина потерь пактов не превышала 0,5-1%. Сделан вывод о высоком качестве передачи сетевых пакетов в современной сети Интернет и соответствии требованиям большинства программных приложений передачи аудио- и видеоинформации, VoIP, видеоконференций.