Доставка через WebRTC: от P2P к масштабируемому распространению

Опубликовано: 2026-05-21 · Время чтения: 22 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-21 с IETF RFC 8825 (Overview of Real-Time Protocols for Browser-Based Applications, февраль 2021), RFC 8826–RFC 8866 (ядро семейства WebRTC), RFC 9725 (WHIP, март 2025), IETF draft-ietf-wish-03 (март 2026), W3C webrtc Candidate Recommendation Snapshot 2024-11-26, Apple HLS Authoring Specification, ревизия 2025-09 (для раздела о гибридном стеке), документацией Cloudflare Stream WebRTC, документацией Dolby OptiView Real-time Streaming, гайдом разработчика AWS IVS Real-Time Streaming, инженерным постом LiveKit «глобальная распределённая меш-сеть» (2024), публичной документацией mediasoup и Bitmovin Video Developer Report 2025/26.

TL;DR

WebRTC – Web Real-Time Communications, определённый семейством IETF RFC 8825–8866 и спецификацией W3C webrtc – был разработан в 2011 году как способ прямого обмена аудио, видео и данными между двумя браузерами с минимальной задержкой: медиа передавались напрямую по UDP с шифрованием SRTP через DTLS. Через пятнадцать лет стриминговая индустрия адаптировала тот же протокол для доставки одного потока миллионам зрителей с задержкой 200–500 мс «от экрана до экрана», маршрутизируя его через дерево Selective Forwarding Unit (SFU) – медиа-серверов, которые принимают один WebRTC-поток от вещателя и передают каждому подключённому зрителю отдельный WebRTC-поток. Архитектура работает, но ведёт себя иначе, чем HLS или DASH: каждый зритель – это полноценный WebRTC-пир со своей DTLS-сессией, набором ICE-кандидатов и собственной нагрузкой на сервер, поэтому бэкенд платит за зрителя, а не за гигабайт в кэше. В этой статье мы разберём, как WebRTC превратился из протокола для 1:1-звонков в инструмент one-to-many-доставки, почему любой современный поставщик WebRTC-стриминга (Cloudflare Stream, Dolby OptiView, LiveKit, AWS IVS Real-Time, Mux Live, Ant Media) использует одну и ту же схему каскадных SFU, сколько это стоит и где проходит граница между WebRTC, HLS, LL-HLS и Media over QUIC.

Почему это важно

Если вы разрабатываете продукт, в котором зритель должен реагировать на происходящее менее чем за секунду – live-ставки на спорт, интерактивные шоу, аукционы, телемедицинские консультации, e-learning с поднятием руки, live shopping, удалённое видеонаблюдение, низколатентное управление дронами, – HLS и DASH вам не подойдут. Даже Low-Latency HLS, самый агрессивный HTTP-протокол, доступный сегодня в продакшене, в реальных условиях даёт задержку от 1,5 до 3 секунд glass-to-glass. WebRTC-доставка при тех же условиях обеспечивает задержку от 200 до 500 мс и остаётся единственным протоколом, способным поддерживать интерактивные сценарии в масштабах интернета. Инженерный компромисс здесь жёсткий: WebRTC масштабируется линейно по числу зрителей, а не логарифмически за счёт edge-кэшей; стоимость серверных ресурсов на одного зрителя в 10–100 раз выше, чем у HLS; сложность плеера и всей инфраструктуры – значительная. Эта статья объясняет этот компромисс так, чтобы продуктовые, архитектурные и финансовые команды могли выбрать подходящий протокол для конкретной задачи, и показывает ключевые точки – simulcast, SVC, каскад SFU, WHEP-egress, мост WebRTC→HLS – где система либо оправдывает свою стоимость, либо её сжигает.

Для чего проектировали WebRTC и что изменилось

WebRTC был стандартизирован с 2011 по 2021 год как способ обмена аудио, видео и данными между двумя браузерами напрямую через публичный интернет с минимальной задержкой. В феврале 2021 года IETF опубликовала первый стабильный обзорный документ – RFC 8825 – Overview: Real-Time Protocols for Browser-Based Applications – вместе с остальной частью семейства RFC 8826–8866, которое закрепило модель безопасности (RFC 8826), транспортный уровень (RFC 8835), каналы данных (RFC 8831), управление перегрузками (RFC 8888) и использование SDP (RFC 8839). Спецификация JavaScript-API от W3C webrtc достигла статуса Candidate Recommendation в 2021 году и в последний раз была обновлена как Candidate Recommendation Snapshot 26 ноября 2024 года.

