Как устроен SFU Server

Визуализация 

Шаг 1. Почему кадр нельзя пустить по трубе целиком (RTP и SRTP)

• Каждый кубик укладывается в стандартную цилиндрическую капсулу RTP, на корпусе которой выбиты порядковый номер и точное время вылета (чтобы у зрителя кубики собрались в правильном порядке).
• Снаружи на время полета по уличной трубе капсула закрывается дорожным кодовым замком SRTP, чтобы никто на улице не подменил кубик.

Шаг 2. Зачем в центре города стоит стрелка, а не цех пересборки (MCU против SFU)

1. Старый сборочный цех (MCU): Капсулы от всех 20 человек прилетали в большой зал. Рабочие открывали каждую капсулу, вынимали все кубики, склеивали из 20 лиц одно общее панно, снова распиливали его на кубики и заново паковали в капсулы для каждого зрителя. Это отнимало драгоценные доли секунды и требовало огромного цеха.
2. Скоростная автоматическая стрелка (SFU): Современный узел - это компактная прозрачная развилка, где вообще не открывают капсулы со слепками. Капсула от тебя на полном ходу влетает в развилку SFU, датчик за миллисекунду считывает только адресную бирку снаружи, и автоматическая стрелка мгновенно выстреливает копии этой капсулы в трубы зрителей.

Шаг 3. Стрелка не умеет уменьшать груз, а труба в лифте узкая (Simulcast и SVC)

• Способ 1 - Три отдельные очереди (Simulcast): Аппарат отправителя дома делает сразу три независимые копии одного кадра большую (50 капсул), среднюю (15 капсул) и малую (5 капсул) и пускает все три потока до развилки SFU. Стрелке на станции остается просто направить крупный поток в широкую трубу, а малый в узкую трубку лифта.
• Способ 2 - Трехцветный модульный конструктор (SVC): Чтобы не гонять от дома до станции три отдельные копии и не тратить место в трубе впустую, отправитель шлет один набор капсул, но разделенный по цветам:
• 5 зеленых капсул несут базовый контур кадра (из них уже можно собрать картинку низкого разрешения);
• 10 желтых капсул добавляют поверх базового контура среднюю резкость;
• 35 синих капсул добавляют мелкие детали высокой четкости. Теперь, когда труба зрителя в лифте сужается, стрелка SFU одним движением заслонки отсекает синие и желтые капсулы, пропуская в узкую трубку только 5 зеленых!

Шаг 4. Как стрелке в центре города узнать, что за 50 км от нее труба в лифте начала забиваться (TWCC, GCC, BWE)

1. Счетчик интервалов на финише (TWCC): На вылете из развилки SFU на каждую капсулу наносится сквозной номер (1, 2, 3...). А прямо перед входом в телефон зрителя стоит оптическое кольцо с секундомером. Оно засекает точное время прилета каждой капсулы и каждые полсекунды отправляет обратно к станции короткую сводку TWCC: "Капсулы №101, 102 и 103 вылетели со станции с дистанцией в 5 миллисекунд, а ко мне на финиш прилетели с растянутой дистанцией в 25 миллисекунд!"
2. Датчик накопления очереди (GCC): Вычислительный блок GCC на станции SFU читает эту сводку и видит простую механику: если расстояние по времени между капсулами на выходе увеличилось, значит, они начали притормаживать в очереди перед узким горлышком роутера или сотовой вышки. Капсулы еще целы, но затор в трубе уже растет.
3. Вентиль пропускной способности (BWE): Получив сигнал от датчика GCC, регулятор BWE вычисляет реальный диаметр трубы в эту секунду и сразу поворачивает заслонку на стрелке SFU: "Пропускная способность упала отсекай синий и желтый слои SVC, подавай в трубу только зеленый базовый слой!"

Шаг 5. Как спрятать кубики от самой станции SFU, не ослепив стрелку (Insertable Streams и MLS)

