Доставка через 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-whep-03 (март 2026), W3C webrtc Candidate Recommendation Snapshot 2024-11-26, Apple HLS Authoring Specification revision 2025-09 (для секции про гибридный стек), документацией Cloudflare Stream WebRTC, документацией Dolby OptiView Real-time Streaming, гайдом разработчика AWS IVS Real-Time Streaming, инженерным постом LiveKit "globally distributed mesh network" (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. Спустя пятнадцать лет streaming-индустрия растянула тот же протокол до доставки одного потока миллионам зрителей с задержкой 200–500 мс glass-to-glass, маршрутизируя его через дерево Selective Forwarding Unit (SFU) – медиа-серверов, которые принимают один WebRTC-поток от вещателя и отдают его отдельным WebRTC-потоком каждому подписавшемуся зрителю. Архитектура работает, но не ведёт себя как HLS или DASH: каждый зритель – это реальный WebRTC-пир со своей DTLS-сессией, своим набором ICE-кандидатов и своим серверным compute-следом, поэтому бэкенд платит за зрителя, а не за гигабайт в кэше. Эта статья проходит через то, как WebRTC из 1:1-протокола звонков превратился в протокол one-to-many-доставки, почему любой современный вендор WebRTC-доставки (Cloudflare Stream, Dolby OptiView, LiveKit, AWS IVS Real-Time, Mux Live, Ant Media) поставляет одну и ту же схему каскадных SFU, сколько это стоит и где проходит граница с 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 как способ обмена аудио, видео и данными между двумя браузерами напрямую через публичный интернет с минимальной задержкой. IETF опубликовала первый стабильный зонтичный документ – RFC 8825 – Overview: Real-Time Protocols for Browser-Based Applications – в феврале 2021, вместе с остальным семейством RFC 8826–8866, которое прибивает к месту модель безопасности (RFC 8826), транспорт (RFC 8835), data channels (RFC 8831), congestion control (RFC 8888) и использование SDP (RFC 8839). W3C-спецификация JavaScript-API webrtc достигла статуса Candidate Recommendation в 2021 и в последний раз была обновлена как Candidate Recommendation Snapshot 26 ноября 2024.

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

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

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

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

Mesh

Первая топология – mesh: каждый участник сессии открывает прямое WebRTC-соединение с каждым другим участником. При N участниках сеть несёт N × (N−1) соединений; каждый паблишер загружает N−1 копий своего собственного потока; каждый зритель скачивает N−1 потоков. Mesh даёт самую низкую задержку из всех топологий (один сетевой хоп, никакой обработки в медиа-сервере посередине) и самую низкую стоимость серверов (медиа-сервера нет вообще – только сигналлинг и fallback на TURN). И она же рассыпается после 4–6 участников: uplink каждого участника плавится под нагрузкой загрузки, а 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 fps стоит порядка 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-buffer и своя петля congestion-control. SFU тратит CPU и память на каждого. Это форма стоимости, к которой мы ещё несколько раз вернёмся в этой статье.

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

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

Simulcast

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

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

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

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

SVC – Scalable Video Coding

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

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

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

Каскад SFU – как WebRTC дотягивается до миллиона зрителей

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

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

В каскаде две инженерные тонкости, которые вендоры решают по-разному. Первая – кто кого тянет: любое каскадное развёртывание должно определить, как листовой SFU находит родителя (чтобы запросить поток), и как корневой SFU знает обо всех детях (чтобы не overprovision-ить). Опубликованная архитектура LiveKit использует mesh SFU c 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-endpoint.

WHEP – причина, по которой плеер WebRTC-доставки в 2026 может переключаться между бэкендами почти так же легко, как HLS-плеер переключается между origin-ами. Один open-source-плеер (WHEP-совместимые куски hls.js, SDK RoomConnection LiveKit в WHEP-режиме, OvenPlayer, WebRTC-режим THEOplayer) может играть из любого conformant 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 мс с того же пути по сравнению с маршрутом по умолчанию.

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

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

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

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

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

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

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

Кумулятивный эффект на представительном live-событии – скажем, 100 000 одновременных зрителей в течение 1 часа в среднем по 1.5 Mbps на зрителя – выглядит так:

Путь 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 продолжает масштабироваться на edge-кэшировании, а WebRTC-compute масштабируется линейно; и улучшается с уменьшением аудитории (1000-зрительский интерактивный шоу может стоить $100 в обоих случаях, и тогда выигрыш в задержке WebRTC получается бесплатно). Точка безубыточности в большинстве production-стеков – около 5000–10 000 одновременных зрителей: ниже – штраф WebRTC по стоимости достаточно мал, чтобы платить его ради латентности; выше – вендоры обычно смешивают WebRTC (для интерактивного слоя) с LL-HLS или DASH (для broadcast-хвоста).

Гибридный стек – 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-edge-кэшированием как любой 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 неравномерное. Браузеры держат WebRTC нативно. iOS и Android – нативно. Реальность 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, 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-play (seek, скраб, DVR). Модель WebRTC по проекту реалтаймовая: нет манифеста, чтобы перечислить альтернативы, нет сегментной структуры, в которую можно сикать, нет спеки для кадров субтитров. Вендоры лечат это кастомными data-channel-стримами для субтитров, которые плеер должен обрабатывать out-of-band, и лечат проблему мультиаудио несколькими RTP-аудио-потоками в одной WebRTC-сессии – работает, но возни много. Если продукту нужна broadcast-grade-доступность и фичевый плеерский опыт, LL-HLS или DASH – дешевле по инженерии.

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

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

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

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

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

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

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

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

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

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

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

Пропустить TURN. UDP-first дизайн 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-кандидатами, восстанавливаться от сетевых перебоев в реальном времени (не просто "buffer and retry" как HLS-плеер) и рендерить кадры в момент их прибытия, а не после заполнения буфера. Команда, поставлявшая только HLS-плееры, недооценивает эту работу в 2–3 раза. Самый чистый паттерн в 2026 – взять вендорский SDK (LiveKit, Cloudflare Stream WebRTC SDK, Dolby OptiView SDK) для WebRTC-слоя и интегрировать его с остальным UI плеера, а не строить с уровня RTCPeerConnection снизу вверх.

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

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

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

• WebRTC-доставка даёт 200–500 мс glass-to-glass – в 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-плееры портативными между вендорами.
• Production-паттерн 2026 – гибрид: WebRTC для интерактивного верха, LL-HLS или DASH для broadcast-хвоста, с decode-once-мостом между ними.

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

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