Исходный сценарий – аудио- или видеозвонок 1:1 между двумя вкладками браузера. Два пира собирают сетевые кандидаты с помощью протокола Interactive Connectivity Establishment (ICE), обмениваются описанием сессии по протоколу Session Description Protocol (SDP) – offer и answer – через прикладной сигнальный канал, проходят DTLS-рукопожатие для генерации общих ключей и после этого напрямую друг другу по UDP отправляют RTP-пакеты, зашифрованные с помощью Secure RTP (SRTP). Сквозная задержка в такой схеме складывается из времени кругового обхода (RTT) между пирами – обычно 50–200 мс в публичном интернете – и дополнительных задержек на кодирование/декодирование, буферизацию джиттера и рендеринг, добавляющих ещё 100–200 мс. Итоговый бюджет задержки – 200–500 мс, и именно эту цифру до сих пор называют все вендоры WebRTC.

Два структурных факта в этом дизайне определяют всё, что следует далее. Первый: каждая WebRTC-сессия – это реальное время, stateful-связь ровно между двумя конечными точками – в протоколе нет понятия HTTP-кэша, сегментов, манифеста, нечего хранить на CDN и раздавать множеству клиентов без активного медиа-сервера. Второй: каждое WebRTC-соединение потребляет ресурсы сервера всё время, пока зритель смотрит – CPU на SRTP-шифрование, память на jitter-буфер и UDP-сокет, который какой-нибудь фаервол по пути готов держать открытым. Именно эти два факта делают доставку через WebRTC для множества зрителей принципиально иной – экономически и архитектурно – по сравнению с доставкой через HLS.

От двух пиров к множеству – три топологии

Когда индустрия захотела использовать WebRTC для one-to-many-доставки, а не только для 1:1-звонков, появились три топологии. У каждой – свой профиль стоимости, задержки и операционная сложность.

Mesh

Первая топология – mesh: каждый участник сессии устанавливает прямое WebRTC-соединение с каждым другим участником. При N участниках сеть содержит N × (N−1) соединений; каждый паблишер передаёт N−1 копий своего потока; каждый зритель получает N−1 потоков. Mesh обеспечивает минимальную задержку среди всех топологий (один сетевой хоп, отсутствие обработки на медиа-сервере) и минимальные затраты на серверы (медиа-сервер не требуется – только сигналлинг и резервный TURN). Однако она не масштабируется: уже при 4–6 участниках канал передачи данных каждого участника перегружается, а CPU не справляется с N−1 одновременными декодерами. Mesh подходит для небольших звонков (видеочат браузер-браузер с двумя-тремя участниками) и плохо подходит для любых других сценариев. Никто не использует mesh для доставки – это топология 1:few, а не 1:many.

MCU – Multipoint Conferencing Unit

Вторая топология – Multipoint Conferencing Unit (MCU). MCU – это медиа-сервер, который принимает аудио и видео от каждого участника, декодирует их, микширует аудио в единый поток и компонует видео в одну общую картинку (классическая сетка в стиле «Brady Bunch»), после чего перекодирует полученный микс и отправляет один поток каждому зрителю. MCU были стандартной архитектурой конференц-связи в эпоху H.323 / SIP, поскольку позволяли устройствам с ограниченным объёмом CPU получать один поток с низкой битрейтовой скоростью. Сегодня они почти исчезли по двум причинам. Во-первых, пайплайн «декодирование – микс – кодирование» добавляет задержку в 100–300 мс на каждый хоп, что сводит на нет главное преимущество WebRTC. Во-вторых, вычислительная нагрузка на CPU от декодирования каждого входящего потока и перекодирования итогового видео огромна: один поток 1080p при 30 кадрах в секунду требует от 1,5 до 3,0 ядер современного сервера непрерывно. MCU сохраняются лишь в строго контролируемых корпоративных системах конференц-связи, где модель «декодер на сервере» остаётся единственным способом поддержки устаревших устройств; для доставки WebRTC на интернет-масштабе их никто не использует.

SFU – Selective Forwarding Unit

Третья топология – Selective Forwarding Unit, SFU. SFU – это медиа-сервер, который принимает RTP-поток каждого паблишера, не декодирует его и пересылает те же самые RTP-пакеты каждому подписанному зрителю через отдельное WebRTC-соединение. SFU добавляет задержку около 20–80 мс на хоп – значительно меньше, чем MCU, – и потребляет на порядок меньше CPU, поскольку никогда не декодирует и не перекодирует потоки. Компромисс заключается в том, что каждый зритель должен запускать полноценный WebRTC-декодер; однако все современные устройства – браузеры, iOS, Android, Smart TV с WebView, set-top box – с этим справляются. SFU – топология, которую в 2026 году использует любой вендор WebRTC-доставки: mediasoup, Janus, LiveKit Server, Jitsi Videobridge, Pion, ion-sfu, бэкенд WebRTC в Cloudflare Stream, платформа Dolby OptiView и сервис AWS IVS Real-Time – все построены на её основе.

Самое важное, что нужно понять про SFU в роли доставки: downstream каждого зрителя – это его собственное реальное WebRTC-соединение. SFU – не CDN-edge: он не может одновременно передавать один и тот же поток байтов нескольким клиентам из кэша. У каждого подписчика своя DTLS-сессия, свой набор ICE-кандидатов, своя петля обратной связи jitter-буфера и своя петля управления перегрузкой. На каждого клиента SFU тратит CPU и память. Это форма стоимости, к которой мы ещё несколько раз вернёмся в этой статье.