• Внутренний непрозрачный футляр (Insertable Streams): Прямо в комнате отправителя, перед тем как кубик кадра упадет в прозрачную капсулу RTP, боковой механизм запаивает сам кубик в непрозрачный внутренний футляр, запертый личным ключом участников комнаты. А снаружи на стенке самой капсулы RTP остается открытая цветная метка ("Зеленый слой SVC, кадр №10"). Теперь стрелка SFU прекрасно видит цветную метку и отсекает лишние слои для лифта, но сам кубик внутри футляра для станции остается черным ящиком.
• Пирамида раздачи ключей (MLS): Чтобы у 1000 человек в звонке был одинаковый ключ от этого внутреннего футляра и он мгновенно менялся при уходе любого участника (иначе ушедший сможет читать чужие капсулы), участников связывают в пирамиду пар (по 2, по 4, по 8 человек). Когда один человек выходит из комнаты, новый ключ передается всего через 10 этажей пирамиды снизу вверх вместо поочередного обхода всех 1000 участников.

Шаг 6. Как вывести трубу со своего закрытого двора и пройти блокпосты на улице (STUN, TURN, DPI, ICE, Happy Eyeballs)

• Внешний указатель ворот двора (STUN): Находясь внутри двора за забором роутера, твой аппарат знает только внутренний номер квартиры, но не видит, через какой именно внешний люк в стене двора твоя труба выходит на улицу. Аппарат пускает пробный шарик до уличного маяка STUN, и тот присылает ответ: "Твоя труба выходит на улицу через внешний люк №48200".
• Посты досмотра (DPI) и обходной рукав (TURN): На некоторых улицах стоят сканеры провайдеров DPI, которые просвечивают трубы и перекрывают заслонку, как только замечают внутри капсулы RTP. А в строгих офисных зданиях прямые люки на улицу вообще заварены. Тогда капсулы пускают через обходной транзитный узел TURN внутри стандартной непрозрачной оболочки обычного веб сайта (HTTPS на порту 443). Сканер DPI видит стандартный банковский трафик и пропускает его без остановки.
• Автоматический выбор рабочей трубы (ICE и Happy Eyeballs): Между домом и станцией SFU всегда есть несколько вариантов прокладки пути: прямая воздушная труба (UDP), наземная рельсовая труба (ICE-TCP), старый мост IPv4, новый мост IPv6 и обходной рукав TURN. Диспетчер ICE собирает список всех доступных люков (в режиме Trickle ICE он проверяет первый же люк мгновенно, не дожидаясь остальных, а сама станция SFU в режиме ICE-Lite просто ждет входящих шаров на своем фиксированном адресе). Чтобы пользователь не ждал поочередной проверки каждого моста, стартовый клапан Happy Eyeballs запускает пробные шары в параллельные трубы одновременно: из какой трубы первой вернулось эхо за сотые доли секунды та сразу открывается для основного потока.

Шаг 7. Финал: Почему на 1 000 000 зрителей одну трубу заменяют на многоствольную обойму и районные склады (QUIC и MoQ)

• Если пустить миллион человек по старой одноколейной трубе (TCP), где все капсулы сцеплены в одну жесткую очередь, то первая же застрявшая капсула с видео заблокирует позади себя всю трубу вместе со звуком.
• А если пытаться раздать миллион потоков через классический WebRTC (RTP поверх UDP), то развилке SFU придется крутить миллион индивидуальных вентилей скорости и перешифровывать каждую капсулу лично под каждого зрителя потому что обычные городские склады (CDN) не умеют копировать безымянный поток RTP.

