Наблюдать, не вмешиваясь: неинтрузивный мониторинг SRT изнутри

Что такое неинтрузивный мониторинг

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

Зонд не устанавливает отдельную сессию до источника и не создаёт промежуточных соединений, в отличие от решений на базе relay или proxy.

Тем не менее преимущества этого подхода перевешивают указанные недостатки и хорошо соответствуют ожиданиям пользователей.

Что такое зонд?

Boro зонд — это программное обеспечение, предназначенное для работы на x86-совместимых машинах под управлением Windows или Linux. Как правило, он разворачивается на отдельном сервере и устанавливается в качестве сервиса. Сервер оснащается требуемым количеством сетевых адаптеров с необходимым максимальным битрейтом, через которые зонд получает потоки.

Приложение также можно устанавливать непосредственно на кодерах, передатчиках, приёмниках и другом оборудовании при условии, что оно работает на платформах x86 под управлением Windows или Linux.

Зонд Boro принимает поток и собирает детальные метаданные о параметрах QoS и QoE. Статистика — не сами потоки — передаётся на сервер Boro, который обычно разворачивается на отдельной машине. Сервер обеспечивает управление зондами, визуализацию данных в виде графиков и таблиц, а также настройку триггеров и оповещений.

Способы доступа к данным при неинтрузивном мониторинге

Неинтрузивный мониторинг может быть реализован несколькими способами. Все эти подходы объединяет общий принцип: они не создают отдельную сессию. В идеале мониторинг не должен прерывать уже установленные сессии.

Network TAP (Test Access Point)

Network TAP — это аппаратное устройство, которое встраивается в сетевой кабель для пассивного копирования всего трафика в обоих направлениях. Оно позволяет осуществлять мониторинг, анализ безопасности или диагностику без нарушения работы основного потока данных. В отличие от SPAN-портов TAP-устройства работают как идеальные зеркала сетевого трафика и не теряют пакеты.

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

Зеркалирование портов (SPAN)

Зеркалирование портов, также известное как SPAN (Switched Port Analyzer), — это функция мониторинга сетевого трафика, которая копирует пакеты с одного или нескольких исходных портов на порт назначения. Устройство мониторинга, подключённое к этому порту, может анализировать трафик без нарушения работы сети.

Практически все современные коммутаторы поддерживают эту функцию. Основное преимущество состоит в том, что дополнительное оборудование не требуется, так как коммутатор обычно уже присутствует в сети.

Однако потеря пакетов на зеркалируемом порту остаётся потенциальной проблемой. Это может происходить по двум причинам:

1. Зеркалируемый порт имеет более низкий приоритет по сравнению с другими портами и при высокой нагрузке будет первым терять пакеты.
2. Зеркалирование может направлять на порт назначения объёмы трафика, превышающие его пропускную способность.

Установка непосредственно на источник или приёмник

Если источник или приёмник представляет собой программное обеспечение, работающее на x86-совместимой системе под управлением Windows или Linux, зонд может быть установлен непосредственно на этой машине. В такой конфигурации сетевая подсистема компьютера фактически выполняет функцию Network TAP, что исключает необходимость в дополнительном оборудовании.

В какой точке отбирать SRT-сигнал?

Первые два метода организуют мониторинг в промежуточных точках, а последний — в конечных. При мониторинге мультикаста зонд обычно подключается к ближайшему коммутатору на потенциальном месте приемников, где логично измерять качество доставки сигнала (QoS). Однако при мониторинге протокола с перезапросом возможна установка зонда и на стороне источника сигнала, и в промежуточной точке, так как зонд может захватывать пакеты с командами повторения отправки.

В таком случае необходимо логировать два набора данных: текущая картина в точке измерения и с учетом перезапроса со стороны приемника.

Приложению Boro-зонда не важно, каким способом сигнал отводится на мониторинг. Ниже в качестве примера рассмотрим получение данных через зеркалирование трафика.

Особенности работы зонда при захвате данных через SPAN

На схеме ниже мониторинг осуществляется в промежуточной точке ближе к приёмнику. К коммутатору, к которому подключён SRT-приёмник, также подключается машина с зондом.

Рис. 1. Схема мониторинга SRT-сессии путем зеркалирования трафика.

Коммутационное оборудование должно поддерживать технологию Port Mirroring (SPAN). Данное решение позволяет дублировать весь трафик, поступающий на порт, к которому подключен приемник SRT сигнала, на порт, к которому подключен зонд. При настройке зеркалирования необходимо указать, что копируется как входящий, так и исходящий трафик, так как SRT-протокол двунаправленный.

Если зонд, как в нашем случае, запущен на отдельном сервере, он не может принимать дублированный трафик обычным способом. Зеркалированные пакеты адресованы другим получателям и не могут быть приняты через обычные сокеты (стандартный API для сетевого взаимодействия). Обычно такие пакеты будут отброшены фильтрами сетевой карты или сетевой подсистемой ОС.

Поэтому зонд при работе с захватом трафика должен переводить сетевую карту в неразборчивый режим (promiscuous mode). В этом режиме карта принимает весь трафик, приходящий на порт, а не только тот, что предназначен конкретно этой машине. Дополнительно зонд использует библиотеку захвата пакетов PCAP (Packet Capture API) — она позволяет перехватить трафик до того, как он пройдёт через сетевые фильтры операционной системы. При этом у PCAP есть собственный набор фильтров, с помощью которых можно выделить нужную SRT-сессию и передать её на дальнейший анализ.

Запуск задач мониторинга на зонде

Мониторинг через захват пакетов — процесс нетривиальный, поэтому система запуска задач в зонде сделана достаточно гибко.