Как SFU реально масштабируется – simulcast и SVC

Один SFU на одной машине обычно обслуживает несколько сотен – несколько тысяч зрителей, в зависимости от параметров кодирования и мощности машины. Две технологии – simulcast и Scalable Video Coding (SVC) – позволяют одному SFU поддерживать гораздо более широкий диапазон пропускных способностей зрителей от одного потока паблишера без перекодирования.

Симультантное вещание

В simulcast вещатель одновременно кодирует одно и то же видео в двух или трёх разрешениях и битрейтах, отправляя все варианты в SFU как отдельные RTP-потоки в рамках одной WebRTC-сессии. Типичная конфигурация simulcast для трансляции в реальном времени:

High:     1080p @ 2.5 Mbps
Medium:    540p @ 0.8 Mbps
Low:       180p @ 0.15 Mbps

SFU затем направляет ровно один из этих трёх потоков каждому подписчику, исходя из последнего сообщённого им бэндвида и бюджета декодера. Зритель, подключённый по оптике, получает 1080p; зритель на телефоне через LTE – 540p; зритель на слабом 3G-соединении – 180p. Решение о передаче может меняться для любого зрителя в любой момент во время трансляции без перекодирования – SFU просто переключает, какой из трёх потоков направляется в канал этого зрителя. Это аналог adaptive-bitrate (ABR) выбора в HLS или DASH, но реализованный на сервере, с точностью до кадра и в рамках одной RTP-сессии.

Цену платит вещатель: кодирование трёх версий вместо одной требует примерно в 2,0–2,5 раза больше CPU по сравнению с одноканальным кодированием (энкодер частично использует результаты ранних вычислений для всех рендиций). Выгоду получает зритель: каждый получает версию, оптимальную под свою сеть и устройство, а нагрузка на SFU для каждого зрителя соответствует его реальным возможностям по приёму.

SVC – Scalable Video Coding

Scalable Video Coding (SVC) – более изящное решение. Вещатель кодирует один поток, но он организован в несколько слоёв: обычно три временных (та же картинка на 7,5, 15 и 30 fps) и два-три пространственных (та же картинка в 360p, 720p и 1080p). Каждый слой – это срез, который SFU может покадрово отбросить или сохранить. Чтобы отправить зрителю версию 540p@15fps, SFU пересылает базовый пространственный слой и один временной enhancement-слой, отбрасывая остальные. При восстановлении полосы пропускания SFU начинает пересылать больше слоёв, чтобы поднять качество до 1080p@30fps. Декодер зрителя восстанавливает картинку максимально возможного качества из тех слоёв, что пришли.

У SVC есть два практических преимущества перед simulcast: вещатель кодирует один поток вместо трёх (меньше нагрузки на CPU у паблишера), а SFU может переключать рендиции на каждом кадре без артефактов (не нужно ждать нового IDR-кадра в нужной рендиции). Недостаток – кодек должен поддерживать SVC. VP9 поддерживает SVC с 2014 года (Google использует VP9-SVC в Meet уже много лет). AV1 поддерживает SVC как полноценную функцию и именно к нему индустрия движется для доставки в WebRTC в 2026 году. H.264 поддерживает SVC только через опциональное расширение Annex G, которое большинство аппаратных энкодеров не реализуют, поэтому H.264-стеки вынуждены использовать simulcast.

Комбинация simulcast (или SVC) плюс SFU – это то, что делает доставку через WebRTC масштабируемой по ширине: один паблишер может обслуживать разнородных зрителей. Сама по себе такая архитектура не масштабируется по количеству – один паблишер не справится с большим числом зрителей. Для этого нужен каскад.

Каскад SFU – как WebRTC масштабируется до миллиона зрителей

Один SFU на одной машине в хорошо настроенном продакшене способен обслуживать несколько сотен – несколько тысяч одновременных WebRTC-подписок, прежде чем станут ограничением CPU или пропускная способность канала. Чтобы обслуживать больше зрителей, чем может вместить одна машина, индустрия использует каскад SFU – дерево SFU, в котором корневой SFU получает поток от вещателя и пересылает его небольшому числу дочерних SFU, каждый из которых раздаёт поток своей группе зрителей и сам может иметь перед собой SFU-внуков.

Математика – то, что делает это рабочим. Если каждый SFU обслуживает 1000 зрителей в downstream, то двухъярусное дерево с одним корнем и 100 листовыми SFU обслуживает 100 000 зрителей; трёхъярусное дерево с одним корнем, 100 узлами среднего уровня и по 100 листьев на каждом из них – 10 миллионов. Количество переходов от вещателя до самого дальнего зрителя – 3, и каждый переход добавляет задержку 20–80 мс, поэтому общая задержка каскада составляет около 60–240 мс – достаточно мало, чтобы общий бюджет задержки в большинстве production-развёртываний оставался ниже 500 мс.

