Основы тестирования сетей TCP/IP для служб эксплуатации №2.7.2

Итак, идеальный агент-инициатор представлен на рисунке 27. А как быть с идеальным сопряжённым? Увы и ах, не стоит забывать, что сеть работает в первую очередь для пользователей, вспомните сомнение 4 в разделе 2.1, а отнюдь не для измерителей, как бы они ни были настойчивы. Поэтому идеальный сопряжённый агент — это тот, который с минимальными дополнительными затратами способен обеспечить съём требуемых метрик. Вы уже догадались, что итоги предлагается собрать в таблицу? Да, так и будет. А точнее таблиц будет две.

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

Расчёт итогов ведём следующим образом:

1. Если технология поддерживает настройку теста или метрику, выставляем базовую оценку 10, если либо поддерживает не полностью, либо требуется доработка, выставляем 5, если не поддерживает, выставляем 0.

2. Для расчёта дрожания задержки выбираем поддержку одного из алгоритмов, а не все. Так как в случае дрожания принципиально само наличие расчёта, а не полная поддержка всех способов.

3. Каждая базовая оценка умножается на весовой коэффициент. Весовые коэффициенты для настроек распределяются так: для P[s] , N[s] , B[s] — 20, для C[s] — 10, для B[r] — 5. Тем самым мы повышаем значимость базовых настроек и понижаем для второстепенных. Весовые коэффициенты для собираемых обязательных метрик первой очереди распределяются так: для LR[p] , ARTT и одного из дрожаний (RDV[p] , APDV[p] , AMDV[p]) — 20, для AD[p] , AD[r] — 10. Односторонней задержке приоритет понижен, так как обычно они собираются либо обе, либо ни одной, и справедливо рассматривать сумму их весовых коэффициентов равной аналогичному для ARTT . А для всех крайне желательных метрик первой очереди (LR[r] , RR[p] , RR[r] , BW[p]) мы вводим коэффициент 15, чтобы подчеркнуть их значимость, но всё-таки не безусловную необходимость.

4. Все произведения суммируются в итоговую оценку.

Окончательные оценки выносим в последней строке таблицы 6, чтобы наглядно показать, какие технологии предпочтительны к применению. Вы можете проконтролировать наши расчёты, создав в любимом редакторе электронных таблиц контрольный пример. Сами расчёты здесь мы не приводим за их очевидностью.

Таблица 6

Всё вышло вполне логично. Самая простая технология V3, которую широко применяют в рекламе, тем не менее, самая простая. Ну и в самом деле, отсутствие настроек, расчёты только круговой задержки и скорости к этому печальному итогу и должны вести. Не слишком далеко от V3 ушёл стандарт RFC-4656 (OWAMP), ибо изначальный выбор одностороннего характера протокола, как видно, сыграл злую шутку с авторами.

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

Чуть выше ping стоит RFC-2544. Этот стандарт как не реализовывай, как не выводи на реальную сеть, хотя он и предназначен для отделённой среды тестирования (Isolated Test Environment), толку будет немного. Даже bwping, уж на что простая программа и не без ошибок (об этом будет разговор), и то умеет больше. А если туда дописать расчёт дрожания, то и ещё больше! Равно как и примитивная реализация слежения за качеством V2, сделанная скорее в целях имитации бурной деятельности, чем для реального использования заказчиком безусловно неплохих маршрутизаторов. Свободная же программа iperf3 умеет чуть больше bwping, не говоря уже про V2, поскольку сопряжённым агентом использует саму себя и имеет заметное число настроек. За счёт этого получает более высокую итоговую оценку.

Кто в лидерах? Производитель V1 и стандарт RFC-5357 (TWAMP) разделили уверенное второе место, а первое место занял наш идеал. Что и неудивительно.

Наш многоуважаемый читатель, не пропускающий ни одной строки, уже заметил, что чуть выше было обещано две таблицы, а приведена всего одна, причём с готовой оценкой технологий. Где же подвох? А нет такого! В таблице 7 будет приведена обобщённая информация, пригодная для формулировки окончательного требования к протоколам сбора метрик качества. Сформируем матрицу совместимости технологий. То есть, какие агенты-инициаторы будут совместимы с аналогичными сопряжёнными. При этом, как и в таблице чемпионата страны по футболу, где «Ростов» стремится к чемпионству, средняя диагональ будет заштрихована, так как протоколы внутри одной технологии совместимы сами с собой, конечно же, но нас интересует как можно сэкономить на внедрении!

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

1. Базовой оценкой будет итог из таблицы 6.

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

