Применение технологии eBPF для мониторинга сетевого трафика в реальном времени

Иван Печерский, Виктор Чертов

Введение

Протокол Secure Reliable Transport (далее SRT) используется для потоковой передачи видео и аудио в режиме реального времени [1]. Согласно отчёту компании-разработчика протокола Haivision за 2026 год, SRT пятый год подряд остаётся ведущим протоколом доставки видеоконтента (рис. 1).

Рис. 1. Результат опроса «Какой транспортный протокол для видео вы используете в настоящий момент?» (из отчёта компании Haivision)

Поскольку эта технология использует в качестве транспортного механизма протокол UDP, применение SRT в рабочих средах со сложной сетевой инфраструктурой сопровождается дополнительными трудностями, связанными с отслеживанием состояний соединений между источниками на стороне поставщика видеоконтента и клиентами.

На ранних этапах развития Интернета протокол UDP [2] использовался для обмена запросами и ответами без учёта состояния, например, с помощью таких протоколов, как DNS или NTP. Перезапуск обслуживающего серверного процесса в этом контексте не являлся проблемой, поскольку ему не нужно сохранять состояние при обслуживании нескольких запросов. Однако современные протоколы, в том числе SRT, используют соединения с отслеживанием состояния. В этом контексте удаление старых соединений при перезагрузке серверного приложения напрямую влияет на доступность сервиса и качество обслуживания конечного клиента, из-за чего в некоторых компаниях применяются собственные решения, обеспечивающие плавное и неразрывное применение изменений в конфигурацию серверного процесса [3].

В представленной работе рассматривается сценарий, в котором проблема «изящной» перезагрузки (от англ. graceful reload) решена внутренней разработкой компании, но в ней отсутствуют средства мониторинга и анализа SRT-трафика, поэтому нет информации о состоянии соединений, такой как задержки, потери или повторные передачи пакетов. При таком раскладе известные инструменты мониторинга сети оказываются недостаточно удобными. Ручная отладка проблем SRT-соединений с помощью сетевых анализаторов, таких как Wireshark с SRT-диссектором, и изучение разрозненных логов значительно снижают скорость реагирования на инциденты [4]. Поэтому целью проведённого исследования являлась разработка прототипа решения для мониторинга SRT-соединений в режиме реального времени.

Extended Berkeley Packet Filter

Для решения проблем, возникающих при использовании UDP-сервисов, создаются очень интересные решения. Например, компания Cloudflare разработала механизм udpgrm для плавного перезапуска сервисов (преимущественно ориентированных на работу с протоколом QUIC, также использующим UDP), который использует специальные параметры сокетов и eBPF-программу, сохраняющую привязку пакетов к конкретному рабочему процессу, чтобы при обновлении конфигурации сервера продолжать обслуживать существующие потоки без потерь [5]. Это позволяет решить задачу сохранения состояния соединений при перезапусках, однако вопрос мониторинга качества соединений остаётся открытым. Тем не менее, udpgrm демонстрирует высокий потенциал технологии eBPF в обработке UDP-трафика.

eBPF – это технология безопасной загрузки и выполнения кода внутри ядра Linux [6]. В контексте проведённого исследования eBPF привлекателен тем, что позволяет отфильтровывать и анализировать SRT-пакеты непосредственно при прохождении через сетевой стек, без необходимости нести затраты на переключение между ядром и пользовательским пространством для обработки каждого пакета, обеспечивая тем самым высокую производительность в обработке данных, а возможность динамической загрузки программ eBPF в ядро даёт существенное преимущество по сравнению с обновлением кодовой базы ядра и последующей перезагрузкой сервера. Наличие встроенного верификатора значительно снижает риск сбоя в работе ядра, который может вызвать загружаемая программа [7].

Подсистема XDP – это высокопроизводительный пакетный процессор, интегрированный в ядро Linux, который выполняет программы BPF, когда драйвер сетевой карты получает пакет [8]. XDP-программы выполняются на самом раннем этапе приёма пакетов (на уровне драйвера сетевой карты), позволяя обрабатывать миллионы пакетов в секунду с минимальными задержками [9].

По этой причине сочетание eBPF/XDP было выбрано как основа для непрерывного мониторинга SRT-трафика в режиме реального времени. Такой подход сочетает в себе отсутствие необходимости вмешательства в код приложений и работу сервера с высокой производительностью и безопасностью исполнения программ в ядре.

Архитектура решения

Разработанный прототип системы мониторинга SRT-соединений функционирует как в пространстве ядра, так и в пространстве пользователя (рис. 2).

Рис. 2. Взаимодействие компонентов разработанного прототипа.

Компоненты пространства ядра взаимодействуют с компонентами пространства пользователя через BPF-карты – разделяемые структуры данных, представляющие собой хранилища ключей и их значений, размещённые в ядре и доступные обеим сторонам. В разработанной системе используется четыре вида таких карт [10–12].