В каскаде две инженерные тонкости, которые вендоры решают по-разному. Первая – кто кого тянет: любое каскадное развёртывание должно определить, как листовой SFU находит родителя (чтобы запросить поток), и как корневой SFU узнаёт обо всех своих детях (чтобы не перераспределять ресурсы). Опубликованная архитектура LiveKit использует mesh SFU с peer-to-peer-маршрутизацией через Redis; Cloudflare Stream применяет Durable Objects в своей глобальной сети, чтобы привязать поток к одному origin и заставить edge-узлы запрашивать его по мере необходимости; Dolby OptiView Real-time Streaming (бывший Millicast) строит собственный CDN-подобный overlay. Каждый из этих подходов – рабочий ответ на один и тот же вопрос.

Вторая тонкость – изоляция отказов. Если дочерний SFU падает посреди трансляции, зрители под ним должны переподключиться к соседнему узлу без нарушения работы остальной части дерева. Паттерны здесь хорошо известны из CDN-инжиниринга – health-чеки, fast-reroute, переподключение со стороны зрителя с экспоненциальным бэкоффом – и каждый вендор WebRTC-доставки реализует свою версию.

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

WHEP – стандартизированный egress для доставки WebRTC

В течение первого десятилетия существования WebRTC каждый вендор разрабатывал собственный сигналлинг – побочный канал, через который передавались SDP offer и answer до установления WebRTC-соединения. Сигналлинг Cloudflare отличался от LiveKit, тот – от Janus, тот – от mediasoup, а тот – от Dolby. Любой плеер приходилось переписывать под стек каждого вендора. У RTMP такой проблемы не было – протокол включал в себя встроенный сигналлинг, – и индустрия понимала, что это серьёзный барьер для внедрения доставки через WebRTC.

WHIP – WebRTC-HTTP Ingestion Protocol, IETF RFC 9725, опубликован в марте 2025 года – стал первым стандартизированным сигнальным протоколом для WebRTC. Он определяет один HTTP POST с SDP offer от паблишера; сервер отвечает SDP answer в теле запроса; WebRTC-соединение устанавливается. WHIP решает задачу паблишера – это протокол, с помощью которого энкодер отправляет поток на сервер.

WHEP – WebRTC-HTTP Egress Protocol – решает задачу со стороны зрителя. На момент написания последней ревизией является draft-ietf-wish-whep-03, опубликованная в марте 2026 года. Протокол полностью повторяет WHIP: один HTTP POST с SDP offer от зрителя; сервер отвечает SDP answer; устанавливается WebRTC-соединение; SFU начинает пересылку RTP. После установления соединения WHEP больше не участвует – транспорт становится обычным WebRTC. WHEP выполняет только функцию сигналлинга. Протокол пока находится в статусе Internet-Draft и может быть пересмотрен, однако его архитектура стабильна, и каждый крупный вендор (Cloudflare Stream, Dolby OptiView, Mux Live, LiveKit, Ant Media, OvenMediaEngine) уже внедрил WHEP-эндпоинт в продакшен.

WHEP – это то, что позволяет плееру доставки WebRTC в 2026 году переключаться между бэкендами почти так же легко, как HLS-плеер переключается между origin-ами. Один open-source-плеер (WHEP-совместимые компоненты hls.js, SDK RoomConnection LiveKit в WHEP-режиме, OvenPlayer, WebRTC-режим THEOplayer) может воспроизводить контент с любого соответствующего WHEP-совместимого сервера. Именно такая стандартизация наконец-то открывает WebRTC для потоковой доставки на уровне портативности плееров, который HTTP-протоколы обеспечивают с 2010 года.

Нажмите, чтобы увеличить

Бюджет задержки – куда уходят 200–500 мс

Заголовочная цифра задержки для WebRTC-доставки – 200–500 мс glass-to-glass. Разберём бюджет по компонентам – это делает картину конкретной и показывает, где вендоры до сих пор находят выигрыш.

Возьмём типичную конфигурацию: вещатель в Берлине транслирует контент зрителю в Сан-Франциско через каскад SFU, включающий один корневой SFU во Франкфурте, один промежуточный (middle-tier) в Вашингтоне и один edge-узел в Сан-Хосе.

Захват и кодирование (вещатель):                  30–60 мс
Сеть: Берлин → Франкфурт (RTP):                    5–15 мс
Пересылка SFU (Франкфурт):                        10–30 мс
Сеть: Франкфурт → Вашингтон (private):            90–110 мс
Пересылка SFU (Вашингтон):                        10–30 мс
Сеть: Вашингтон → Сан-Хосе (private):             55–70 мс
Пересылка SFU (Сан-Хосе):                         10–30 мс
Сеть: Сан-Хосе → зритель (public, last mile):      5–25 мс
Декод и рендер (зритель):                         30–60 мс
Jitter buffer (переменный):                       30–80 мс
                                                ----------