3. При частичной поддержке (например, возможности использовать UDP-эхо или ICMP-эхо в качестве подмены) будет применяться четверть от оценки сопряжённого агента на базе ping. Это логично, так как в любой ОС общего назначения сейчас есть реализация эхо либо на базе ядра, либо на базе системного ПО и большой заслуги в реализации здесь быть не может, в то же время необходимо немного стимулировать включение устройств общего типа в список возможных сопряжённых агентов.

Таблица 7

Итак, что же вышло в итоге? Отсортируем по степени возрастания оценки.

1. V3. Проигрывает всем, так как совместима только сама с собой. Повсеместное внедрение на сколько-нибудь заметное число точек присутствия сети TCP/IP приведёт к невиданному раздутию расходной части бюджета, при этом осмысленного числа метрик мы так и не получим, что ясно из таблицы 6. Ну и знание того, что данная технология проталкивается производителем путём бесплатной установки агентов Q2 в целях, как это преподносится, «объективной проверки», приводит нас к мысли, что оплачивать здесь нечего, вендор пытается собрать компенсацию только в виде рекламы физическим лицам и продажи «отчётов» операторам связи. Непригодно ни в каком виде! Бесплатно — пусть стоит. Помогать трудовым рублём — даже не преступление, а ошибка.

2. RFC-4656 (OWAMP). За счёт очевидной однобокости протокола придётся как устанавливать на сети устройства, так и проводить измерения по два раза. Хотя стандарт и реально реализовать на любом устройстве, тем не менее готовых решений пока, прямо скажем, немного. Следовательно вновь «выхожу один я на дорогу, сквозь туман кремнистый путь блестит». Это явно не то, чего хочется в итоге.

3. RFC-2544. Агент-инициатор совместим сам с собой, ну и с UDP-эхо. Всё. Он даже не способен выполнить ICMP-эхо, хотя кажется, что подобное просто нереально! С учётом незначительного объёма собираемых метрик, повсеместное внедрение данного стандарта приводит к бессмысленной трате ресурсов как разработчиков программ, так и операторов связи. «Заяц — вычёркиваем».

4. iperf3. Заслуги у технологии только благодаря таблице 6. Всё остальное — в недостатках. Код системы открыт. Кажется, что вот-вот сообщество разработчиков создаст совместимость и с другими стандартами, это же так просто — пиши себе на языке Си в свободное от работы время, да и в ус не дуй. Но отсутствие даже попытки создать новый модуль намекает нам на то, что в сообществе нет единства, нет плана действий, нет руководителей, и что самое «прекрасное» в FOSS-сообществе — оно не может существовать без перекрёстного субсидирования. Хорошо, когда рядовой администратор пользуется этим инструментом для своих нужд, это позволяет снизить издержки, мы приветствуем такой подход. Но как это решение внедрять на сеть оператора связи? Следует расставить Linux/BSD-машины? Даже для сопряжённых агентов? Явно не разумно.

5. ping. Все поклонники сетевых игр знают эту программу. Все администраторы после настройки сети первым выполняют именно ping. Практически в любой сколько-нибудь уважающей себя системе мониторинга либо встроен собственный ping, либо используется системный. Про языки программирования и говорить стыдно, модуль ICMP-эхо есть практически везде. Любое сетевое устройство, кроме закрытых межсетевых экранов, по умолчанию отзывается на ICMP-эхо. Даже те, в которые встроены технологии V1, V2 и TWAMP! Даже идеальная технология IQM, есть она или нет, неважно, наверняка на 95% должна отзываться! Глупо не пользоваться тем, что есть. Именно за перекрёстное тестирование ping и набрал столь много. Пусть метрики и будут круговые, на первый случай для отслеживания качества этого довольно. Оператор связи уже может смело ставить задачу в отдел разработки или подрядчику по добавлению в систему мониторинга не одного-двух-пяти посылок на один хост, а сразу многих N[s] , в соответствии с уже озвученными в книге требованиями. И размер пакета указать! И снять все метрики, а не только состояние «ответил/не ответил»! Разумеется, не с центральной точки! Уважающие системы мониторинга давно умеют исполнять запросы с удалённых точек. Чем такие точки не агенты-инициаторы Q1? Первое рабочее решение!