• Шланг с десятками независимых внутренних стволов (QUIC): Вместо одной трубы между сервером и зрителем прокладывается широкий защищенный рукав QUIC. На его конце стоит плавающая муфта (Connection ID): когда человек выходит из дома и переключается с Wi-Fi на 5G, муфта за миллисекунду перещелкивается на новую трубу без остановки потока. А внутри самого рукава, как в барабане револьвера, проходят десятки отдельных гладких стволов. Если в одном стволе застряла капсула, по всем соседним стволам внутри этого же рукава груз продолжает лететь без малейшей заминки.
• Отдельный ствол под каждую секунду видео (MoQ): Диспетчер MoQ раскладывает медиапоток по этим внутренним стволам QUIC по трем простым правилам:
• Верхний ствол только под звук: голосовые капсулы всегда вылетают первыми в обход любых видео очередей.
• Каждая новая секунда видео заряжается в свой собственный соседний ствол! В начале ствола идет тяжелая стартовая капсула (полный опорный кадр секунды), а за ней по этому же стволу скользят 30 легких капсул движений этой секунды.
• Обгон пробки без ожидания: если зритель вошел в лифт и в Стволе 10-й секунды застряла капсула, система не ждет, пока она протолкнется! В ту же долю секунды по соседнему Стволу 11-й секунды в обход затора выстреливается свежая стартовая капсула новой секунды, а застрявший 10-й ствол просто отключается и сбрасывается.
• Копирование через обычные городские склады (MoQ Relays / CDN): Поскольку каждая секундная обойма в MoQ имеет четкую серийную маркировку снаружи ("Канал 1, Видео, Секунда №11"), центральной станции SFU больше не нужно тянуть миллион труб к зрителям. Она отправляет всего одну обойму на обычные районные склады вдоль трассы (серверы CDN), а те, вообще не открывая зашифрованные капсулы, просто клонируют готовые секундные обоймы со своих полок в сотни тысяч рукавов QUIC местных зрителей.

Справочник терминов и стандартов

WebRTC (Web Real Time Communication)

MCU (Multipoint Control Unit)

SFU (Selective Forwarding Unit)

RTP и SRTP (Real time Transport Protocol / Secure RTP)

SVC (Scalable Video Coding)

BWE (Bandwidth Estimation)

TWCC (Transport Wide Congestion Control)

GCC (Google Congestion Control)

STUN (Session Traversal Utilities for NAT)

TURN (Traversal Using Relays around NAT)

ICE, ICE Lite, Trickle ICE и ICE TCP

DPI (Deep Packet Inspection)

Insertable Streams (WebRTC Encoded Transform)

MLS (Messaging Layer Security)

WHIP и WHEP (WebRTC HTTP Ingestion / Egress Protocol)

QUIC (Quick UDP Internet Connections)

MoQ (Media over QUIC)

Happy Eyeballs (Fast Fallback)

Зачем нужен SFU

Как сервер переваривает сотни тысяч пакетов в секунду

1. Пакетный асинхронный ввод вывод (Batching I/O)

2. Архитектура без блокировок

• Изоляция рабочих процессов На каждом ядре запускается полностью независимый рабочий процесс или поток (Worker) со своим циклом обработки событий и собственной таблицей маршрутизации. В безсостоятельных ретрансляторах (например, в высоконагруженных TURN серверах) потоки могут делить один порт через опцию ядра Linux SO_REUSEPORT, где сетевая карта сама раскидывает пакеты по ядрам по хэшу адресов и портов (5 tuple). А в серверах вроде Mediasoup, где конкретная комната (Router) жестко живет внутри одного конкретного процесса Worker, каждый рабочий процесс слушает свой выделенный порт (WebRtcServer), либо перед ними ставится фильтр eBPF (SO_ATTACH_REUSEPORT_EBPF), направляющий пакеты сразу на нужное ядро по идентификатору сессии (ice ufrag). Потоки не делят память друг с другом, поэтому мьютексы им не нужны.
• Неблокирующиеся кольцевые буферы Если одному потоку все же нужно передать пакет другому (например, когда отправитель и зритель обслуживаются разными ядрами), используется кольцевая очередь в памяти. Для пары "один писатель - один читатель" блокировки вообще не требуются один поток меняет только индекс записи, а другой - только индекс чтения с помощью быстрых атомарных операций и барьеров памяти (Acquire / Release) за считанные такты процессора. Если же в очередь пишут сразу несколько потоков (MPSC / MPMC), указатели сдвигаются аппаратными атомарными инструкциями сравнения с обменом (CAS - Compare And Swap, занимающими 15–40 тактов) без системных вызовов и остановки потоков.

3. Жесткая привязка к ядрам процессора