Итого:                                          275–510 мс

Доминируют два бюджета. Первый – длинный межрегиональный сегмент Франкфурт ↔ Вашингтон: это физика, скорость оптоволокна через Атлантику, и никакой протокол на земле её не обгонит без спутника посередине. Каждый вендор WebRTC-доставки компенсирует это, прокладывая свой бэкбон через приватный пиринговый обмен с крупными IXP, а не по публичному интернету – именно так удаётся сэкономить 30–50 мс по сравнению с маршрутом по умолчанию.

Второй бюджет – это буфер джиттера у зрителя, который WebRTC-стек динамически подстраивает в зависимости от потерь и переупорядочивания пакетов на последнем километре. На стабильном Wi-Fi буфер может опускаться до 30 мс; при нестабильной мобильной связи WebRTC-стек увеличит его до 80 мс или больше, чтобы избежать заморозки видео. Это жёсткий компромисс: каждые 10 мс буфера джиттера – это 10 мс дополнительной задержки, которую зритель уже не сможет компенсировать на последующих этапах.

Пути энкодера и декодера можно сократить, предоставив вещателю аппаратный энкодер (NVENC, QuickSync, VideoToolbox), но полностью устранить их нельзя. Задержка пересылки в SFU – это примерно время, необходимое для приёма UDP-пакета, обработки и переписывания RTP-заголовков, требуемых для каскада, и последующей отправки пакета наружу: современные SFU на bare metal работают на нижнем пределе диапазона 10–30 мс; SFU в загруженном Kubernetes-поде – на верхнем.

Сквозная задержка – от 275 до 510 мс в этом примере, в зависимости от условий. Для того же вещателя, доставляющего контент тому же зрителю через LL-HLS, сопоставимый бюджет – с учётом двухсекундного целевого буфера плеера – составляет от 1500 до 3000 мс. Путь доставки через WebRTC – от 3 до 10 раз быстрее по end-to-end. Именно за это и платят.

Стоимость – почему WebRTC-доставка – дорогой вариант

WebRTC-доставка обходится дороже HLS-доставки примерно в сто раз на один зритель-час. Это связано с тем, как два протокола используют серверные ресурсы, а не с ценообразованием вендора. Две конкретные цифры помогут объяснить этот разрыв.

Первая – серверный compute на зрителя. HLS edge, отдающий закешированные сегменты, фактически не тратит вычислительные ресурсы на зрителя, как только сегмент попал в кэш: edge выполняет ту же работу, что и HTTP-кэш, для чего HTTP-кэши и предназначены. SFU, обслуживающий WebRTC-зрителя, поддерживает DTLS-сессию, шифрует каждый исходящий RTP-пакет с помощью SRTP, обрабатывает RTCP-обратную связь, реализует контроль перегрузки и перенаправляет пакеты по каскаду. На одного одновременного зрителя на типичном SFU требуется около 1–3 mCPU непрерывно (из 1000 mCPU = одно полное ядро): одна машина с 32 ядрами способна обслуживать порядка 10–30 тысяч одновременных зрителей. Та же машина в роли HLS edge обслуживает миллионы.

Вторая – egress-полоса из приватной сети. HLS- или LL-HLS-edge передаёт байты из приватного edge CDN в last mile. Стоимость CDN на уровне wholesale определяется транзитом и пирингом – обычно $0.01–$0.05 за ГБ при объёмах, характерных для крупных стриминговых сервисов. Egress WebRTC SFU также отправляет данные в last mile, но поскольку SFU поддерживает real-time UDP-соединение с каждым зрителем через NAT, трафик проходит через инфраструктуру, рассчитанную на низкий джиттер и минимальные потери – это дороже: обычно $0.05–$0.15 за ГБ. Полоса, используемая для каскадирования между SFU, идёт по тому же приватному бэкбону, что и у CDN, поэтому эта часть не обходится дороже, чем у HLS.

Кумулятивный эффект на крупном live-событии – например, 100 000 зрителей одновременно в течение часа при средней скорости 1,5 Мбит/с на одного зрителя – выглядит следующим образом:

Путь LL-HLS:
  Всего байт:    100 000 × 1.5 Mbit/s × 3600 с / 8 = 67.5 TB
  Edge egress:   67.5 TB × $0.02/GB                 = $1 350
  Origin compute: пренебрежимо мал (cache hit > 99%)
                                                     -------
  Итого:                                              $1 350

Путь WebRTC-доставки:
  Всего байт:    67.5 TB                              то же
  Edge egress:   67.5 TB × $0.10/GB                 = $6 750
  SFU compute:   100 000 зрителей × 1 час × ~$0.0005/мин × 60 = $3 000
                                                     -------
  Итого:                                              $9 750