В пространстве ядра функционирует сама eBPF-программа. После загрузки в ядро она прикрепляется к двум сетевым точкам перехвата, описанным далее.

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

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

Перехват и идентификация SRT-пакетов

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

Вторая точка обеспечивает перехват исходящего трафика посредством подсистемы управления трафиком (TC). Мониторинг исходящего трафика является необязательным: он активируется соответствующим параметром в конфигурации или аргументом командной строки при запуске демона. На обеих точках перехвата вызывается одна и та же процедура разбора пакета, различается лишь направление передачи.

Сначала программа обрабатывает Ethernet-заголовок и определяет тип вышестоящего протокола, используя поле EtherType (рис. 3). Если кадр содержит метку виртуальной локальной сети (VLAN-тег) стандарта IEEE 802.1Q, то он снимается путём увеличения смещения разбора на четыре байта [13]. Поскольку на практике нередко применяется двойное тегирование (стандарт 802.1AD, известный также как QinQ), программа способна последовательно снять обе метки: сначала внешний тег провайдера, затем внутренний тег клиента [14].

Далее программа разбирает IPv4- или IPv6-заголовок. Для пакетов IPv4 из заголовка извлекаются адреса источника и назначения, поле протокола верхнего уровня, а также длина заголовка, необходимая для определения начала полезной нагрузки пакета. Для пакетов IPv6 также извлекаются адреса, но принадлежность к транспортному протоколу UDP устанавливается по полю «следующий заголовок» [15].

Рис. 3. Порядок разбора полученного фрейма данных.

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

Наконец выполняется идентификация пакета как принадлежащего протоколу SRT. Поскольку SRT не имеет зарезервированного номера порта, идентификация производится по структуре внутреннего заголовка, минимальный размер которого составляет 16 байт. Тип пакета определяется по старшему биту первого слова заголовка: единица означает управляющий пакет, а ноль — пакет данных. Данное разграничение закреплено в спецификации протокола SRT (рис. 4) [16].

Рис. 4. Структура SRT-пакета.

Из управляющих пакетов извлекается их контрольный тип. Система распознаёт следующие типы для наблюдения за жизненным циклом соединения: установление соединения (HANDSHAKE), поддержание активности (KEEPALIVE), подтверждение получения (ACK), уведомление о потере (NAK), завершение соединения (SHUTDOWN) и подтверждение подтверждения (ACKACK). Для пакетов данных анализируются два признака: биты поля шифрования (KK), указывающие на применение шифрования к данному пакету, а также бит повторной передачи пакета (R).

Для объединения встречных направлений потока пакетов, идущих от узла А к узлу Б, и пакетов, идущих от Б к А, в единую запись карты сессий применяется процедура сортировки кортежа из четырёх компонентов, образованного адресами и портами обеих сторон. Ключ сессии хранит два поля адресов, признак версии протокола IP и два поля портов. Упорядочивание выполняется путём лексикографического побайтового сравнения двух адресов. Адрес, лексикографически меньший, всегда помещается в первое поле ключа и обозначает первое направление потока, а адрес, лексикографически больший, во второе поле. При равенстве адресов, что возможно, например, при работе через интерфейс обратной петли (loopback), для окончательного упорядочивания сравниваются номера UDP-портов. Благодаря такому подходу пакеты обоих направлений одного соединения всегда порождают одинаковый ключ, и их статистика консолидируется в единой записи карты сессий.

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

Для каждой активной сессии обновляются счётчики пакетов и байт, а также показатели качества соединения. Основным источником данных о состоянии канала служат управляющие пакеты типа ACK. Принимающая сторона отправляет их передающей, дополнительно сообщая внутри них свои измерения параметров соединения. Первым является двусторонняя задержка (RTT) в микросекундах – оценка, вычисленная принимающей стороной, как время между отправкой ACK-пакета и приемом ACKACK-пакета (рис. 5).

Рис. 5. Оценка RTT в протоколе SRT.

Следом идёт вариация этой задержки, или джиттер, измеряемый также в микросекундах. Далее находится значение доступного объёма буфера приёмника в пакетах. Затем идёт значение скорости приёма в пакетах в секунду. Наконец, последним из извлекаемых полей является оценочная пропускная способность канала, тоже в пакетах в секунду. Все эти значения являются последними из наблюдаемых и при каждом поступлении ACK-пакета перезаписываются.

Помимо вышеперечисленных показателей, обновляются счётчик пакетов типа HANDSHAKE, счётчики пакетов ACK и NAK, счётчик пакетов данных, счётчик управляющих пакетов, счётчик повторно переданных пакетов данных, счётчик пакетов данных с признаком шифрования, а также идентификатор SRT-сокета.