• Потеря горячего кэша L1 и L2 У каждого физического ядра процессора есть сверхбыстрая собственная память - кэш L1 и L2 (время доступа - около 1–4 наносекунд против 60–100 наносекунд у оперативной памяти RAM). Пока поток работает на одном ядре, код обработки RTP пакетов и контексты шифрования SRTP лежат прямо в кэше L1/L2. Как только поток переезжает на соседнее ядро, его кэш оказывается пустым, и процессор простаивает сотни тактов, подтягивая данные из медленной оперативной памяти (Cache Miss).
• Холодный буфер адресов На новом физическом ядре кэш трансляции виртуальных адресов памяти в физические (TLB) оказывается незаполненным для страниц памяти этого потока, что вызывает серию дорогих промахов TLB Miss при обращении к сетевым буферам.
• Штрафы архитектуры NUMA На многопроцессорных серверах переезд потока на ядро другого процессорного сокета заставляет его тянуть сетевые буферы из "чужой" памяти через межпроцессорную шину с повышенной задержкой.

Что происходит с видео в лифте и как работают BWE, TWCC и GCC

1. Разбиение кадра на десятки пакетов Один кадр видео 1080p (особенно полный опорный кадр - I frame) весит от 30 до 100 КБ. Поскольку максимальный размер одного сетевого пакета в интернете (MTU) составляет около 1200–1500 байт, один видеокадр нарезается на 30–80 отдельных RTP пакетов.
2. Переполнение буфера сотовой вышки и сброс пакетов Когда поток из десятков пакетов ударяется в узкое горлышко радиоканала в лифте, очередь памяти на базовой станции переполняется за доли секунды (Bufferbloat), и маршрутизатор оператора начинает принудительно выбрасывать невлезающие пакеты (Packet Loss).
3. Остановка декодера и шторм перезапросов (PLI Storm) Видеодекодер в телефоне не может собрать кадр, если из 50 его пакетов потерялись хотя бы несколько штук. Более того, следующие за опорным кадром разностные кадры (P frames) хранят только математические изменения относительно предыдущего кадра. Потеряв опору, декодер оставляет на экране последнюю целую картинку и шлет на сервер аварийный сигнал PLI (Picture Loss Indication) - "пришли новый полный опорный кадр". Если сервер в ответ вышлет в лифт новый тяжелый ключевой кадр, он окончательно забьет узкий канал.

Как устроен протокол сбора данных TWCC

1. Сквозная маркировка на выходе Отправитель (например, SFU при раздаче потока зрителю) добавляет в заголовок каждого уходящего RTP пакета специальное расширение - единый возрастающий номер пакета (Transport Wide Sequence Number 1, 2, 3, 4...), а у себя в памяти записывает точное время отправки каждого номера с точностью до микросекунд.
2. Журнал приема на телефоне Смартфон получателя принимает эти пакеты и фиксирует по своим внутренним часам точное время прихода каждого номера.
3. Квитанция обратной связи Каждые 50–100 миллисекунд получатель упаковывает эти замеры в компактный служебный пакет RTCP (TransportLayerFeedback) и отправляет обратно "Пакеты №101–120 получены, интервалы прибытия между ними составили столько то четвертей миллисекунды (шаг 250 мкс), а пакет №115 не дошел".

Как алгоритм GCC вычисляет скорость канала по данным TWCC

• Контроллер на основе задержки (Delay based controller - главный) Он сравнивает интервалы времени, с которыми пакеты выходили от отправителя (tsend), с интервалами, с которыми они приходили к получателю (trecv). Разница между ними называется вариацией межпакетной задержки (One Way Delay Gradient). Если сервер отправил два пакета с разницей в 5 мс, а на телефон они пришли с разницей в 8 мс, потом 12 мс, потом 18 мс - математический фильтр тренда (Trendline filter или фильтр Калмана) внутри GCC сразу подает сигнал тревоги очередь в буфере роутера перед телефоном начала расти. Пакеты еще не теряются, картинка еще плавная, но канал уже перегружен. GCC немедленно дает команду снизить битрейт, предотвращая зависание видео заранее.
• Контроллер на основе потерь (Loss based controller - страховочный) Он смотрит на долю потерянных пакетов в квитанции TWCC. Если потерь менее 2% - алгоритм разрешает плавно повышать битрейт, нащупывая потолок канала. Если потери составляют от 2% до 10% - скорость удерживается на текущем уровне. Если потеряно более 10% пакетов - битрейт экстренно урезается пропорционально доле потерь.

Simulcast и SVC как уменьшить картинку без перекодирования

Simulcast (три отдельных конвейера)

SVC (принцип слоеной матрешки)

Семейство протоколов ICE и работа с TURN сервером