WebRTC-доставка обходится примерно в 7 раз дороже LL-HLS (LL-HLS) для той же аудитории при таком масштабе. Разница в стоимости растёт с увеличением числа зрителей, поскольку LL-HLS продолжает эффективно масштабироваться за счёт кэширования на edge, а вычислительные затраты WebRTC растут линейно. При этом при уменьшении аудитории разница сокращается: например, интерактивное шоу на 1000 зрителей может стоить около $100 в обоих случаях, и тогда преимущество WebRTC по задержке получается «бесплатно». Точка безубыточности в большинстве production-стеков – около 5000–10 000 одновременных зрителей: ниже этой отметки дополнительный расход на WebRTC оказывается невеликим, и его можно оправдать ради низкой задержки; выше – поставщики обычно комбинируют WebRTC (для интерактивного слоя) с LL-HLS или DASH (для трансляции массовой аудитории).

Гибридный стек – WebRTC для первого ряда, LL-HLS для задних рядов

Архитектурный паттерн, который предлагает любая серьёзная платформа доставки WebRTC в 2026 году, – это гибридный стек: WebRTC для интерактивного верхнего слоя аудитории и LL-HLS или DASH для broadcast-хвоста. Картинка примерно такая:

                        +-----------------+
                        |    Вещатель     |
                        +--------+--------+
                                 |  WHIP / RTMP
                                 v
                        +--------+--------+
                        |   Origin SFU    |
                        +--+---------+----+
                           |         |
              WebRTC RTP   |         |  RTP → декод → HLS pkg
                           v         v
              +------------+--+   +--+--------------+
              |  Каскад      |   | Мост WebRTC →    |
              |  SFU         |   | HLS              |
              +------+-------+   +-------+---------+
                     |                   |
            WebRTC + WHEP            LL-HLS + CDN
                     |                   |
                     v                   v
              [ 5K зрителей ]      [ 5M зрителей ]
              (200–500 мс)         (1.5–3 с)

Мост – сервер, который принимает RTP-поток WebRTC, один раз декодирует его, упаковывает в CMAF и отдаёт в формате HLS или DASH. При этом обработка происходит один раз на поток, а не на каждого зрителя. Затраты на «декодирование один раз» реальны – от 1,0 до 2,5 ядер CPU на рендеринг непрерывно, пока мост работает, – но далее масштабирование выхода обеспечивается HTTP-краевым кэшированием, как у любого LL-HLS-стриминга. Опыт зрителя зависит от выбранного слоя: те, кто использует режим «Интерактив» или активирует интерактивные функции – например, чат или поднятие руки, – подключаются к WebRTC-слою и платят за задержку менее 500 мс повышенными затратами на инфраструктуру. Зрители в broadcast-хвосте получают LL-HLS-стрим значительно дешевле на одного пользователя при задержке 2–3 секунды, что вполне достаточно для комфортного просмотра шоу.

Именно такую архитектуру предлагают Cloudflare Stream, AWS IVS Real-Time + IVS Channel, LiveKit (через свой multistreaming в RTMP) и Dolby OptiView. Граница между слоями – продуктовая, а не инженерная: каждая вендорская поверхность позволяет определить, в какой слой попадёт конкретный зритель – часто на основе того, кликнул ли он по элементу, требующему интерактива.

Чего WebRTC-доставка не делает хорошо

Три известных ограничения делают WebRTC-доставку неподходящим инструментом для некоторых задач, даже если преимущество по задержке выглядит привлекательным.

Покрытие Smart TV и set-top box неравномерное. Браузеры и мобильные платформы (iOS и Android) поддерживают WebRTC нативно. Однако ситуация с Smart TV в 2026 году остаётся пятнистой: Samsung Tizen, LG webOS и Vidaa включают WebRTC-стек во встроенных браузерах, но их реализации отстают от Chrome на 2–3 года и зачастую не поддерживают кодековые профили, используемые SFU. У Roku на базе BrightScript WebRTC-стек отсутствует полностью. Нативный плеер Apple TV также не работает с WebRTC – требуется кастомное приложение для tvOS, использующее WebKit-WKWebView или сторонний WebRTC SDK. Если аудитория в основном использует Smart TV и set-top box, доставка через WebRTC оказывается значительно сложнее, чем LL-HLS, который поддерживается на всех Smart TV без исключений.

DRM – тяжёлая проблема. Common Encryption с cbcs – стандартный режим DRM для HLS и DASH (мы подробно разбирали его в статье про CMAF и в статье про Common Encryption). У WebRTC нет нативного аналога: SRTP-шифрование защищает медиа в транзите между SFU и WebRTC-стеком зрителя, но как только стек передаёт кадр рендереру, байты остаются расшифрованными в памяти браузера и становятся доступны решительному атакующему. Вендоры, которым нужен DRM-эквивалент для доставки через WebRTC, либо вынуждены перешифровывать данные на уровне приложения (что требует поддержки со стороны плеера и не является стандартом), либо признают, что протокол не предназначен для таких задач. Большинство production-развёртываний WebRTC используются для передачи пользовательского или интерактивного контента, а не премиальных лицензированных каталогов.