Пользователь может указать полный набор параметров захвата: srcIP:port + dstIP:port (4-tuple), а может — только часть: srcIP:port или dstIP:port. Порт указывается обязательно. Дополнительно задаётся тип протокола захватываемого потока — в нашем случае это SRT.

В текущей реализации мы тестировали работу с соединениями в режимах Caller–Listener. Это означает, что как минимум один IP-адрес всегда известен. Ещё один важный момент: одна сессия всегда работает в рамках одного соединения с неизменным 4-tuple. Рукопожатие, передача команд, перезапрос пакетов, полезные данные — всё идёт через одно соединение.

Приведем пару примеров для наглядности.

Мониторинг SRT

Протокол SRT оказался довольно удобным для сниффинга в Boro:

1. используется небольшое число понятных команд;
2. шифрование затрагивает только пакеты с данными;
3. при получении сессионных ключей не используются алгоритмы perfect forward secrecy;
4. работа ведётся в рамках одного порта;
5. данные передаются в формате MPEG-TS.

После захвата в задачу мониторинга попадают пакеты, относящиеся только к конкретной сессии. Их нужно разобрать согласно SRT-спецификации. Как и SRT-приёмник, зонд организует буфер, в котором накапливаются принятые пакеты. Если анализатор видит перезапрошенный пакет, он логирует это действие. Перезапрошенные пакеты помещаются в буфер, если нужная позиция ещё не была из него вытеснена. Так формируется восстановленный поток данных.

Дальше полученный транспортный поток направляется на классический анализ — как если бы это был обычный мультикаст: измеряется IAT, проверяется целостность потока, параметры TR 101 290 и так далее, вплоть до проверки QoE. Помимо этого, зонд логирует набор метрик, идентичный стандартному способу мониторинга SRT, включая Estimated Bandwidth и RTT (на основе захвата ACK-пакетов).

Пока мы описали процесс мониторинга в общих чертах, дальше остановимся на наиболее значимых деталях.

Как понять, что отфильтрованный поток — это SRT?

Даже если SRT-поток зашифрован, заголовки пакетов остаются открытыми. Этим зонд и пользуется. Сначала он ищет предполагаемый SRT-заголовок и проверяет поле Socket ID — его значение должно повторяться от пакета к пакету. Затем зонд изучает поля со счётчиками, которые должны возрастать. Если оба условия выполняются, можно с высокой вероятностью утверждать, что пакеты принадлежат SRT-протоколу.

Шифрованный SRT

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

Почему это важно? В режиме Caller–Listener именно Caller инициирует сессию, отправляя Handshake control packets для обмена конфигурациями и согласования параметров соединения. Если выбран режим с шифрованием, эти пакеты будут содержать Key Material Message — информацию, необходимую для кодирования и декодирования потока. Перехватив пакеты рукопожатия, зонд получает полный набор данных для декодирования потока: ключи, векторы и пароль.

Периодически пиры выполняют ротацию ключей. Зонд захватывает новые ключи и применяет их в нужный момент.

Если задача захвата запущена для уже установленной сессии, зонд не сможет получить ключи. В этом случае мониторинг покажет только битрейт входящего потока, без детализации. Такая ситуация продлится до момента обновления Key Material, которое обычно производится редко.

Шифрование — один из ограничивающих факторов для неинтрузивного мониторинга. Но, как видно, это препятствие вполне преодолимо. Главное — соблюдать последовательность запуска процессов.

Проблема мультиплексированных потоков

SRT-протокол поддерживает мультиплексированные потоки: несколько SRT-сокетов могут использовать один и тот же UDP-сокет. Пакеты, приходящие на этот UDP-сокет, корректно распределяются по целевым SRT-сокетам. Во время рукопожатия стороны обмениваются своими SRT Socket ID, которые затем указываются в поле Destination SRT Socket ID каждого пакета.

Допустим, в сессии передаётся мультиплекс из двух потоков. Зонд будет захватывать пакеты с четырьмя идентификаторами: два для данных, два для команд.

Без захвата Handshake control packets невозможно определить, какому потоку принадлежит тот или иной идентификатор. Та же проблема касается измерений RTT и Estimated Bandwidth — зонд отслеживает измерительные пакеты, которые тоже содержат Socket ID.

Как и с шифрованием, мониторинг мультиплексированных потоков требует соблюдения последовательности процессов: сначала необходимо запустить задачу мониторинга, а затем организовать SRT сессию.

Размер буфера

Размер буфера — ключевая метрика при анализе SRT путём сниффинга. Критически важно, чтобы он совпадал со значением, о котором договорились приёмник и передатчик. Только тогда картина восстановления пакетов в задаче мониторинга будет идентична тому, что происходит на приёмнике.

На этапе переговоров пиры выбирают наибольший из двух размер буфера и передают его в Handshake control packets. Зонд будет использовать именно это значение. Но на случай, если перехватить Handshake control не удается, в форме добавления задачи есть поле «Размер буфера» — пользователь заполняет его вручную перед запуском.

Параметры мониторинга

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

Производительность

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

Задача PCAP-процесса — только отобрать пакеты, принадлежащие определенной сессии. Дальнейшая обработка передаётся другим процессам. На данном этапе можно сказать, что анализ путем сниффинга будет сопоставим по производительности с классическим анализом SRT. Наибольшую нагрузку всегда создаёт декодирование видео и углублённый анализ QoE, который в разы и десятки раз более трудоемок, чем прием данных. Декодирование видео в любых подходах мониторинга идентично.

Автор: Антон Прошутя — менеджер продукта Elecard Boro. Работает в сфере контроля качества видео с 2007 года.

Elecard Boro — многофункциональное программное решение для контроля качества потокового вещания в UDP, RTP, HTTP, HLS, DASH, SRT и RTMP и отслеживания QoS и QoE параметров в распределенной сети с централизованным доступом к статистике и генерацией регулярных отчетов