Конфигурация и демон

Конфигурация системы описывается в YAML-файле (рис. 6). При отсутствии этого файла программа запускается с предопределёнными по умолчанию значениями.

Рис. 6. Пример содержимого конфигурации.

Конфигурация включает несколько групп параметров. Параметры привязки к сетевому интерфейсу определяют, на каком интерфейсе вести наблюдение, нужен ли мониторинг исходящего трафика и путь до Unix-сокета. Пороговые значения задают критерии оценки состояния сессий: допустимую долю повторных передач, порог RTT, порог неактивности сессии и минимальное число пакетов для активации проверок. Параметр мониторинга определяет частоту опроса BPF-карты сессий. Параметры экспорта метрик включают флаг активации и адрес HTTP-сервера. Параметры BPF задают максимальное число отслеживаемых сессий и фильтр UDP-порта. Фильтр сессий позволяет отображать только сессии, удовлетворяющие заданным условиям, подробнее о нём рассказано далее. Параметры отображения управляют обратным разрешением DNS и временем жизни кеша DNS-имён. Уровень журналирования задаётся как строка, принимающая значение уровня отладки, информации, предупреждения или ошибок.

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

1. IP-адрес любой из сторон соединения.
2. Блок IP-адресов в CIDR-нотации любой из сторон соединения.
3. Порт любой из сторон соединения.

Предусмотрены также строгие критерии: отдельно по IP-адресу источника или получателя и отдельно по порту источника или получателя. Также имеется специальный критерий, который ограничивает вывод только сессиями, у которых зафиксировано превышение хотя бы одного из настроенных пороговых значений.

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

Следующим действием является запись идентификатора процесса в специальный файл. Если он существует и содержит идентификатор активного процесса, тогда осуществляется проверка существования такого процесса и, если она оказывается удачной, запуск прерывается, предотвращая одновременную работу двух экземпляров демона. Устаревший же файл перезаписывается. При нормальном завершении демона этот файл удаляется.
После успешной инициализации демон загружает конфигурацию из YAML-файла, при необходимости переопределяя отдельные её параметры значениями из командной строки. Затем в ядро загружается eBPF-программа и запускается фоновый мониторинг сессий. Подсистема мониторинга непрерывно читает события из кольцевого буфера. При получении события о появлении или завершении сессии регистрируется соответствующее информационное сообщение. Одновременно периодически опрашивается BPF-карта сессий с заданным интервалом. При каждой итерации опроса выполняется полное считывание текущего состояния BPF-карты сессий. Для каждой обнаруженной сессии проверяется её время последней активности, и если с момента последнего принятого пакета прошло больше времени, чем заданный порог неактивности, запись признаётся устаревшей и удаляется. Для каждой активной сессии выполняется проверка «здоровья» путём сравнения текущих показателей с пороговыми. Проверка активируется только после накопления в данном направлении пакетов более установленного минимума, чтобы предотвратить ложные срабатывания на начальном этапе соединения, когда имеющихся данных ещё недостаточно для достоверного вывода.

Дополнительно при каждом опросе сравнивается текущее значение счётчика рукопожатий с сохранённым значением из предыдущего опроса. Если счётчик вырос и предыдущее значение было ненулевым, значит в рамках уже существующей сессии произошло повторное рукопожатие, что свидетельствует о переподключении клиента. Это событие тоже регистрируется в журнале.

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

Затем запускается сервер межпроцессного взаимодействия. Он принимает подключения через доменный сокет UNIX [17]. Одновременное число активных соединений ограничено шестнадцатью — и при исчерпании лимита новые соединения отклоняются без обработки. При создании сокета производится определение идентификатора группы. Если группа уже существует в системе, сокет передаётся во владение этой группе с правами доступа, разрешающими чтение и запись владельцу и членам группы. При отсутствии группы права сужаются до доступа исключительно для привилегированного пользователя. Авторизация подключения выполняется через специальный параметр сокета. При получении нового соединения через системный вызов запрашиваются реальные идентификаторы пользователя и группы подключающегося процесса. Соединение авторизуется, если идентификатор пользователя равен нулю или идентификатор группы совпадает с идентификатором группы приложения.

Демон поддерживает пять команд взаимодействия с ним:

запрос текущей статистики — возвращает массив описаний активных сессий с применением фильтрации, либо разовой из запроса, либо постоянной из конфигурации;

запрос на установку фильтра — сохраняет параметры отбора сессий для применения ко всем последующим запросам статистики;

запрос на смену уровня журналирования — позволяет переключить детализацию журнала демона;

запрос конфигурации — возвращает полную текущую конфигурацию демона в формате JSON;

запрос на перезагрузку конфигурации — инициирует повторное считывание YAML-файла и применение новых параметров.