Субтитры, мультиаудио и trick play слабые. У HLS и DASH зрелый стек для рендеринга субтитров (WebVTT, IMSC), нескольких аудиоверсий (Dolby Atmos, мультиязык) и trick-игры (seek, скраб, DVR). Модель WebRTC по своей сути реалтаймовая: нет манифеста, чтобы перечислить альтернативы, отсутствует сегментная структура, в которую можно было бы перейти при seek, и нет спецификации для кадров субтитров. Вендоры решают эти проблемы с помощью кастомных data-каналов для стриминга субтитров, которые плеер должен обрабатывать вне основного потока (out-of-band), а также используют несколько RTP-аудиопотоков в одной WebRTC-сессии для мультиаудио – работает, но требует много усилий. Если продукту нужна broadcast-уровневая доступность и полноценный плеерский опыт, LL-HLS или DASH – более экономичный выбор с точки зрения инженерии.

Полное сравнение по пунктам – в статье про матрицу протоколов; кратко: доставка через WebRTC специально разработана для сценариев с интерактивностью менее секунды и стабильно неправильный выбор для всего остального.

Нажмите, чтобы увеличить

Короткий тур по вендорам 2026

Платформы, предоставляющие WebRTC-доставку в 2026 году, делятся на три группы.

Облачные платформы. Cloudflare Stream, AWS IVS Real-Time (Stages) и Mux Live – каждая из них предоставляет управляемую доставку по WebRTC с поддержкой WHIP-ингеста, WHEP-эгерега и гибридного хвоста на основе LL-HLS. Ключевое преимущество Cloudflare – самый масштабный edge-футпринт (более 300 городов, точки присутствия в пределах 50 мс от 95% интернет-пользователей мира), а также Workers и Durable Objects для реализации логики маршрутизации, что обеспечивает агрессивно низкую задержку – менее секунды в браузере. AWS IVS Real-Time использует технологический стек, унаследованный от Twitch, и делает акцент на интерактивных Stages с поддержкой до 12 ведущих и более чем 25 000 одновременных зрителей на одном стейдже. Mux Live делает ставку на удобство для разработчиков и по умолчанию использует открытые стандарты (WHIP / WHEP).

Специализированные real-time-платформы. Dolby OptiView Real-time Streaming (бывший Millicast / Dolby.io) – старейший pure-play-сервис доставки через WebRTC, заявляющий задержку 500 мс при аудитории свыше 60 000 зрителей. LiveKit – ведущая open-source-платформа с горизонтально масштабируемым SFU-решением и возможностью поддержки миллионов зрителей в LiveKit Cloud. И Dolby, и LiveKit активно публикуют технический контент, раскрывающий устройство своих каскадных SFU-стеков.

Self-hosted стеки. Ant Media Server, OvenMediaEngine, Janus Gateway, mediasoup, Pion и более старый Jitsi Videobridge – все они позволяют командам развернуть собственный SFU. Цена такого выбора – ответственность оператора за каскад, NAT-Traversal, настройку TURN, мониторинг и масштабирование: это реальные инженерные вложения, но правильный путь для тех, кому нужны data-residency, соответствие требованиям комплаенса или контроль над затратами – то, чего не дают управляемые сервисы.

Граница между группами нечёткая – LiveKit Cloud представляет собой управляемое решение на базе открытого стека, Cloudflare Stream использует компоненты, напоминающие открытый SFU, но с проприетарной маршрутизацией, а Ant Media предлагает как самохостируемые, так и облачные версии. При выборе архитектуры важнее не название вендора, а ответы на короткий список вопросов: действительно ли нужна задержка менее секунды или достаточно 2–3 секунд? Сколько зрителей будет одновременно в пике? Требуется ли защита контента (DRM)? Необходимо ли поддержка Smart TV? Готова ли команда управлять WebRTC-инфраструктурой или предпочитает управляемый сервис? Эти ответы помогут определить подходящую группу решений быстрее, чем за час.

Распространённые ошибки (список «хотели бы знать заранее»)

Относиться к WebRTC как к CDN. Самая большая ошибка – воспринимать WebRTC SFU как CDN-EDGE: планировать ресурсы исходя из «число зрителей × средний битрейт», а не «число зрителей × нагрузка на CPU на одно соединение». Трансляция на 100 тысяч зрителей в формате LL-HLS размещается на edge-кэше при почти нулевой вычислительной нагрузке. То же самое событие на 100 тысяч зрителей через WebRTC требует 3–10 активно работающих SFU-машин – и это не только нагрузка на пропускную способность. Команды, проектирующие архитектуру, будто SFU – это кэш, сталкиваются с резким ростом расходов в счёте.

Считать, что вещатель сможет делать simulcast. Simulcast увеличивает нагрузку на кодирование у паблишера. Средний ноутбук, кодирующий 1080p H.264 с помощью софтверного энкодера, справляется с одной рендицией; если попросить три simulcast-рендации – CPU будет загружен на пределе, а fps упадёт до единиц. Доставка в production через WebRTC либо использует simulcast на аппаратном энкодере вещателя (например, NVENC на десктопе или аппаратную capture-карту), либо применяет SVC на AV1 (это один поток и легче для паблишера), либо разделяет рендации на сервере – тогда нагрузка на CPU ложится на SFU, а не на вещателя.