6. bwping. Но есть лучшее решение, уже в базе имеющее больше баллов, чем свой исторический коллега. Больше, так как умеет принимать в виде настройки параметр скорости B[s] . Можно в качестве базы для будущего глобального отслеживания качества в операторе использовать исходный код bwping. А то и просто его вызывать! Реально? Более чем! Мы уверены, что программистам будет даже интересно! Лучше всего, конечно, добавить в код расчёт RR[p] , AMDV[p] , OR[p] , SR[p] , мы видели похожие реализации и находим, что в условиях ограниченности бюджета оператора это более чем разумный выход. В итоге у вас уже почти готовый к применению агент-инициатор Q1. А сопряжёнными Q2 выступают многочисленные разнесённые устройства. Правда, следует заметить, что нагрузочное тестирование может быть затруднено, но подробно поговорим об этом позже. Пока фиксируем в блокнот, что второе рабочее решение превышает по возможностям первое, а стоит примерно столько же.

7. V2. Как ни хорошо ICMP-эхо и его расширенный вариант, как его не дописывай, но когда вам придётся выяснять, почему именно в Зимовники идут потери, а оттуда их нет, почему перекраска трафика происходит только в направлении Богучара, а обратно всё отлично, вам придётся принять нелёгкое решение внедрять протоколы, где видны направления. Эхо-протоколы не дают этой информации, поэтому умные производители, поняв перспективы, реализовали свои собственные недокументированные протоколы измерений односторонних метрик. Что позволяло при наличии на сети устройств нужного изготовителя организовать проверки качества с сохранением результатов либо на самих устройствах, либо в системах управления. Одним из примеров является технология V2. Легко видеть в таблице 7, что она получила более высокую оценку, чем bwping, так как предусматривает расчёт некоторого числа метрик с выделением направления трафика. Однако, означает ли это, что её следует немедленно внедрять, расставляя по сети агенты-инициаторы с указанным заводским клеймом? Нет! И вот почему. Забегая вперёд, скажем, что есть более цивилизованные способы потратить бюджет, и есть более цивилизованные технологии с числом метрик, превышающим V2, кроме того, с альтернативной реализацией, позволяющей выбрать мудро. Подробности будут в разделе критики. Что же касается использования устройств V2, которые уже стоят на сети, то при условии поддержки ими не только эхо-протоколов, а и совместимых технологий (допустим TWAMP), их использование в качестве сопряжённых агентов Q2 не только возможно, а прямо нами рекомендуется! Впрочем, сам протокол V2 не столь уж сложен, и при некотором навыке ваш любимый отдел программирования или ваш любимый производитель ПО вполне способен добавить в существующий агент-инициатор поддержку нужного функционала.

8. V1. Так как производитель V1 со своей технологией получил высокую оценку, отметим, что, как и в предыдущем случае, решение поддержать расчёт односторонних метрик было ими принято задолго до сегодняшнего дня. Поэтому имелись все возможности рассчитать почти весь спектр параметров, за исключением разве что RR[p] и RR[r] , что даже удивляет нас, памятуя то, что работать с политиками контроля качества по полю ToS V1 умел хорошо на большом числе моделей. Разумеется, в таких условиях оператор связи был вынужден расставлять в качестве сопряжённых агентов Q2 соответствующие устройства. В документации V1 даже был выработан смешной термин shadow router, как бы намекающий, что хотя тот и находится в тени, но деньги приносит исправно. Правда, не совсем оператору связи, но на что не пойдёшь ради красивых журнальных статей и завиральных идей маркетинга! Но мы не устаём учить всех наших читателей подходить критически к любой технологии. Поэтому в настоящее время рекомендовать данный агент-инициатор никак не можем. Впрочем, если вы уже понесли капитальные затраты и снимаете с этого производителя данные о качестве, то глупо это закрывать вовсе. Это можно и нужно использовать! Допустим, объединяя в общей системе управления. Но вновь ставить — нет и ещё раз нет. Для этого есть другая, более верная возможность. А вот использовать устройства V1 в качестве сопряжённых Q2 — абсолютно верное решение. Можно и нужно. Как в виде TWAMP Session-Reflector, так и с оригинальным протоколом. Благо в России достаточное число талантливых программистов, которые способны и разобраться в существующем и написать новое. Используйте эту Силу, а не выдуманную Лукасом!