Разбор всех режимов ICE простым языком

• Full ICE (Полный ICE, RFC 8445) Стандартный режим, в котором работают браузеры и мобильные приложения при звонке друг другу. Оба устройства сначала собирают все свои возможные адреса (кандидаты) локальный адрес в домашней сети (Host candidate), внешний адрес роутера, узнанный через STUN сервер (Server Reflexive candidate), и резервный адрес на ретрансляторе TURN (Relayed candidate). Затем оба устройства начинают взаимно простукивать все пары адресов проверочными пакетами, пока не найдут самый короткий рабочий маршрут.
• ICE Lite (Облегченный серверный ICE) Упрощенный режим специально для медиасерверов SFU. Поскольку SFU всегда стоит в дата центре на фиксированном публичном ("белом") IP адресе и не прячется за домашним роутером, ему не нужно опрашивать STUN серверы и первым рассылать проверочные пакеты клиентам. В режиме ICE Lite сервер просто публикует свой IP и порт и отвечает на входящие проверки от браузера. Это экономит процессорное время сервера и ускоряет подключение.
• Trickle ICE (Капельный ICE, RFC 8838) В старом режиме ICE браузер сначала несколько секунд собирал абсолютно все свои адреса (опрашивал сетевые карты, STUN и TURN) и только потом одним большим списком отправлял их серверу. В режиме Trickle ICE браузер передает кандидатов "по капле" параллельно по мере их обнаружения в первую же миллисекунду отсылает локальный адрес, через 20 мс - адрес от STUN. В итоге соединение с SFU устанавливается почти мгновенно.
• ICE TCP (Прямой ICE поверх TCP, RFC 6544) В некоторых общественных сетях Wi Fi и офисах системные администраторы блокируют протокол UDP. Стандарт ICE TCP позволяет SFU открыть обычный TCP порт и принимать медиапакеты напрямую от браузера без участия TURN сервера (каждый RTP пакет при этом предваряется двухбайтовым заголовком длины по стандарту RFC 4571). Он бывает трех подтипов passive (сервер ждет входящее соединение - основной режим для SFU), active (клиент сам открывает соединение) и so (simultaneous open - одновременный встречный пробой).
• ICE Restart (Перезапуск ICE) Механизм быстрого восстановления связи при смене сети. Когда человек во время звонка выходит из дома и телефон переключается с Wi Fi на 4G/5G, его IP адрес меняется. Чтобы не сбрасывать весь звонок и не пересоздавать сессию в комнате, браузер генерирует новые пароли ICE (ice ufrag и ice pwd), за доли секунды прокладывает новый маршрут к SFU и продолжает передавать видео в тот же самый поток.

Зачем перед SFU нужен TURN сервер, если есть ICE Lite и ICE TCP?

• Маскировка под HTTPS (TURN over TLS) На прямом соединении с SFU по ICE TCP рукопожатие начинается с открытых нешифрованных пакетов STUN. Система фильтрации DPI на порту 443 видит, что внутри идет не настоящий веб трафик TLS, и обрывает связь. И только при подключении к TURN серверу по схеме turns443 браузер сначала устанавливает полноценное криптографическое соединение TLS (точно такое же, как при входе в интернет банк), внутрь которого уже прячет все пакеты WebRTC.
• Проход через офисные HTTP прокси В закрытых корпоративных сетях, где компьютеры вообще не имеют прямого выхода в интернет, браузер умеет пробивать туннель до TURN сервера через штатный корпоративный прокси сервер методом HTTP CONNECT.
• Мультиплексирование на одном порту В современной архитектуре на внешнем порту 443 ставят умный балансировщик (или встроенный в SFU TURN модуль), который принимает замаскированный TLS поток, снимает внешнюю оболочку TLS в памяти сервера и сразу передает пакеты в ядро SFU без задержек на пересылку по сети.

Гео каскадирование серверов

Сквозное шифрование в групповых звонках Insertable Streams и MLS

Как работают Insertable Streams (WebRTC Encoded Transform)

