WebRTC vs HLS в 2026: какой стриминговый протокол выбрать для приложения (задержка, стоимость, масштаб)

Почему Фора Софт написала это руководство

За последние пять лет мы выпустили два десятка видеостриминговых платформ. Worldcast Live, наша HD-платформа для трансляции концертов, тянет 10 000 одновременных зрителей с задержкой меньше секунды (0,4–0,5 с glass-to-glass) на гибридной архитектуре WebRTC-SFU → LL-HLS. Sprii, приложение для live-шопинга, масштабируется до 50 тыс. одновременных зрителей по LL-HLS с задержкой 3 с. Ariuum использует WebRTC для интерактивных дебатов с задержкой меньше секунды и 500 одновременными спикерами, плюс резервный HLS для масштаба.

Это руководство по-новому ставит вопрос «WebRTC или HLS». Настоящий ответ — не «выберите один». Настоящий ответ: «поймите свою целевую задержку, потолок одновременных зрителей и допустимый бюджет». А дальше — собирайте гибрид или берите один протокол, который подходит. Мы проведём вас по бенчмаркам, архитектурным ловушкам и фреймворку принятия решения, которым пользуемся сами.

WebRTC vs HLS в 2026 — коротко о главном

Берите WebRTC (с медиасервером вроде mediasoup или Janus), если нужна задержка меньше секунды, а аудитория небольшая — до 500 одновременных зрителей. Это интерактивные игры, live-аукционы, торги в реальном времени, панельные дебаты, где важна задержка между спикерами.

Берите HLS или LL-HLS, если нужен массовый масштаб и допустима задержка 2–30 секунд. Это вещание на 10 тыс.+ одновременных зрителей в рамках разумного бюджета: live-спорт, презентации продуктов, образовательные стримы, ленты live-шопинга.

Берите гибрид (WebRTC для спикеров + LL-HLS/HLS для зрителей), если нужно и то и другое. Именно так работают Worldcast Live, Sprii и Ariuum. Спикеры получают RTT меньше секунды между собой; зрители получают стабильный поток с задержкой 2–5 с и без перегрузки SFU по памяти. В 2026 большинство современных live-платформ выпускаются именно так.

Что такое задержка на самом деле — glass-to-glass и RTT

Вы наверняка слышали «WebRTC быстрее» и «у HLS задержка 6 секунд». Эти утверждения мешают в одну кучу три разных типа задержки, и путаница ломает решения.

Glass-to-glass (G2G)

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

Round-trip time (RTT)

Один пользователь отправляет сообщение, второй получает и отвечает, первый получает ответ. Это задержка между пользователями, а не от источника к зрителю. Здесь WebRTC блистает: два спикера на одном SFU могут уложиться в RTT 50–200 мс. Зритель HLS в принципе не отправляет данные обратно вещателю в реальном времени; HLS — это одностороннее вещание.

Сквозная (E2E) или стриминговая задержка

Сколько проходит времени между тем, как вещатель начал говорить, и тем, как зритель его услышал. Именно это рекламируют как «LL-HLS даёт задержку 2 секунды». То же самое называют «воспринимаемой задержкой» или «стриминговой задержкой». Критично для live-событий, менее критично для односторонних трансляций.

Как устроен WebRTC — почему задержка меньше секунды

WebRTC передаёт сырые медиапакеты (кадры аудио и видео) peer-to-peer или через Selective Forwarding Unit (SFU, медиарелей). Никакого кодирования в сегменты HLS. Никакого разбиения на чанки. Никакой стратегии буферизации с ожиданием границы сегмента. Кадры пришли — мгновенно декодируются и отрисовываются.

Архитектура SFU (стандарт для live-сценариев с многими пользователями)

Каждый спикер передаёт видеопоток (обычно 720p или 1080p, 30 fps, 2–5 Мбит/с). Сервер SFU (mediasoup, Janus, Pion) принимает поток, перекодирует его в несколько битрейтов (simulcast: 720p, 360p, 144p) и отдаёт каждому зрителю нужный битрейт под его канал. Каждый зритель держит только одно WebRTC-соединение с SFU и забирает по нему несколько потоков, если нужно.

Почему это быстро. Пакеты идут непрерывно. Не нужно ждать границы сегмента. Доминирует задержка кодека (кодирование VP8/H.264 добавляет ~30–50 мс). Сетевая задержка по своей природе небольшая (типичная связь дата-центр — клиент: 20–100 мс). Согласование ICE (поиск кратчайшего сетевого пути) добавляет 1–3 секунды на старте, но после этого RTT стабилен.

Почему это ломается на масштабе. У инстанса SFU есть потолок по CPU. Один процесс mediasoup на 16-ядерной машине (Hetzner серии AX или аналог) тянет примерно 100–300 одновременных зрителей в зависимости от кодека, битрейта и использования simulcast. Дальше — поднимаете ещё один SFU и каскадируете. Каскадирование добавляет задержку (прыжки пакетов) и сложность (согласование ICE между SFU).

