Основы тестирования сетей TCP/IP для служб эксплуатации №2.7
CAEВыбор протокола
Поэт писал, что дьяволу служить или пророку — каждый выбирает для себя. Выбор правильного протокола тестирования сродни подобному экзистенциальному выбору. Но прежде чем это делать, мы добавим наглядности в текст, ибо что-то давно у нас с вами не было приобщения к прекрасному, не так ли?
В разделе 1.8 мы привели несколько определений — OP, TP, TNP, TAP, которые теперь стоит проиллюстрировать. Кроме того, из раздела 2.1 известно, что такое агент-инициатор и сопряжённый агент (Q1 и Q2), и это тоже явно хочется изобразить наглядно. Потому что рисунки помогают нам понять, а из каких собственно модулей должны состоять агенты как в идеале, так и в реальности. Начнём с протокола типа OP.
Рисунок 20
где
Теперь приведём блок-схему стороны приёма данных.
Рисунок 21
где
Пора изложить подробности. Основным модулем агента-инициатора является, безусловно, модуль расписания. В нём хранится целый список информации, как о параметрах тестирования (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
где
И не забудем, что сторона приёма данных тоже изменилась.
Рисунок 23
где
Что нового в Q1 протокола TP по сравнению с протоколом OP? Во-первых добавился приёмник, теперь тестовый трафик одновременно и принимается, и получается. Во-вторых модуль подведения итогов сразу получает информацию от приёмника, и ему не нужно дополнительно после сессии проводить излишнюю работу. В-третьих, модуль подведения итогов может рассчитывать не только однонаправленные, но и двунаправленные, да и круговые метрики.
А что изменилось в Q2? У него отобрали модуль расчётов и добавили модуль генератора. Это несколько изменило структуру программного обеспечения, которое реализует весь этот функционал, и, поскольку генератор в данном случае упрощён донельзя, в предельном случае он зависит только от размера пакета P[s] , а сам вызов функции sendmsg(2) нельзя признать сложным, то можно сказать, что и весь функционал ПО Q2 стал проще для реализации. Более того, на рисунке 24 мы специально приводим пример «эхо»-реализации функционала Q2 в качестве иллюстрации простоты.
Рисунок 24
Видите, как всё просто? Приняли пакет и ответили обратно в адрес отправителя, возможно, внеся некоторые небольшие изменения в пакет данных. Эта простота позволяет либо вынести реализацию 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
где
Разница между рисунком 25 и рисунком 22 кажется минимальной. Однако она есть. ping, UDP-эхо и V2 такому требованию уже не удовлетворяют, ведь в их настройках не указывается скорость генерации теста. Плюс приёмник теперь всегда точно знает сколько пакетов надо принять, это немного облегчает алгоритм приёма.
Теперь создаём идеальную схему для Q2.
Рисунок 26
Новых обозначений мы здесь не ввели, просто организовали все модули ПО таким образом, чтобы выжать максимум информации во время расчётов. Так, теперь по сравнению с прежними схемами работы Q2, скорость B[s] и число пакетов N[s] являются для сопряжённого агента обязательными параметрами. Это позволяет создавать два встречных потока трафика (бледно-жёлтая и розовая стрелки), что позволяет полностью эмулировать действия пользователя сети путём применения разных параметров, как это рекомендуется в разделе 2.5.
Осталось определиться с протоколом TAP. Он ничем особенным не отличается от TNP, кроме асимметричности скоростей генерации теста B[s] и B[r] . Это полезно в основном для нагрузочного тестирования, когда у пользователей явно однонаправленный характер запросов, однако и измерения качественных характеристик могут быть полезны при применении неравномерной нагрузки.
Рисунок 27
где
В отличие от рисунка 25, в нашем случае видно, что обе скорости передаются в генератор. Однако B[s] он использует в личных корыстных целях, а B[r] передаёт дальше на сопряжённый агент Q2 по управляющему соединению.
А сама сторона Q2 теперь выглядит так:
Рисунок 28
где
Изменения по сравнению с рисунком 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] , и поведение будет полностью соответствовать ожидаемому.