1. Когда видеокодек (например, VP9 или AV1) сжал кадр видео, браузер передает массив байтов этого кадра в специальный фоновый скрипт (Web Worker).
2. Скрипт шифрует только саму картинку (полезную нагрузку) по стандарту SFrame (Secure Frame, RFC 9605) секретным групповым ключом, которого нет у сервера.
3. Зашифрованный кадр возвращается обратно в браузер, который упаковывает его в стандартные RTP пакеты и прикрепляет открытую внешнюю этикетку - незашифрованный заголовок RTP и дескриптор зависимостей (Dependency Descriptor).
4. В результате SFU видит открытую этикетку ("это кадр №540, средний слой 540p, не опорный"), свободно переключает слои качества под интернет зрителей, но внутри самой "шкатулки" видит только зашифрованный шум.

Как работает протокол MLS (Messaging Layer Security, RFC 9420)

• Все участники комнаты размещаются в нижних узлах (листьях) виртуального бинарного дерева, а на самой вершине (в корне дерева) находится общий групповой ключ шифрования медиапотока.
• Каждый участник знает секретные ключи только вдоль своей прямой ветки от своего листа до корня дерева.
• Когда один человек выходит из комнаты на 1024 участника, системе не нужно рассылать 1024 индивидуальных сообщения - достаточно обновить всего 10 узлов вдоль одной ветки дерева 2(1024)=10. Благодаря логарифмической сложности O(N) ротация ключей в огромных конференциях происходит за считанные миллисекунды.

Универсальные шлюзы WHIP и WHEP и подключение ИИ

• WHIP (WebRTC HTTP Ingestion Protocol, RFC 9725 - на вход в сервер) Позволяет любой программе для стриминга (включая OBS Studio и FFmpeg) начать вещание в любой SFU за долю секунды, отправив параметры сессии (SDP Offer) одним стандартным запросом HTTP POST на веб адрес сервера и получив ответ 201 Created (SDP Answer).
• WHEP (WebRTC HTTP Egress Protocol - на выход к зрителю) Позволяет любому легковесному плееру в браузере, мобильном приложении или Smart TV забрать живой поток из SFU по обычной веб ссылке одним HTTP запросом без подключения тяжелых проприетарных библиотек конкретного сервера.
• Внутренние шлюзы для ИИ Современные SFU имеют прямые серверные интерфейсы для подключения нейросетей (моделей распознавания и синтеза речи или мультимодальных голосовых ассистентов). Нейросеть подключается к комнате на уровне памяти сервера как виртуальный участник, получает чистый аудиопоток без интернет задержек и мгновенно возвращает сгенерированный голосовой ответ.

Подробный разбор QUIC и MoQ будущее доставки видео

1. Сложное и долгое подключение Чтобы запустить звонок, устройству нужно провести цепочку отдельных рукопожатий (проверка ICE, затем криптографическое рукопожатие DTLS, затем настройка SRTP).
2. Несовместимость с дешевыми сетями доставки контента (CDN) В WebRTC каждый зритель поддерживает индивидуальную зашифрованную сессию с сервером SFU. Если трансляцию смотрят 100 000 человек, вам придется арендовать сотню мощных SFU серверов, потому что обычные кэширующие серверы CDN (Cloudflare, Akamai, Fastly) умеют раздавать только статические файлы (как в HLS/DASH с задержкой 5–15 секунд) и не понимают потоковый WebRTC.

Как устроен протокол QUIC (RFC 9000)

• Мгновенный старт (1 RTT и 0 RTT) В QUIC шифрование TLS 1.3 встроено прямо в сам транспортный протокол. Установка соединения и обмен ключами происходят одновременно за один оборот пакета (1 RTT), а при повторном подключении к знакомому серверу данные летят с первой же миллисекунды (0 RTT).
• Независимые потоки без блокировки очереди (No Head of Line Blocking) Если передавать аудио и видео через обычный протокол TCP, потеря одного пакета с тяжелым видеокадром заставляет операционную систему остановить чтение всего TCP соединения, пока потерянный пакет не перешлют заново. Из за этого вместе с видео заикается и звук, который уже давно дошел до телефона. В QUIC внутри одного соединения создаются десятки легких независимых логических потоков (QUIC Streams) и быстрых датаграмм (QUIC Datagrams, RFC 9221). Если в потоке с видео потерялся пакет, соседний поток с голосом продолжает воспроизводиться без единой запинки.
• Бесшовная миграция соединения (Connection Migration) В старых протоколах соединение жестко привязано к паре "IP адрес + порт". Когда вы выходите из дома и смартфон переключается с Wi Fi на 5G, IP адрес меняется и связь рвется (требуя перезапуска ICE Restart). В QUIC каждое соединение идентифицируется криптографическим номером Connection ID (CID) в заголовке пакета. Когда телефон меняет сеть на 5G, он просто продолжает слать пакеты со старым Connection ID с нового IP адреса, и сервер узнает его на лету без потери ни одного кадра.