Как устроен HLS — почему он масштабируется за счёт сегментной буферизации

HTTP Live Streaming (HLS) берёт live-поток, режет его на сегменты по 2–10 секунд (MPEG-TS или fMP4) и отдаёт их как плейлист. Плеер зрителя читает плейлист, скачивает сегменты по порядку, буферизует 2–3 штуки и проигрывает последовательно. Просто, кэшируется и масштабируется до миллионов одновременных зрителей через обычный CDN.

Классический HLS (задержка 6–30 с)

10-секундный сегмент собирается 10 секунд (энкодер буферизует 10 секунд видео), затем сервер публикует его и обновляет плейлист. Клиент скачивает, буферизует 2–3 сегмента (20–30 секунд) и начинает играть. Сквозная задержка обычно 20–40 секунд. Для записанного контента или неспешных трансляций это нормально.

LL-HLS (Low-Latency HLS, задержка 2–6 с) — стандарт 2026

Apple представила LL-HLS (RFC 8216), чтобы уменьшить задержку без изобретения велосипеда. Вместо ожидания целого 10-секундного сегмента энкодер выпускает частичный сегмент каждые 200–500 мс. Клиент через HTTP/2 server push или HTTP/1.1 trailers получает каждый частичный сегмент в реальном времени. В связке с контейнером CMAF (Common Media Application Format) для более быстрого чанкинга LL-HLS даёт задержку 2–6 секунд на стандартных CDN.

Почему LL-HLS выигрывает в 2026. Работает на любом CDN, поддерживающем HTTP/2 server push (Cloudflare, Akamai, AWS CloudFront, Fastly). Никакого специализированного железа под SFU. Масштабируется до 100 тыс. одновременных зрителей при цене egress ~0,06 ₽/ГБ. Если клиент не умеет server push, автоматически откатывается на классический HLS.

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

Бенчмарки задержки — что вы получите на практике

Эти цифры — из наших бенчмарков 2026 года (продакшен-запуски Worldcast, Sprii, Ariuum) плюс документация вендоров. Цифры рассчитаны на приличные сетевые условия (без обрывов Wi-Fi, доступная полоса >5 Мбит/с).

Практическое замечание. На Worldcast Live мы получили 0,4–0,5 с glass-to-glass на собственном стеке WebRTC (mediasoup SFU + оптимизированные энкодеры на Hetzner). Нижняя граница 0,2 с предполагает лабораторные условия. На Sprii LL-HLS дал воспринимаемую задержку 3 с с размером сегмента 1 секунда (баланс между временем старта и пропускной способностью). CMAF-LL — это спецификация; LL-HLS — то, что вы получите на iOS и Safari.

Стоимость на одного зрителя при масштабе — где живёт математика

Стоимость на зрителя определяется либо полосой (egress для HLS/LL-HLS), либо часами SFU-вычислений (WebRTC). Вот точка, где они пересекаются.

HLS/LL-HLS: платите за полосу через CDN

1080p-поток с битрейтом 5 Мбит/с тянет ~2,25 ГБ в час. Egress CDN стоит 0,06–0,37 ₽ за ГБ в зависимости от региона и объёма. Для 10 000 одновременных зрителей в течение 1 часа:

• Суммарный трафик: 10 000 зрителей × 2,25 ГБ = 22 500 ГБ
• По 0,07 ₽/ГБ (Cloudflare, средний объём): 1 687 ₽/час = 40 500 ₽/день
• По 0,22 ₽/ГБ (AWS CloudFront, стандартная ставка): 5 062 ₽/час = 121 500 ₽/день
• Стоимость на зрителя в час: 0,15–0,52 ₽

WebRTC: платите за вычисления SFU

SFU на mediasoup на 16-ядерном сервере Hetzner серии AX (~11 250 ₽/мес) тянет 150–300 одновременных зрителей в зависимости от кодека и битрейта. Для 10 000 одновременных зрителей:

• Сколько нужно инстансов SFU: 10 000 ÷ 200 (середина диапазона) = 50 инстансов
• Стоимость: 50 × 11 250 ₽/мес = 562 тыс. ₽/мес
• Стоимость на зрителя в месяц: 56 ₽ за зрителя
• Стоимость на зрителя в час (при 8-часовом событии): 6,7 ₽ за зрителя

Точка пересечения. Для часового события на 10 000 зрителей LL-HLS стоит 1 650–5 025 ₽, WebRTC — около 33 750 ₽. HLS выигрывает в 10 раз. Но если вам нужна задержка меньше секунды или RTT между спикерами, выбора, кроме WebRTC, нет.

Охват и поддержка устройств — браузеры, ТВ, бюджетные Android

