Статья описывает механизмы формирования трафика на внешних каналах связи в DION при наличии нескольких территориально распределённых ЦОД. Основная цель — предоставить понимание того, какие компоненты генерируют трафик между ЦОД, как он масштабируется и какие параметры конфигурации на него могут повлиять.
В инфраструктуре DION за медиаобработку отвечают два независимых серверных компонента — SFU и AudioHub. Каждый из них устанавливает собственные межсерверные соединения. Для участников, подключающихся из внешних сетей, дополнительно используется сервер TURN.
SFU — центральный медиасервер, к которому подключаются пользователи DION. Он отвечает за маршрутизацию видеопотоков между участниками конференции и построение каскадных соединений между различными SFU в случае, когда участники распределены по нескольким серверам.
Аллокацией новых SFU управляет Медиаконтроллер — отдельный компонент платформы. В облачной и гибридной архитектуре он размещён в облаке, в архитектуре на собственных серверах (on-premises) запускается в контейнере dm_mediacontroller на сервере appsvm.
Каждый SFU работает в паре со своим AudioHub: клиент подключается к SFU, получает видеопотоки от него, а аудиоданные — от AudioHub, привязанного к этому SFU.
Клиент всегда подключается только к одному SFU — ближайшему согласно настройкам геораспределения.
AudioHub — выделенный сервер аудиомикширования, работающий в паре со своим SFU. Он принимает аудиопотоки от своего SFU, микширует их в единый поток и обменивается смикшированным аудио с серверами AudioHub других ЦОД, участвующих в одной конференции.
Когда Медиаконтроллер аллоцирует новый SFU, вместе с ним по умолчанию выделяется соответствующий AudioHub. В одном ЦОД может функционировать как одна пара SFU+AudioHub, так и несколько таких пар — в зависимости от нагрузки и конфигурации системы.
SFU устанавливают между собой видеосоединения, AudioHub — аудиосоединения. Эти соединения независимы и суммируются при расчете общей нагрузки на внешний канал связи.
TURN (Traversal Using Relays around NAT) — сервер-ретранслятор, используемый клиентами, не способными установить прямое WebRTC-соединение с SFU. Подробнее о нагрузке, создаваемой такими участниками, см. в разделе Внешние участники и сервер TURN.
Каждому ЦОД в панели администрирования DION назначаются маски подсетей. При подключении клиента к платформе его IP-адрес сравнивается с назначенными масками подсетей, и клиент направляется на SFU соответствующего ЦОД. Если IP-адрес не соответствует ни одной из заданных масок, клиент направляется на ЦОД, заданный по умолчанию.
Таким образом, распределение участников конференции по ЦОД определяется не количеством участников, а их IP-адресами. Участники из разных ЦОД генерируют трафик между ЦОД.
Внутри одного ЦОД конференция может обслуживаться одной парой SFU+AudioHub или распределяться между несколькими парами:
Внешний трафик возникает только при соединении SFU и AudioHub из разных ЦОД.
Каскадное соединение между ЦОД возникает, когда к уже существующей конференции подключается участник из другого ЦОД. С этого момента:
Между серверами AudioHub передаётся один смикшированный аудиопоток в кодеке Opus с фиксированным битрейтом 48 кбит/с в каждую сторону, что составляет ≈ 96 кбит/с на одное соединение AudioHub–AudioHub. По тому же соединению передаются служебные JSON-сообщения об активных спикерах, однако их объём пренебрежимо мал.
Общее число аудиосоединений между ЦОД определяется количеством серверов AudioHub, одновременно участвующих в конференциях с участниками в обоих ЦОД — все они связываются по схеме «каждый с каждым». Например: в ЦОД-1 запущены две конференции на двух разных серверах AudioHub, в ЦОД-2 один AudioHub обслуживает участников обеих конференций — в итоге формируется 4 соединения по 96 кбит/с каждый.
Видеосоединение между SFU разных ЦОД создаётся только тогда, когда хотя бы один участник из ЦОД-2 просматривает видеопоток участника из ЦОД-1. Если никто не просматривает — соединение либо не создаётся, либо существует без трафика.
Максимальный битрейт одного видеосоединения SFU–SFU зависит от типа содержимого:
| Тип потока | Битрейт (макс.) |
|---|---|
| Видеокамера (базовое качество) | ≈ 1 Мбит/с |
| Видеокамера (включена опция «Повышенное качество») | ≈ 1,5 Мбит/с |
| Демонстрация экрана | до 3,5 Мбит/с |
| Видеокамера при активной демонстрации экрана | ≈ 150 кбит/с |
Все используемые потоки суммируются.
Примеры расчёта для одной конференции с участниками в двух ЦОД:
| Сценарий | Трафик |
|---|---|
| 1 демонстрация экрана + 1 камера в ЦОД-1; всё смотрят в ЦОД-2 | до 3,5 + 0,15 ≈ 3,65 Мбит/с + 96 кбит/с аудио |
| 4 камеры с повышенным качеством в ЦОД-1; смотрят все 4 в ЦОД-2 | 4 × 1,5 = 6 Мбит/с + 96 кбит/с аудио |
| Только аудио, нет видео | 96 кбит/с |
| 1 камера в ЦОД-1, но никто в ЦОД-2 не смотрит | 96 кбит/с (только аудио) |
На практике в крупных встречах (50+ участников) одновременно активны 2–4 спикера и максимум один транслирующий экран — это существенно снижает фактическую нагрузку относительно теоретического максимума.
Внешний участник — пользователь, чей IP-адрес не принадлежит ни одному из настроенных ЦОД. Он направляется на ЦОД, заданный по умолчанию, и подключается к SFU через TURN, поскольку прямое WebRTC-соединение для него недоступно.
Внешний участник получает все активные потоки через TURN, который ретранслирует их от SFU: смикшированный аудиопоток и каждый просматриваемый видеопоток — без агрегирования. По нагрузке на внешний канал он эквивалентен отдельному ЦОД.
Составляющие трафика для одного внешнего участника:
| Компонент | Битрейт |
|---|---|
| Аудио без микрофона (только входящий смикшированный поток) | ≈ 48 кбит/с |
| Аудио с включённым микрофоном (48 вх. + 48 исх.) | ≈ 96 кбит/с |
| Видеокамера одного вещателя (базовое качество) | ≈ 1 Мбит/с |
| Видеокамера одного вещателя (повышенное качество) | ≈ 1,5 Мбит/с |
| Демонстрация экрана одного вещателя | до 3,5 Мбит/с |
| Видеокамера при активной демонстрации экрана | ≈ 150 кбит/с |
| Несколько вещателей на экране | суммируется по каждому потоку |
Пример: внешний участник с включённым микрофоном участвует в конференции, в которой активна демонстрация экрана и включены камеры двух участников. При активной демонстрации экрана видеопотоки камер ограничиваются до ≈ 150 кбит/с каждый. Общий трафик через внешний канал составит: 3,5 + 2 × 0,15 + 0,096 ≈ 3,896 Мбит/с.
При подключении клиент получает список ICE-кандидатов, включающий адреса всех доступных серверов TURN. Выбор происходит автоматически по результатам ICE-согласования — DION не управляет этим выбором напрямую.
Если развернуты несколько серверов TURN в разных ЦОД, клиент подключится к тому, который обеспечит наилучшие характеристики соединения. Весь трафик внешнего участника будет проходить через выбранный TURN, создавая нагрузку на канал именно этого ЦОД.
DION не имеет встроенного механизма ограничения трафика между ЦОД на уровне SFU или AudioHub. Платформа запрашивает необходимую пропускную способность для обслуживания активных медиапотоков. Ограничение пропускной способности (QoS, shaping) настраивается на уровне сетевой инфраструктуры.
По умолчанию при превышении 50 участников на одном SFU-сервере Медиаконтроллер аллоцирует новый SFU и соответствующий ему AudioHub. Каждый новый сервер потенциально добавляет соединения между ЦОД:
Чтобы минимизировать количество соединений между ЦОД, можно увеличить порог аллокации новых SFU или отключить автоматическую аллокацию AudioHub при создании SFU. При отключённой автоматической аллокации AudioHub все конференции в ЦОД обрабатываются на одном AudioHub и порождают ровно одно аудиосоединение на конференцию между ЦОД.
Оба параметра настраиваются через конфигурацию медиасервера — обратитесь в техническую поддержку DION. Отключение балансировки может увеличить нагрузку на CPU одного сервера.
Оптимизация актуальна при дорогостоящих или узких каналах между ЦОД. Если внутренний трафик между ЦОД бесплатен — смысла в оптимизации нет.
Сервер отправляет клиенту проверочные сообщения (ping) через WebSocket каждые 5 секунд. Клиент отслеживает их получение:
Сервер отслеживает жизнеспособность клиентского соединения на уровне WebSocket-протокола. Если в течение 50 секунд сервер не получает ответа от клиента, соединение закрывается, а клиент автоматически исключается из конференции.
| Таймаут | Кто контролирует | Значение | Последствие |
|---|---|---|---|
| Интервал проверочных сообщений (ping) | Сервер → клиент | 5 сек | Клиент отсчитывает время до автоматического восстановления |
| Автоматическое восстановление клиента | Клиент | 15 сек без пингов | Клиент закрывает и переоткрывает WebSocket |
| Время для ответа на сообщение до разрыва соединения (pong deadline) | Сервер | 50 сек | Соединение закрывается, клиент исключается из конференции |
При деградации канала (не полной потере) участник может оставаться в конференции, если WebSocket-пакеты проходят хотя бы раз в 50 секунд. Качество медиа при этом снижается, но принудительное отключение не происходит.