WebRTC или 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-ХЛС, если нужен массовый охват и допустима задержка 2–30 секунд. Это вещание на 10 тыс. и более зрителей одновременно в рамках разумного бюджета: прямые трансляции спортивных событий, презентации продуктов, образовательные стримы, прямые эфиры в шопинге.

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

Что такое задержка на самом деле — 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 секунды». То же самое называют «воспринимаемой задержкой» или «стриминговой задержкой». Критично для прямых трансляций, менее важно для односторонних.

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

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

Архитектура SFU (стандарт для прямых трансляций с участием множества пользователей)

Каждый спикер передаёт видеопоток (обычно 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) берёт прямой поток, разбивает его на фрагменты по 2–10 секунд (в формате MPEG-TS или fMP4) и отдаёт как плейлист. Плеер зрителя читает этот плейлист, скачивает фрагменты по очереди, буферизует 2–3 штуки и воспроизводит их подряд. Просто, хорошо кэшируется и легко масштабируется до миллионов зрителей одновременно — за счёт обычного CDN.

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

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

LL-HTTP Live Streaming (LL- 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-HTTP Live Streaming выигрывает в 2026 году. Работает на любом CDN, поддерживающем HTTP/2 server push (Cloudflare, Akamai, AWS CloudFront, Fastly). Не требует специального оборудования для SFU. Масштабируется до 100 тыс. одновременных зрителей при стоимости передачи данных около 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-HTTPS: платите за трафик через 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-HTTP Live Streaming (LL-HTTP Live Streaming) стоит 1 650–5 025 ₽, WebRTC — около 33 750 ₽. HLS выигрывает в 10 раз. Но если нужна задержка меньше секунды или низкая задержка между спикерами, выбора, кроме 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-HTTP Live Streaming (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-HTTP Live Streaming (LL- HLS)-сегменты. Зрители получают LL-HLS-поток через CDN.

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

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

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

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

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

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

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

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

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-HTTP Live Streaming (LL- HLS) стандартный размер сегмента — 1–2 с. Однако на перегруженных сотовых сетях 1-секундный сегмент может не успеть загрузиться до появления следующего, и плеер начинает буферизоваться. Проблему решают адаптивным размером сегмента (например, CMAF-LL с дробными сегментами, размер которых меняется динамически) или предсказательным предвыборочным буферированием (плеер заранее читает и буферизует три сегмента).

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

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 из живого HLS-стрима, либо записывайте исходный поток напрямую, либо используйте сервис архивации сегментов, который сохраняет их по мере создания.

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

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

Эта команда берёт входной RTMP-поток (от вашего SFU или энкодера) и создаёт LL-HTTP Live Streaming (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-HTTP Live Streaming на iOS). -hls_flags independent_segments позволяет обращаться к каждому сегменту независимо (удобно для CDN). Для коротких сегментов LL-HTTP Live Streaming (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 кадров в секунду (4,5 Мбит/с). SFU кодирует один общий выходной поток 1080p со скоростью 5 Мбит/с и передаёт его в FFmpeg-энкодер, который разбивает поток на сегменты LL- HLS (длительность сегментов — 1 с, контейнер fMP4). Эти сегменты сохраняются в S3, а затем распространяются через CDN Cloudflare. Зрители видят задержку 0,4–0,5 с от экрана до экрана: примерно 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%, при котором качество восприятия считается хорошим. Активность в чате была высокой, потому что взаимодействие ощущалось живым и реальным. Обрыв соединения в середине трансляции случился у 3% зрителей — это соответствует норме для обычных потребительских сетей. Команда применяла ту же архитектуру ещё на 8 мероприятиях в 2025 году, и каждый раз задержка и затраты на масштабирование оставались предсказуемыми.

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

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

Архитектура. Чистый LL-HTTP Live Streaming (LL- HLS). Ведущие транслировали видео в разрешении 720p, 30 кадров в секунду, со скоростью 2,5 Мбит/с через OBS в RTMP-эндпоинт. FFmpeg-энкодер создавал ABR-лестницу из пяти уровней (1080p, 720p, 480p, 360p, 240p) и разбивал поток на сегменты по 1,5 секунды в формате LL- HLS. Система каталога товаров получала от вещателя события — ID товара, количество и промокод — и отправляла их каждому зрителю через WebSocket, независимо от видеопотока. Готовые сегменты сохранялись в S3 и раздавались через Cloudflare. Зрители получали задержку от экрана до экрана 3 секунды при отсутствии буферизации на 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-HTTP Live Streaming + обновления товаров через WebSocket) стала шаблоном, который Фора Софт применила ещё в трёх live-коммерс-приложениях.

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

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

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

• WebRTC (1 SFU + 1 энкодер): Hetzner AX41 (9 000 ₽/мес) + вычислительные часы = ~3 000 ₽ суммарно. Стоимость на зрителя в час: 1,5 ₽.
• LL-ХЛС (энкодер + CDN): Энкодер (225 ₽ амортизировано) + трафик (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 ₽) + трафик (10 тыс. × 4,5 ГБ × 0,11 ₽/ГБ) = 5 325 ₽ всего. Стоимость на один зрительский час — 0,27 ₽.
• Победитель: WebRTC, если считать по месяцам. LL-НЛС, если мероприятие разовое. Гибрид (спикеры через WebRTC + зрители через LL-НЛС) — золотая середина: 7 500 ₽ суммарно, 0,37 ₽ за зрителя в час.

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

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

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

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

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

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

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

5. Какой у вас месячный бюджет на события? Если <37 500 ₽ — LL-HTTP или гибрид. Если 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 — придётся перекодировать. Это нагружает процессор и увеличивает задержку. Всегда согласовывайте кодеки: если SFU работает с H.264, настройте энкодер на приём H.264.

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

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

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

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

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

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-HTTP Live Streaming (LL- HLS) часто выигрывает по простоте реализации.

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

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

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

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

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

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

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

QUIC работает быстрее TCP в условиях ненадёжной сети с низкой задержкой. WebTransport (QUIC поверх HTTP/3) — развивающийся стандарт, но по состоянию на 2026 год он всё ещё остаётся экспериментальным в браузерах и CDN. Для продакшена лучше использовать WebRTC (в основе которого лежит UDP) или LL-HTTP (работающий по 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-HTTP Live Streaming (LL-HTTP Live Streaming) — по масштабу и охвату устройств. Гибридная схема (спикеры через WebRTC, зрители через HLS/LL-HTTP Live Streaming) — выбор по умолчанию для современных платформ прямых трансляций, потому что она балансирует задержку, стоимость и простоту эксплуатации. Worldcast Live доказал это на 10 тыс. одновременных зрителей; Sprii — на 50 тыс. Ваша платформа, скорее всего, пойдёт по тому же пути.

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

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