WebRTC. Нужен браузер с поддержкой WebRTC. Поддерживается в Chrome, Firefox, Safari (11+), Edge. Не поддерживается в Opera Mini, старых Android-браузерах (ниже 5.0), многих смарт-ТВ. Если нужна поддержка Roku, Apple TV или Xbox, придётся добавить HLS как запасной вариант. WebRTC по своей природе требователен к полосе (нет традиционной битрейт-лестницы на уровне протокола; адаптивный битрейт реализуете в приложении).

HLS. Работает везде: Safari (iOS/macOS), Chrome (через HLS.js), Firefox (через Shaka), нативный Android, Roku, Apple TV, старые кнопочные телефоны (это просто HTTP GET + декодирование MPEG-TS). У HLS встроена битрейт-лестница для адаптивного вещания: сервер публикует несколько вариантов битрейта (1080p, 720p, 360p, 144p), и клиент выбирает лучший под доступную полосу.

LL-HLS. Нативно на Safari 13+ (iOS 13+), на других браузерах требует HLS.js или Shaka. Поддержка на смарт-ТВ неоднородная: Apple TV — да, Roku пока нет (по состоянию на 1 квартал 2026), но ситуация улучшается. Если нужна 100% охват устройств, добавьте откат на классический HLS.

Сравнительная матрица — все параметры одним взглядом

Гибридная схема — спикеры через WebRTC, зрители через HLS/LL-HLS

Это архитектура, победившая в 2026. Под группу спикеров (обычно 5–50 человек) поднимаете WebRTC SFU. Каждый спикер передаёт в SFU поток в полном качестве. SFU кодирует один мастер-поток высокого качества (1080p, 5 Мбит/с) и отдаёт его в энкодер, который пакует его в LL-HLS-сегменты. Зрители забирают LL-HLS-поток из CDN.

Почему это работает

Спикеры получают RTT меньше секунды между собой (WebRTC). Зрители получают стабильное буферизованное видео (LL-HLS) без перегрузки SFU. SFU крутится на одной машине или небольшом кластере. Конвейер кодирования (мастер-выход SFU → энкодер → сегментер HLS) не зависит от числа зрителей.

Реальные цифры: Worldcast Live

Worldcast Live, HD-платформа концертов на 10 тыс. одновременных зрителей, которую мы построили, работает ровно по этой схеме. Кластер из 4 машин mediasoup тянет 50 спикеров с RTT 0,1 с между ними. Каждый спикер передаёт 1080p 30 fps (4,5 Мбит/с). SFU кодирует один мастер-выход 1080p 30 fps 5 Мбит/с, отдаёт его в FFmpeg-перекодировщик на Hetzner, который сегментирует в LL-HLS с размером сегмента 1 с. Зрители видят задержку 0,4–0,5 с glass-to-glass. Суммарная стоимость: 60 000 ₽/мес (кластер SFU) + 1 875 ₽/мес (энкодер) + 1 500 ₽ за egress для 4-часового концерта на 10 тыс. зрителей. Это 0,06 ₽ за зрителя-час, против 6 750 ₽ для подхода на чистом WebRTC.

Чек-лист реализации

• Энкодер (FFmpeg или аналог) забирает мастер-выход SFU через rtmp:// или собственный сокет.
• Энкодер перекодирует (обычно просто перемультиплексирует, если кодек на выходе SFU совпадает с целевым) и режет в LL-HLS (сегменты 1–2 с).
• Сегменты складываются в S3-бакет или локальную директорию; синхронизируются на CDN (Cloudflare, Fastly, AWS CloudFront).
• Плейлист (index.m3u8) обновляется каждые 200–500 мс (обновления частичных сегментов в LL-HLS).
• Откат на классический HLS, если плеер не поддерживает LL-HLS (автоматически в большинстве современных плееров).

Архитектурные подводные камни WebRTC при масштабировании

1. Стена по CPU у SFU на 300 зрителях. Один инстанс mediasoup на 16-ядерной машине с кодеком VP8 упирается в потолок CPU примерно на 300 одновременных зрителей. Дальше — поднимаете ещё один SFU. Но каскадирование SFU (пересылка между SFU) добавляет задержку: каждый прыжок добавляет 20–50 мс, а повторное согласование ICE между SFU занимает 2–4 секунды. Простой обходной путь — simulcast (каждый спикер отправляет несколько вариантов битрейта). SFU пересылает только нужный битрейт каждому зрителю вниз по потоку, снижая нагрузку на энкодер. Цена — выше восходящая полоса на спикера, но потолок можно поднять до 500–600 зрителей на один SFU.

2. Сбои ICE на уровне 10–15%. Interactive Connectivity Establishment (ICE) в WebRTC ищет кратчайший путь между пирами. В продакшене 10–15% согласований ICE падают (firewall блокирует peer-to-peer, таймауты STUN, перегрузка TURN). Приложение должно обрабатывать это аккуратно: либо откатиться на TURN (релей через сервер, добавляет 50–200 мс задержки), либо разорвать соединение и переподключиться. Worldcast Live держит долю обрывов в середине звонка 3–5% несмотря на тюнинг ICE; для потребительских сетей это норма.