Пропустить TURN. UDP-приоритетный дизайн WebRTC отлично работает, пока зритель не попадает в корпоративную сеть, полностью блокирующую UDP. Без настроенного TURN-ретранслятора такие зрители не могут подключиться и получают бесполезное сообщение об ошибке. Любому production-стеку необходим подготовленный TURN-сервер, мощность которого соответствует доле пользователей, попадающих в fallback (обычно 10–20% корпоративных, 1–3% обычных), и отдельный мониторинг. Полоса пропускания через TURN также дороже прямой WebRTC-полосы, поскольку трафик идёт через egress TURN-сервера, а не через SFU – это нужно учитывать при планировании бюджета. Полная механика описана в статье про NAT, STUN, TURN, ICE.

Выбирать кодеки, которые SFU не маршрутизирует. Не все SFU поддерживают все кодеки. Большинство SFU по умолчанию работают с H.264 baseline и main, а также VP8; H.265 / HEVC редко встречается в WebRTC SFU из-за патентных ограничений; AV1 поддерживается в современных SFU (LiveKit, mediasoup с 2024, Cloudflare Stream), но пока не везде. Если браузер зрителя поддерживает кодек, а SFU не может его маршрутизировать, SFU отклоняет весь поток. Перед релизом обязательно тестируйте матрицу «кодек × рендиция» end-to-end.

Недооценить работу плеера. Плеер WebRTC-доставки – не drop-in-замена HLS-плееру. Он должен поддерживать WHEP, обрабатывать обмен SDP, управлять ICE-кандидатами, восстанавливаться от сетевых перебоев в реальном времени (а не просто «буферизовать и повторить», как это делает HLS-плеер) и рендерить кадры сразу по их поступлению, а не после заполнения буфера. Команда, специализирующаяся только на HLS-плеерах, недооценивает объём этой работы в 2–3 раза. Самый чистый подход в 2026 году – использовать вендорский SDK (например, LiveKit, Cloudflare Stream WebRTC SDK, Dolby OptiView SDK) для WebRTC-слоя и интегрировать его с остальной частью UI плеера, а не строить всё с нуля от уровня RTCPeerConnection.

Где здесь Фора Софт

Фора Софт поставляет WebRTC-решения в реальном времени с 2011 года – во всех пяти отраслях, где задержка менее секунды действительно меняет продукт: видеоконференции (изначальный сценарий WebRTC), прямые трансляции с интерактивными элементами (шоу, аукционы, live shopping), телемедицина (приём врача и пациента, где задержка должна ощущаться как телефонный разговор), e-learning (живые занятия с возможностью поднять руку и использовать общую доску) и видеонаблюдение (управление оператор-камера, где каждая секунда задержки – это упущенное событие). Мы работали с mediasoup, LiveKit, Janus и собственными проприетарными SFU в разных проектах; реализовывали WHIP- и WHEP-эндпоинты; строили мост WebRTC→LL-HLS для production-стеков. Архитектурные решения, описанные в этой статье, – те самые, которые мы обсуждаем на скоупинг-звонках каждую неделю.

Ключевые выводы

• WebRTC-доставка обеспечивает задержку glass-to-glass 200–500 мс – в 3–10 раз быстрее, чем LL-HLS, – но обходится примерно в 7 раз дороже на зритель-час при масштабировании.
• Selective Forwarding Unit (SFU) – единственная топология, способная масштабировать WebRTC за пределы нескольких зрителей; она пересылает RTP-пакеты без декодирования, добавляя задержку 20–80 мс на каждый хоп.
• Simulcast передаёт несколько версий потока от паблишера, а SVC – один многоуровневый поток; обе технологии позволяют SFU обслуживать зрителей с разным качеством без перекодирования.
• Каскад SFU между регионами позволяет масштабировать WebRTC-доставку с тысяч до миллионов зрителей; при этом дерево из трёх хопов добавляет задержку 60–240 мс.
• WHIP (RFC 9725, март 2025) и WHEP (draft-ietf-wish-whep-03, март 2026) – стандартизированные протоколы сигнализации, наконец обеспечивающие переносимость WebRTC-плееров между вендорами.
• Производственный паттерн 2026 года – гибридный: WebRTC используется для интерактивной части, а LL-HLS или DASH – для broadcast-хвоста, при этом между ними работает мост с декодированием один раз.

Что читать дальше

• WebRTC без эзотерики – первые принципы без жаргона.
• SFU vs MCU vs Mesh – три топологии WebRTC – когда какая топология окупается.
• Выбор протокола доставки в 2026: дерево решений – BOFU-статья, сопоставляющая продуктовые ограничения с выбором протокола.