Ранее...

Поэт писал, что дьяволу служить или пророку — каждый выбирает для себя. Выбор правильного протокола тестирования сродни подобному экзистенциальному выбору. Но прежде чем это делать, мы добавим наглядности в текст, ибо что-то давно у нас с вами не было приобщения к прекрасному, не так ли?

В разделе 1.8 мы привели несколько определений — OP, TP, TNP, TAP, которые теперь стоит проиллюстрировать. Кроме того, из раздела 2.1 известно, что такое агент-инициатор и сопряжённый агент (Q1 и Q2), и это тоже явно хочется изобразить наглядно. Потому что рисунки помогают нам понять, а из каких собственно модулей должны состоять агенты как в идеале, так и в реальности. Начнём с протокола типа OP.

Рисунок 20. Блок-схема агента-инициатора Q1 для протокола OP.

где

Модуль запуска по расписанию.

Модуль генератора теста по переданным параметрам.

Модуль подведения итогов и записи метрик.

Передача настроек теста от модуля запуска к генератору. При этом Ps , Ns — обязательные, а Bs , Cs — факультативные. Os определяется автоматически.

Управляющее соединение от Q1 до Q2.

Поток тестового трафика от Q1 до Q2.

Приём накопленных метрик от Q2 на Q1.

Теперь приведём блок-схему стороны приёма данных.

Рисунок 21. Блок-схема сопряжённого агента Q2 для протокола OP.

где

Модуль ожидания соединения.

Модуль приёма на Q2 трафика, создаваемого Q1

Передача полученных настроек и результатов расчётов от модуля к модулю.

Пора изложить подробности. Основным модулем агента-инициатора является, безусловно, модуль расписания. В нём хранится целый список информации, как о параметрах тестирования (P_s , N_s , B_s , C_s), так и служебные (например, T_freq). По мере наступления момента запуска очередного теста, этот модуль передаёт генератору трафика настройки, в которых могут быть как обязательные параметры, так и зависящие от конкретной реализации. На блок-схеме это специально выделено указанием либо выше стрелки передачи, либо ниже. Опытный читатель уже мог заметить, что модуль похож на известную программу cron, которую любой Unix-администратор знает очень хорошо.

Генератор устанавливает управляющее соединение от Q1 до Q2 тем или иным методом, тем самым сообщая модулю ожидания соединения на Q2 о своём желании начать тестирование. Модуль ожидания даёт команду приёмнику начинать приём, что тот и делает. Генератор создаёт тестовый трафик (бледно-жёлтая стрелка), который принимается приёмником, а данные расчёта метрик фиксируются в модуле подведения итогов.

После окончания тестирования (см. подробности в алгоритме 1) модуль подведения итогов Q2 передаёт модулю подведения итогов Q1 все накопленные метрики. Это может делаться как по управляющему соединению, так и иначе, в блок-схеме подробности реализации не важны. Так же пока не важно, как распорядится модуль записи метрик Q1 с полученной информацией. Мы, напоминаем, пока выбираем протоколы тестирования, и данные блок-схемы нужны для лучшего понимания уважаемыми читателями тех или иных наших выводов.

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

Односторонние протоколы — это хорошо и относительно просто, но в мире существуют и другие. Начнём с простого протокола TP (относительно сложный инициатор и относительно простой сопряжённый агент при дуплексном трафике).

Рисунок 22. Блок-схема агента-инициатора Q1 для протокола TP.

где

Передача настроек модулю приёма на Q1 трафика, создаваемого Q2

Поток тестового трафика от Q2 до Q1.

И не забудем, что сторона приёма данных тоже изменилась.

Рисунок 23. Блок-схема сопряжённого агента Q2 для протокола TP.

где

Передача настроек теста от модуля приёма к модулю генератора. При этом Ps — обязательный, а Ns , Cs — факультативные. Os определяется автоматически. Bs фактически не используется ввиду зависимости генератора (см. раздел 1.8).

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

А что изменилось в Q2? У него отобрали модуль расчётов и добавили модуль генератора. Это несколько изменило структуру программного обеспечения, которое реализует весь этот функционал, и, поскольку генератор в данном случае упрощён донельзя, в предельном случае он зависит только от размера пакета P_s , а сам вызов функции sendmsg(2) нельзя признать сложным, то можно сказать, что и весь функционал ПО Q2 стал проще для реализации. Более того, на рисунке 24 мы специально приводим пример «эхо»-реализации функционала Q2 в качестве иллюстрации простоты.

Рисунок 24. Блок-схема сопряжённого агента Q2 для протокола TP типа «эхо».

Видите, как всё просто? Приняли пакет и ответили обратно в адрес отправителя, возможно, внеся некоторые небольшие изменения в пакет данных. Эта простота позволяет либо вынести реализацию Q2 на уровень стандартного модуля ОС, либо на уровень ядра ОС, либо вообще реализовать в микросхемах. Удобно? Ещё бы! Не мы первые кто это заметил, поэтому подробности желающие могут поискать в RFC-792. Умный читатель уже понял, что тем самым мы намекаем о вездесущем ICMP-эхе. Ну к UDP-эху сказанное тоже относится, конечно же.

А теперь о том, кто же работает по подобной схеме для замеров качественных метрик. По рисункам 22 и 24 работают: ping, bwping, RFC-2544 (именно! читаем внимательно!), и вендор №2, более известный как V2. Естественно, для ping, bwping модуль расписания обычно вновь вынесен на руки администратора, впрочем, могут быть и решения от систем мониторинга, которые иногда в пределе простоты ограничиваются простым запуском через cron. А по рисункам 22 и 23 работают: RFC-5357 (TWAMP) и популярный вендор №1, более известный в народе как V1. Что же касается Y.1540, то опустим занавес стыда перед этим стандартом, поскольку определив кучу метрик, аналогично I.353, авторы так и сподобились создать хоть что-то, минимально похожее на протокол тестирования. Поневоле вспомнишь бессмертную цитату про съеденные деньги на заготовке рогов и копыт посреди упоительной жизни.