3. Непредсказуемая полоса на сотовых сетях. WebRTC адаптируется к доступной полосе, но мобильные сети меняют пропускную способность очень быстро. Спикер на 4G LTE может передавать 5 Мбит/с, потом сеть проседает до 1 Мбит/с. Энкодер SFU не успевает; зрители видят рывки. Лечится тем, что заранее кодируем simulcast в 2–3 уровня битрейта (5 Мбит/с, 2 Мбит/с, 500 кбит/с) и даём зрителям выбирать. Это требует более широкого восходящего канала от спикеров, но гарантирует стабильное воспроизведение для зрителей.

4. Раздувание памяти SFU на больших группах спикеров. Каждое WebRTC-соединение съедает ~100–200 МБ ОЗУ (видеобуферы, состояние кодека, отслеживание ICE-кандидатов). На 50 спикерах + 500 зрителях получаете ~60 ГБ ОЗУ по инстансам SFU. Это дорого и медленно масштабируется. Смягчение — каскадировать инстансы SFU деревом (SFU спикеров, релейные SFU спикеры–зрители), но с принятием задержки. Или брать управляемый сервис вроде Agora (но платить поминутно, что на 10 тыс. зрителей становится дорого).

5. Несовпадение кодеков между браузерами. Chrome предпочитает VP8, Safari — H.264. На едином SFU придётся перекодировать каждый поток в кодек, который понимают обе стороны. Перекодирование VP8 добавляет 20–50 мс на каждое перекодирование; аппаратное кодирование H.264 (на GPU Nvidia) помогает, но добавляет стоимости. Подход Worldcast Live: спикеры заранее указывают кодек (H.264 или VP8), и мы запускаем отдельные пути кодирования. Чуть больше накладных расходов — зато никаких сюрпризов.

Архитектурные подводные камни HLS — размер сегмента и кэш CDN

1. Размер сегмента — компромисс между задержкой и пропускной способностью. Меньшие сегменты (1 с) уменьшают задержку, но увеличивают накладные расходы на HTTP-запросы (больше запросов, больше TCP-рукопожатий, больше попаданий в edge-узлы CDN). Большие сегменты (10 с) снижают накладные расходы, но фиксируют задержку на 15–40 с. Для LL-HLS стандарт — размер сегмента 1–2 с. Но на перегруженных сотовых сетях 1-секундный сегмент может не успеть загрузиться до того, как готов следующий, и плеер начинает буферизоваться. Лечится адаптивным размером сегмента (CMAF-LL с дробными сегментами, которые динамически меняют размер) или предсказательным предвыборочным буферированием (плеер читает наперёд и буферизует 3 сегмента).

2. Промахи кэша CDN на старте стрима. У нового стрима в edge-кэше CDN ещё нет сегментов. Первые запросы сегментов идут в origin, и это добавляет 200–500 мс на запрос. Sprii решает это предварительным прогревом CDN: за 30 секунд до старта эфира origin пушит первые сегменты в edge-узлы. Это стоит ~375–1 500 ₽ на стрим (CDN purge + push), зато убирает задержку старта.

3. Настройка лестницы ABR — дело эмпирическое. Лестница адаптивного битрейта обычно состоит из 5–8 уровней (1080p на 5 Мбит/с, 720p на 2,5 Мбит/с, 480p на 1,5 Мбит/с, 360p на 600 кбит/с, 240p на 300 кбит/с). Но правильная лестница зависит от распределения полос у вашей аудитории. Соберите неделю аналитики, замерьте битрейт против частоты буферизации и подкрутите. Неправильно настроенная лестница (слишком много высокобитрейтных уровней для аудитории с низкой полосой) приводит к буферизации и оттоку.

4. Устаревание плейлиста в live-сценариях. HLS-плейлист нужно обновлять часто (на каждый сегмент). Но если обновлять слишком часто без правильных HTTP-заголовков кэширования, можно перегрузить origin. Поставьте `Cache-Control: max-age=2s` на плейлист, чтобы edge-узлы кэшировали его и какое-то время отдавали слегка устаревший. Плеер всё равно перезапросит плейлист, если дойдёт до его конца, поэтому устаревшие данные не ломают воспроизведение — будет лишь несколько секунд дублирующих запросов.

5. Запись HLS требует подцепления сегментов, а не выкачивания из CDN. Просто забрать HLS-плейлист и сегменты с CDN для записи не получится: origin может удалить старые сегменты раньше, чем вы их скачаете. Вместо этого подцепляйте сегменты на origin или на энкодер-сервере (до распространения по CDN) и пишите напрямую в объектное хранилище (S3 или аналог). Если хотите VOD из live-HLS-стрима, либо записывайте исходный фид напрямую, либо ставьте сервис архивации сегментов, который сохраняет их по мере создания.