9. RFC-5357 (TWAMP). Поскольку стандарт занял высокое место, следует сказать, что разработан он был «Инженерным советом Интернета», безусловно, с оглядкой на V1 и V2. Не удивимся, если теми же самыми людьми. И это разумно. Поскольку даже в существующих реализациях, кроме так называемых "light", которые и реализациями-то назвать нельзя, ибо в сущности это повторение UDP-эхо, расчёт однонаправленных метрик сделан прилежно. А те, что пока не реализованы, допустим RR[p] или AMDV[p] достаточно легко добавить. Почему же в матрице совместимости у него всего три отметки, но при этом первое место? А потому что протокол документирован! Что, читатель? Вы удивлены? Вовремя сказанная шутка — это глоток свежего воздуха! На самом деле, хотя документирование очень важно, но всё-таки в весовых коэффициентах таблицы 7 не предусмотрено. Дело в другом — в технологиях V1 и V2 реализованы TWAMP-совместимые сопряжённые агенты. Не просто ответ на эхо, а полноценные, с управляющим соединением. Равно как и должна быть сама эталонная реализация TWAMP. Поэтому там больше баллов, чем в обратную сторону. Ну и никто не мешает сделать TWAMP-совместимым наш идеал на предпоследней строке. Именно эти три оценки и дали преимущество перед недокументированными протоколами, всё строго математически. Остаётся сказать, что внедрять на сети в качестве базы стоит именно совместимые документированные протоколы, обеспечивающие расчёт однонаправленных и двунаправленных метрик. Таков TWAMP. Записывайте его в качестве обязательного требования к агенту-инициатору Q1, а благие пожелания для будущей гибкости, в частности поддержку эхо-протоколов, будем добавлять в лидера сезона таблицы 7.

10. IQM. Идеал, он и есть идеал. Есть ли он, нет ли его, не столь важно. Важно понимать, к чему мы стремимся в итоге. А стремимся мы к поддержке в одном агенте-инициаторе Q1 как собственных протоколов, так и многочисленных сторонних, от ICMP-эхо и UDP-эхо, что просто и делается чуть не за один день, до сложных TWAMP, V2, V1, что уже не так-то и просто, но мы верим в силу русских связистов и программистов. А зачем мы к этому стремимся? А затем, чтобы в одном агенте-инициаторе объединять множество различных технологий. Пусть на сети будет лишнее устройство, измеряющее метрики качества! Да, это затраты. Но чем больше сторонних технологий будет поддерживаться, тем большим числом устройств, уже расположенных на сети, можно будет воспользоваться, как сопряжёнными агентами Q2. Вот он — наш идеал. Затраты разумны, а итог максимально полон. Более того, эти же агенты-инициаторы можно сделать ещё полезнее, о чём мы напишем ниже.

Сводим всё вышесказанное в два простых требования к реализации протоколов тестирования сетей TCP/IP с расчётом максимального числа метрик. Вначале требования к реализации для агента-инициатора:

Требование 7

Прикладное программное обеспечение, используемое для расчёта метрик качества на сети TCP/IP, установленное на агенте-инициаторе Q1, должно в обязательном порядке поддерживать один из эхо-протоколов (предпочтительно UDP, либо в крайней случае ICMP), а так же RFC-5357 (TWAMP) как минимум в варианте с управляющим соединением.

Прикладному программному обеспечению, используемому для расчёта метрик качества на сети TCP/IP, установленному на агенте-инициаторе Q1, крайне желательно поддерживать протоколы V1, V2 в целях использования уже установленных на сети устройств в качестве сопряжённых агентов.

Прикладному программному обеспечению, используемому для расчёта метрик качества на сети TCP/IP, установленному на агенте-инициаторе Q1, желательно поддерживать иные протоколы, имеющие расширенный набор метрик качества, даже если для этого требуется установка отдельных сопряжённых агентов Q2.

Теперь требования для сопряжённого:

Требование 8

Прикладное программное обеспечение, используемое для расчёта метрик качества на сети TCP/IP, установленное на сопряжённом агенте Q2, должно в обязательном порядке поддерживать либо ICMP-эхо, либо UDP-эхо.

Прикладному программному обеспечению, используемому для расчёта метрик качества на сети TCP/IP, установленному на сопряжённом агенте Q2, крайне желательно поддерживать протокол RFC-5357 (TWAMP) в целях расширенного сбора метрик качества.

Прикладному программному обеспечению, используемому для расчёта метрик качества на сети TCP/IP, установленному на сопряжённом агенте Q2, желательно поддерживать протоколы V1, V2 и иные в целях расширенного сбора метрик качества в случае необходимости.

На наш взгляд, всё вышесказанное следует переварить в спокойной обстановке.

Отодвинем профессию в сторону, прочь книжки, прочь сомнения. Скачем веселиться к князю Орловскому, там уже началось, слышите?

Эту чашу пью за дружбу нашу,

За огонь во взорах, за сердечный порох.

Эту чашу пью за встречу нашу

За веселье до утра!!!

cc: net-probe, lj, vk, telegram: 1,2, zen, AT

Далее...