Как работает стандарт MoQ (Media over QUIC)

• Объектная модель данных (Tracks → Groups → Objects) Вместо бесконечного неразрывного потока пакетов (как в RTP) MoQ организует трансляцию в четкую иерархию именованных объектов. Канал вещания делится на дорожки (Tracks) отдельно аудио, отдельно видео 1080p, отдельно видео 360p, отдельно субтитры. Каждая видеодорожка нарезается на группы (Groups) - это короткие независимые отрезки видео (обычно GOP - Group of Pictures длительностью 1–2 секунды, начинающиеся с полного опорного кадра). Внутри группы лежат отдельные объекты (Objects) - конкретные видеокадры, которые стримятся кадр за кадром по мере их выхода из камеры с задержкой в десятки миллисекунд.
• Отдельный QUIC поток на каждую группу кадров и умные приоритеты Каждая новая группа кадров (GOP) отправляется в собственном независимом QUIC потоке с явно заданным приоритетом (Delivery Priority). Если человек зашел в лифт и старая группа видеокадров застряла при передаче, сервер не пытается бесконечно досылать устаревшее видео - он дает максимальный приоритет 1) звуку, 2) самой свежей группе кадров, а старый застрявший поток просто закрывает командой STOP_SENDING. Благодаря этому видео никогда не отстает от живого разговора.
• Дешевое масштабирование через кэширующие реле (MoQ Relays / CDN) Поскольку каждый кадр в MoQ имеет уникальное имя (ID трансляции + ID дорожки + номер группы + номер кадра), промежуточным серверам больше не нужно понимать устройство видеокодеков или расшифровывать медиаданные. Обычный пограничный сервер CDN (MoQ Relay) получает один поток от автора с задержкой 100 мс, складывает именованные кусочки в быструю оперативную память и раздает их сотням тысяч зрителей по модели подписки (Pub/Sub), одновременно позволяя перематывать эфир назад на несколько секунд.

Почему блокировки UDP не страшны

• Дверь UDP443 Принимает около 90% всего медиатрафика на максимальной скорости и с минимальной задержкой. Умный сетевой демультиплексор на входе смотрит на первые байты пакета и за наносекунды распределяет трафик пакеты STUN/DTLS/SRTP направляет в движок классического WebRTC, а пакеты QUIC - в движок MoQ.
• Дверь TCP443 Принимает сигнальные команды управления, HTTP запросы WHIP и WHEP, прямые соединения ICE TCP, резервный поток HTTP/2 и замаскированный под обычный HTTPS сайт трафик TURN over TLS, гарантируя 100% проходимость звонков и трансляций в любых сетях мира.

Готовые платформы для создания видеосерверов

• Mediasoup (C++ и Rust) Сверхбыстрая низкоуровневая библиотека конструктор с архитектурой Shared Nothing для тех, кто хочет выжать максимум потоков из каждого ядра процессора и написать собственную бизнес логику управления комнатами на Node.js или Rust.
• Janus WebRTC Server © Легковесный модульный ветеран рынка с минимальным потреблением памяти, который отлично подходит для встраиваемых систем, стыковки браузеров с классической офисной телефонией SIP и IP камерами наблюдения (RTSP).
• Pion / Ion SFU (Go) Набор гибких библиотек протоколов WebRTC на языке Go, позволяющий быстро собрать собственный специализированный медиасервер, кастомный шлюз или серверный рекордер с нуля.
• Slyber SFU Server (Go) Готовый распределенный медиасервер "из коробки" со встроенным гео каскадированием, интегрированным TURN/TLS шлюзом на порту 443, поддержкой WHIP/WHEP и готовым фреймворком для подключения голосовых и видео агентов ИИ.