Фрагменты кода и конфигов — настройка LL-HLS и подключение по WebRTC

Генерация LL-HLS-сегментов (конфиг FFmpeg)

Эта команда берёт входной RTMP-поток (от вашего SFU или энкодера) и выдаёт LL-HLS-сегменты:

ffmpeg -i rtmp://localhost/live/main \
  -c:v libx264 -preset veryfast -b:v 5M -maxrate 5.5M -bufsize 11M \
  -c:a aac -b:a 128k \
  -f hls \
  -hls_time 1 \
  -hls_list_size 6 \
  -hls_flags delete_segments+independent_segments \
  -hls_segment_type fmp4 \
  /var/www/html/live/stream.m3u8

Ключевые флаги. -hls_time 1 создаёт 1-секундные сегменты. -hls_segment_type fmp4 использует контейнер fMP4 (обязателен для LL-HLS на iOS). -hls_flags independent_segments разрешает случайный доступ к каждому сегменту (дружелюбно к CDN). Для частичных сегментов LL-HLS (200 мс) нужно расширение Apple cmafSegmentDuration.

Подключение к WebRTC (пример на mediasoup/Node.js)

// Client joins a mediasoup room
const rtpCapabilities = await mediasoupClient.device.getRtpCapabilities();

const transportParams = await fetch('/api/transport', {
  method: 'POST',
  body: JSON.stringify({ rtpCapabilities })
}).then(r => r.json());

const transport = await mediasoupClient.device.createSendTransport(transportParams);

const producer = await transport.produce({
  track: videoTrack,
  codecOptions: {
    videoGoogleStartBitrate: 1000,
    videoMaxBitrate: 5000,
  }
});

// Inform server of producer ID
await fetch('/api/producer', {
  method: 'POST',
  body: JSON.stringify({ producerId: producer.id })
});

Что происходит. Клиент запрашивает у сервера Send Transport (подключается к SFU). Клиент добавляет видеотрек (с камеры или экрана). SFU кодирует поток в нескольких битрейтах (simulcast). Клиент теперь — Producer в комнате SFU.

Мини-кейс: Worldcast Live — 10 000 одновременных HD-зрителей с задержкой 0,4 с

Задача. Концертная площадка хотела транслировать живой HD-концерт на 10 000 одновременных зрителей по всему миру. Интерактивная задержка была критична: аудитория хотела видеть реакцию исполнителя на возгласы зала в пределах 500 мс. Подход на чистом WebRTC стоил бы 562 тыс. ₽+ только за серверы SFU; чистый HLS означал бы задержку 15–30 с, что ломало интерактивность.

Архитектура. Мы развернули гибрид: 4 инстанса mediasoup (Hetzner серии AX) тянут 50 сценических спикеров и участников аудитории с RTT 0,1 с между ними. Каждый спикер передаёт 1080p 30 fps (4,5 Мбит/с). SFU кодирует один мастер-выход 1080p 5 Мбит/с, отдаёт его в FFmpeg-энкодер, который режет в LL-HLS (сегменты по 1 с, контейнер fMP4). Сегменты уходят в S3, дальше распространяются через Cloudflare CDN. Зрители видят задержку 0,4–0,5 с glass-to-glass (буфер энкодера ~100 мс + сеть 150–200 мс + буфер плеера 100–150 мс).

Разбивка по стоимости. Кластер SFU: 4 машины × 11 250 ₽/мес = 45 000 ₽/мес. Энкодер (FFmpeg на одной Hetzner CPX41): 3 750 ₽/мес. Egress CDN (10 тыс. зрителей × 2,25 ГБ/час × 4 часа × 0,07 ₽/ГБ): 6 750 ₽. Итого за 4-часовой концерт: 55 500 ₽. Стоимость на зрителя-час: 0,13 ₽. Для сравнения, чистый WebRTC обошёлся бы в 562 тыс. ₽ только за инфраструктуру.

Результат. Зрители сообщили об отзывчивом и стабильном видео. Частота буферизации: 0,3% (ниже порога 1% для хорошего QoE). Вовлечённость в чате была высокой, потому что интерактивность ощущалась настоящей. Доля обрывов в середине звонка: 3% (норма для потребительских сетей). Команда повторила эту архитектуру на 8 событиях в 2025 году; каждый раз задержка и стоимость масштабировались предсказуемо.

Мини-кейс: Sprii Live Shopping — 50 000 одновременных зрителей с задержкой 3 с

Задача. Платформе live-шопинга нужно было масштабироваться до 50 000 одновременных зрителей на флеш-распродажах. Задержка 3–5 секунд была приемлемой (зрители жмут «купить» в пределах нескольких секунд после анонса скидки ведущим). Подход на WebRTC на таком масштабе не работал.