Завершающим этапом инициализации является регистрация обработчиков сигналов операционной системы. Сигнал SIGHUP обрабатывается как команда перезагрузки конфигурации, при получении которой повторно считывается YAML-файл. Сигналы SIGTERM и SIGINT инициируют завершение работы.

Интерфейс командной строки и отображение данных

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

В режиме наблюдения клиент периодически повторяет запрос с заданным интервалом, предварительно очищая экран перед каждым обновлением. При включённом обратном разрешении DNS выполняется разрешение всех IP-адресов текущего снимка и рядом с IP-адресом в скобках выводится доменное имя, если оно доступно в кеше (рис. 7).

Рис. 7. Пример отображаемых данных об имеющихся SRT-сессиях.

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

Заключение

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

Список литературы:

[1] Haivision/srt: Secure, Reliable, Transport [Электронный ресурс]. URL: https://github.com/haivision/srt (дата обращения: 19.03.2026).
[2] RFC 768 — User Datagram Protocol [Электронный ресурс]. URL: https://datatracker.ietf.org/doc/html/rfc768 (дата обращения: 19.03.2026).
[3] Everything you ever wanted to know about UDP sockets but were afraid to ask, part 1 [Электронный ресурс]. URL: https://blog.cloudflare.com/everything-you-ever-wanted-to-know-about-udp-sockets-but-were-afraid-to-ask-part-1/ (дата обращения: 19.03.2026).
[4] Wireshark. Go Deep | Display Filter Reference: SRT Protocol [Электронный ресурс]. URL: https://www.wireshark.org/docs/dfref/s/srt.html (дата обращения: 19.03.2026).
[5] QUIC restarts, slow problems: udpgrm to the rescue [Электронный ресурс]. URL: https://blog.cloudflare.com/quic-restarts-slow-problems-udpgrm-to-the-rescue/ (дата обращения: 19.03.2026).
[6] Райс. Л. Изучаем eBPF: Пер. с англ. – Астана: Алист, 2024. – 224с. ISBN 978-601-08-4118-5
[7] [2410.00026] The eBPF Runtime in the Linux Kernel [Электронный ресурс]. URL: https://arxiv.org/abs/2410.00026 (дата обращения: 19.03.2026).
[8] Calavera David, Fontana Lorenzo, Frazelle Jessie. Linux observability with BPF : advanced programming for performance analysis and networking. O’Reilly Media, Inc., 2020. P. 162.
[9] Hoiland-Jorgensen T. et al. The eXpress data path: Fast programmable packet processing in the operating system kernel // CoNEXT 2018 — Proceedings of the 14th International Conference on Emerging Networking EXperiments and Technologies. Association for Computing Machinery, Inc, 2018. Vol. 18. P. 54–66.
[10] BPF_MAP_TYPE_ARRAY and BPF_MAP_TYPE_PERCPU_ARRAY — The Linux Kernel documentation [Электронный ресурс]. URL: https://docs.kernel.org/bpf/map_array.html (дата обращения: 19.03.2026).
[11] BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants — The Linux Kernel documentation [Электронный ресурс]. URL: https://docs.kernel.org/bpf/map_hash.html (дата обращения: 19.03.2026).
[12] BPF ring buffer — The Linux Kernel documentation [Электронный ресурс]. URL: https://docs.kernel.org/6.2/bpf/ringbuf.html (дата обращения: 19.03.2026).
[13] Таненбаум Эндрю, Фимстер Ник, Уэзеролл Дэвид. Компьютерные сети. 6-е изд. — СПб.: Питер, 2023. 397–403 c. ISBN 978-5-4461-1766-6
[14] Олифер Виктор, Олифер Наталья. Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, доп. и испр. — СПб.: Питер, 2024. 378–396 с. ISBN 978-5-4461-4085-5
[15] Робачевский А. Интернет изнутри: Архитектура экосистемы Интернета / Андрей Робачевский. — 3-е изд., перераб. и дополн. — М.: Серпантин Эдженси, 2024. 17–41 с. ISBN 978-5-6052033-0-8
[16] draft-sharabayko-srt-00 [Электронный ресурс]. URL: https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-00 (дата обращения: 19.03.2026).
[17] Уорд Б. Внутреннее устройство Linux. 3-е изд. — СПб.: Питер, 2022. 342–343 с. ISBN 978-5-4461-3946-0

Об авторах:

Печерский Иван Васильевич, студент магистерской программы «Компьютерные системы и сети» МИЭМ НИУ ВШЭ
Чертов Виктор Дмитриевич, студент магистерской программы «Компьютерные системы и сети» МИЭМ НИУ ВШЭ
Научный руководитель: Александр Владимирович Белов, профессор, руководитель Департамента прикладной математики, МИЭМ НИУ ВШЭ