Внимательный читатель, наслаждающийся нашей книгой с карандашом в руках, а не только ради литературных отступлений от тяжёлой доли связиста, уже заметил, что неторопливо, но неуклонно мы перечислили все протоколы, упомянутые в прошлом разделе, и уже кричит: «А протоколы TNP и TAP откуда возьмутся? Они вообще реализованы?»

Давайте вначале помечтаем. В любом техническом задании, которое пишет оператор связи для того, чтобы либо внутренний отдел, либо сторонний подрядчик создал нечто, что оператору нужно, обычно требования, мягко говоря, завышены. Иногда, на всякий случай, чтобы вытрясти из подрядчика лишнее и при этом минимально потратиться, туда вписывается даже фаза Луны и солнечные затмения. Вот для такого случая нами и придуман специальный термин — Ideal Quality Measurer или сокращённо IQM. Для тех кто привык к русской терминологии, мы тоже постарались и назвали его ИАИ (Идеальный Агент Измерений). Есть ли он в реальности, вопрос не столь важный, ведь "You have to have a dream so you can get up in the morning". Без этого шесть «Оскаров» так и останутся мечтой.

Итак, идеальная схема устройства Q1.

Рисунок 25. Блок-схема агента-инициатора Q1 для протокола TNP.

где

Передача настроек теста от модуля запуска к генератору. При этом Ps , Ns , Bs — обязательные, Cs — факультативный. Os определяется автоматически.

Передача настроек модулю приёма на Q1 трафика, создаваемого Q2. При этом Ps , Ns — обязательные, Cs — факультативный.

Разница между рисунком 25 и рисунком 22 кажется минимальной. Однако она есть. ping, UDP-эхо и V2 такому требованию уже не удовлетворяют, ведь в их настройках не указывается скорость генерации теста. Плюс приёмник теперь всегда точно знает сколько пакетов надо принять, это немного облегчает алгоритм приёма.

Теперь создаём идеальную схему для Q2.

Рисунок 26. Блок-схема сопряжённого агента Q2 для протокола TNP.

Новых обозначений мы здесь не ввели, просто организовали все модули ПО таким образом, чтобы выжать максимум информации во время расчётов. Так, теперь по сравнению с прежними схемами работы Q2, скорость B_s и число пакетов N_s являются для сопряжённого агента обязательными параметрами. Это позволяет создавать два встречных потока трафика (бледно-жёлтая и розовая стрелки), что позволяет полностью эмулировать действия пользователя сети путём применения разных параметров, как это рекомендуется в разделе 2.5.

Осталось определиться с протоколом TAP. Он ничем особенным не отличается от TNP, кроме асимметричности скоростей генерации теста B_s и B_r . Это полезно в основном для нагрузочного тестирования, когда у пользователей явно однонаправленный характер запросов, однако и измерения качественных характеристик могут быть полезны при применении неравномерной нагрузки.

Рисунок 27. Блок-схема агента-инициатора Q1 для протокола TAP.

где

Передача настроек теста от модуля запуска к генератору. При этом Ps , Ns , Bs , Br — обязательные, Cs — факультативный. Os определяется автоматически.

В отличие от рисунка 25, в нашем случае видно, что обе скорости передаются в генератор. Однако B_s он использует в личных корыстных целях, а B_r передаёт дальше на сопряжённый агент Q2 по управляющему соединению.

А сама сторона Q2 теперь выглядит так:

Рисунок 28. Блок-схема сопряжённого агента Q2 для протокола TAP.

где

Передача настроек теста от модуля ожидания к генератору. При этом Ps , Ns , Br — обязательные, Cs — факультативный. Os определяется автоматически.

Изменения по сравнению с рисунком 26 минимальны. Из управляющего соединения берётся вместо B_s скорость B_r , а всё остальное реализовано так же, как и раньше. Не боясь критики, мы смело заявляем, что на рисунках 27-28 приведены блок-схемы идеального агента для сбора статистических метрик качества сети TCP/IP. Более того, схема на рисунке 27 может применяться как идеальный агент-инициатор для любого типа протокола (OP, TP, TNP, TAP).

Допустим, агент-инициатор Q1 собран по схеме 27. А сопряжённый ему Q2 по схеме 21. Будет ли работать подобное? При условии, естественно, что протоколы сопряжения совместимы, отсутствие входящего тестового трафика позволит приёмнику Q1 завершить работу заранее, а модуль подведения итогов на Q1 запишет только односторонние данные, полученные от Q2, чего мы и добиваемся в итоге.

Далее, пусть Q2 собран по схеме 23. Приёмник на Q1 примет все данные, которые отослал генератор Q1 и завернул генератор Q2, опять-таки при условии совместимости протоколов. Таким образом, мы получим все нужные метрики, так как B_r фактически игнорируется стороной Q2.

То же самое происходит и со схемой 24, это вы можете показать самостоятельно.

А в случае, когда применяется схема 26, нам достаточно по управляющему соединению правильно передать на Q2 скорость B_r равную B_s , и поведение будет полностью соответствовать ожидаемому.

Итак, идеальный агент-инициатор представлен на рисунке 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.

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

Требование 8.

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

Эту чашу пью за дружбу нашу,
За огонь во взорах, за сердечный порох.
Эту чашу пью за встречу нашу
За веселье до утра!!!

cc: lj: 1,2, telegraph: 1,2, vk: 1,2, telegram: 1,2, zen, AT, MMM

Далее...