Архитектура. Чистый LL-HLS. Ведущие вещали 720p 30 fps (2,5 Мбит/с) через OBS в RTMP-эндпоинт. FFmpeg-энкодер создавал 5-уровневую ABR-лестницу (1080p, 720p, 480p, 360p, 240p) и резал в LL-HLS (сегменты по 1,5 с). Система каталога товаров получала события от вещателя (ID товара, количество, промокод) и синхронизировала их по WebSocket всем зрителям отдельно от видеопотока. Сегменты уходили в S3 и Cloudflare. Зрители получали задержку 3 с glass-to-glass с нулевой буферизацией на 95-м перцентиле.

Стоимость одного события. Egress: 50 тыс. зрителей × 1,5 ГБ (40-минутный шопинг-эфир) × 0,11 ₽/ГБ (объёмная скидка Cloudflare) = 8 437 ₽ за событие. Энкодер-сервер (один Hetzner AX41): 7 500 ₽/мес, амортизировано до ~225 ₽ на событие. Итого: ~8 625 ₽ за событие на 50 тыс. зрителей. Стоимость на зрителя-час: 0,07 ₽.

Результат. Конверсия в оформление заказа выросла на 8% по сравнению с записанными стримами (воспринимаемая интерактивность сыграла свою роль). Частота буферизации: 0,15%. Платформа теперь проводит 2–3 флеш-события в неделю, пиковая аудитория каждого — 30–60 тыс. зрителей. Гибридная синхронизация продуктов (видео LL-HLS + обновления товаров по WebSocket) стала шаблоном, который Фора Софт переиспользовала ещё для трёх live-коммерс-приложений.

Модель стоимости — три уровня

Вот что реально потратите на 2-часовое live-событие в 2026 году на продакшен-железе (Hetzner или эквивалентное облако):

Уровень 1: 1 000 одновременных зрителей

• WebRTC (1 SFU + 1 энкодер): Hetzner AX41 (9 000 ₽/мес) + вычислительные часы = ~3 000 ₽ суммарно. Стоимость на зрителя-час: 1,5 ₽.
• LL-HLS (энкодер + CDN): Энкодер (225 ₽ амортизировано) + egress (1 тыс. × 4,5 ГБ × 0,15 ₽/ГБ) = 900 ₽ суммарно. Стоимость на зрителя-час: 0,45 ₽.
• Победитель: LL-HLS в 3,3 раза. Но WebRTC жизнеспособен, если нужна задержка <1 с.

Уровень 2: 10 000 одновременных зрителей

• WebRTC (4 инстанса SFU + энкодер): 4 × 11 250 ₽ / 20 часов длительности события = 2 250 ₽ за событие. Стоимость на зрителя-час: 0,11 ₽ (при ежемесячной амортизации по 20 событиям).
• LL-HLS (энкодер + CDN): Энкодер (225 ₽) + egress (10 тыс. × 4,5 ГБ × 0,11 ₽/ГБ) = 5 325 ₽ суммарно. Стоимость на зрителя-час: 0,27 ₽.
• Победитель: WebRTC, если амортизировать помесячно. LL-HLS, если событие разовое. Гибрид (спикеры через WebRTC + зрители через LL-HLS) — золотая середина: 7 500 ₽ суммарно, 0,37 ₽ за зрителя-час.

Уровень 3: 100 000 одновременных зрителей

• WebRTC: Нежизнеспособно. Понадобится 50+ инстансов SFU = инфраструктура на 562 тыс. ₽/мес.
• LL-HLS (энкодер + CDN): Энкодер (375 ₽ амортизировано) + egress (100 тыс. × 4,5 ГБ × 0,06 ₽/ГБ, объёмная скидка) = 27 525 ₽ суммарно. Стоимость на зрителя-час: 0,13 ₽.
• Победитель: LL-HLS — единственный вариант. Гибрид — только если нужна небольшая группа WebRTC-спикеров (<50).

Фреймворк принятия решения — пять вопросов

1. Какой у вас потолок одновременных зрителей? Если <500 — WebRTC жизнеспособен. Если 500–10 тыс. — выигрывает гибрид. Если 10 тыс.+ — нужен LL-HLS. (Всё, что выше 100 тыс., толкает вас к управляемому CDN вроде Cloudflare или Akamai.)

2. Какая у вас целевая задержка? Если <1 с — только WebRTC. Если 1–5 с — LL-HLS. Если 5 с+ — классический HLS. Если не знаете — по умолчанию 2–5 с (LL-HLS — безопасный выбор для большинства сценариев).

3. Нужно ли зрителям отправлять данные обратно вещателю в том же потоке? Если да (ставки на live-аукционе, управление игрой) — WebRTC или WebRTC + отдельный канал сообщений. Если нет (только просмотр, чат отдельно) — LL-HLS подойдёт.

4. Какое покрытие устройств вам нужно? Если обязательны смарт-ТВ, Roku, старые Android — HLS, единственный вариант. Если хватает веба и мобильных — LL-HLS работает.

5. Какой у вас месячный бюджет на события? Если <37 500 ₽ — LL-HLS или гибрид. Если 37 500–375 тыс. ₽ — гибрид. Если 375 тыс. ₽+ — WebRTC масштабируется, но требует постоянной эксплуатации SFU. (Управляемые сервисы вроде Agora стоят ~0,75 ₽ за зрителя-минуту, что на 10 тыс. зрителей превышает расходы на CDN.)

Не уверены, какой уровень подходит вашей платформе? Позвоните нам по телефону +7 (911) 236-51-91 или напишите на info@fora-soft.ru, и мы пройдёмся со стриминг-архитектором по вашим целям по задержке, потолку зрителей и бюджету.

Пять подводных камней — что ломается в продакшене

1. Недооценка частоты сбоев ICE в WebRTC. Планируйте, что 10–15% согласований ICE упадут или деградируют до TURN-релея. Это добавляет 50–200 мс задержки на соединение и сжигает полосу TURN-сервера. Закладывайте 1 Мбит/с TURN-полосы на 20–30 одновременных пользователей. Тестируйте на реальных сотовых сетях (4G LTE, 5G) до запуска, а не только на Wi-Fi.

2. Выбор размера сегмента без тестирования. 1-секундный сегмент — дефолт для LL-HLS, но он добавляет накладных расходов. Если аудитория в основном на перегруженной сотовой связи, попробуйте сегменты по 2–3 с и замерьте частоту буферизации. 1-секундный сегмент на канале 1 Мбит/с с заторами скачивается >8 секунд; плеер ребуферизуется.

3. Несовпадение кодеков между энкодером и SFU (в гибридных схемах). Если энкодер отдаёт H.264, а SFU ждёт VP8 — придётся перекодировать. Это стоит CPU и добавляет задержку. Всегда выравнивайте кодеки: если SFU выдаёт H.264, говорите энкодеру принимать H.264 на вход.

4. Отсутствие мониторинга частоты буферизации и RTT в продакшене. Частота буферизации — это процент сессий воспроизведения, которые подвисают. RTT — round-trip time для запроса сегмента плеером с CDN. Типовые цели: частота буферизации <1%, медианный RTT <200 мс. Если не снимаете эти метрики, не узнаете, когда архитектура ломается, пока пользователи не пожалуются.

5. Каскадные сбои SFU из-за нехватки TURN-мощности. Если WebRTC-связка опирается на peer-to-peer, а TURN-мощность кончилась — новые согласования ICE падают, и вы теряете зрителей. Прогоните нагрузочный тест перед событием: подключите вдвое больше ожидаемой нагрузки и замерьте долю успешных ICE. Если меньше 90% — добавляйте TURN-серверы или смиритесь с тем, что у 10% зрителей задержка будет выше.

KPI — что измерять в продакшене

KPI качества. Доля буферизации: процент сессий с хотя бы одной остановкой. Цель: <1%. Задержка старта: время от .play() до первого отрисованного кадра. Цель: <3 с для LL-HLS, <5 с для HLS. Битрейт (взвешенное среднее): какой процент зрителей смотрел в полном качестве против пониженного. Цель: >70% на 720p+.

Бизнес-KPI. Пиковое число одновременных зрителей: максимум параллельных стримов. Ожидаемая вовлечённость: (длительность сессии зрителя / длительность трансляции). Доля оттока: процент зрителей, прервавших просмотр в середине. Цель: <5% для live-событий. Доход на зрителя (если применимо): рекламные показы / число зрителей.

KPI надёжности (WebRTC). Доля успешных ICE: процент попыток соединения, дошедших до peer-to-peer. Цель: >85%. Доля обрывов в середине звонка: процент активных соединений, неожиданно отключившихся. Цель: <5%. Загрузка CPU SFU: средняя нагрузка по инстансам SFU. Цель: <70% (запас на пики). Доля TURN-релея: процент соединений, откатившихся на релей. Цель: <15%.

Когда НЕ стоит использовать WebRTC или HLS

Если у вас записанный контент с произвольной перемоткой (пользователь может перематывать вперёд и назад), ни WebRTC, ни HLS — не лучший первый выбор. Берите прогрессивную загрузку MP4 или VOD-платформу (Vimeo, Mux, JW Player), оптимизированную под навигацию.

Если нужно сквозное шифрование на уровне зрителя (например, медицинские консультации с соблюдением HIPAA) — нужен HLS с DRM (Widevine, FairPlay, PlayReady) или WebRTC с DTLS-SRTP-шифрованием end-to-end. Обычный CDN под соответствие не подходит.

Если у вас меньше 50 зрителей и допустима задержка 10–30 секунд — простой RTMP-сервер (модуль Nginx RTMP, Wowza) с вещанием на обычный CDN дешевле и проще, чем WebRTC или HLS. Изощрённость не нужна; нужна доступность.

FAQ

WebRTC быстрее HLS?

По задержке — да: WebRTC выдаёт 0,2–0,5 с glass-to-glass; HLS — 2–40 с в зависимости от варианта. Но «быстрее» не значит лучше для вашего сценария. HLS надёжнее на масштабе, поддерживает больше устройств и обходится дешевле на зрителя. Если задержка меньше секунды не нужна, LL-HLS часто выигрывает по простоте.

Можно ли использовать WebRTC и HLS в одном приложении?

Безусловно. Это и есть гибридная схема: WebRTC для спикеров и интерактивных пользователей, HLS для зрителей. Запускаете их параллельно. Спикеры получают RTT меньше секунды между собой; зрители получают стабильный буферизованный поток. Большинство современных live-платформ используют это как архитектуру по умолчанию.

Что такое LL-HLS и чем он отличается от классического HLS?

Low-Latency HLS использует частичные сегменты (чанки по 200–500 мс), которые пушатся через HTTP/2 server push, уменьшая задержку с 15–40 с до 2–5 с. Работает на стандартных CDN и автоматически откатывается на классический HLS, если плеер или CDN не поддерживают server push. LL-HLS — протокол выбора для live-событий в 2026.

HLS работает везде?

Классический HLS работает на любом устройстве (iOS, Android, веб, смарт-ТВ, Roku). LL-HLS работает нативно на iOS 13+ и Safari, на других браузерах требует HLS.js, а на смарт-ТВ — как повезёт по состоянию на 1 квартал 2026. Если нужна 100% поддержка устройств, протестируйте свой плеер на реальной пользовательской базе или добавьте откат на классический HLS.

А что насчёт WebTransport и QUIC для стриминга?

QUIC быстрее TCP для ненадёжных протоколов с низкой задержкой. WebTransport (QUIC поверх HTTP/3) — развивающийся стандарт, но по состоянию на 2026 он всё ещё экспериментален в браузерах и CDN. Для продакшена держитесь WebRTC (который под капотом использует UDP) или LL-HLS (который работает по HTTP/2 TCP). WebTransport начнёт играть роль в 2027–2028, когда поддержка в браузерах станет шире.

Подходит ли WebRTC для 100 000 одновременных зрителей?

Нет, не как основной транспорт. Один инстанс SFU упирается в потолок 300–500 зрителей. Для масштабирования до 100 тыс. зрителей понадобилось бы 200–400 инстансов SFU, каскадированных деревом, что добавит огромную задержку и операционные расходы. Используйте WebRTC для небольшой группы спикеров (<100), а массовую аудиторию вещайте через HLS/LL-HLS.

HLS шифруется end-to-end?

Сегменты HLS шифруются в пути (TLS до CDN), но не шифруются в покое в edge-кэше CDN. Для полного end-to-end-шифрования (вещатель → зритель) нужен DRM (Widevine, FairPlay, PlayReady) или собственный слой шифрования. В WebRTC шифрование DTLS-SRTP встроено, поэтому он — выбор по умолчанию для стримов, где критична приватность (медицина, юриспруденция).

А что со спортивными ставками с жёсткой задержкой?

Регулирование ставок различается по юрисдикциям, но большинство требует, чтобы live-поток и фид ставок были синхронизированы в пределах 500 мс — 1 секунды. Это исключает классический HLS (слишком большая задержка). Нужен WebRTC (<500 мс) или LL-HLS (<5 с) в связке с низкозадержечным фидом событий (WebSocket или gRPC). Юридическая экспертиза обязательна; одной задержки для соответствия мало.

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

Готовы выбрать протокол и масштабировать его?

В 2026 WebRTC и HLS — не конкуренты, а дополняющие друг друга технологии. WebRTC выигрывает в интерактивных сценариях с задержкой меньше секунды в небольших группах. HLS и LL-HLS выигрывают по масштабу и охвату устройств. Гибридная схема (спикеры через WebRTC, зрители через HLS/LL-HLS) — выбор по умолчанию для современных live-платформ, потому что балансирует задержку, стоимость и эксплуатационную простоту. Worldcast Live доказал это на 10 тыс. одновременных зрителей; Sprii — на 50 тыс. Ваша платформа, скорее всего, пойдёт по тому же пути.

Дерево решений простое: если зрителей <500 и нужна задержка меньше секунды — берите WebRTC. Если 500–100 тыс. и допустимы 2–5 с — берите гибрид или чистый LL-HLS. Если 100 тыс.+ или обязательно поддерживать все устройства — берите чистый LL-HLS. Большинство реальных платформ приходят к гибриду, потому что им нужны и интерактивность, и масштаб.

Инженерная сложность реальна — эксплуатация SFU, жизненный цикл сегментов, управление кэшем CDN, тюнинг кодеков, откат ICE — но это уже хоженый путь. Мы выпускали этот стек для концертного стриминга, live-шопинга, дебатных платформ и финансового трейдинга. Модель стоимости предсказуема. Цели по задержке достижимы.