HLS и WebRTC:
что выбрать для онлайн-трансляций
Статья разбирает HLS и WebRTC как две разные модели видеодоставки — с точки зрения архитектуры, задержки, масштабирования и эксплуатационных требований. Классический HLS при 6‑секундных сегментах и CDN‑кешировании даёт задержку 20–45 секунд; Low‑Latency HLS снижает её до 1,5–3 секунд, сохраняя CDN‑совместимость. WebRTC обеспечивает задержку 150–500 мс, но требует SFU‑кластера, сигнального слоя и TURN‑ретрансляторов — через которые в реальных условиях проходит около 20–25% сессий. Технологии не исключают друг друга: в продвинутых архитектурах WebRTC часто обслуживает ведущих и интерактивный контур, а HLS — массовую зрительскую аудиторию через CDN. Материал адресован инженерам, продюсерам ивентов и техническим руководителям, выбирающим архитектуру стриминга под конкретную задачу.
Если сравнивать HLS и WebRTC для онлайн-трансляций только по задержке доставки, в центре внимания окажется один параметр: HLS медленнее, WebRTC быстрее. Для стриминга этого недостаточно: технологии различаются по модели доставки, подходу к масштабированию и требованиям к инфраструктуре.
Поэтому полезнее спрашивать не «что лучше», а «какая модель доставки подходит под конкретный сценарий». Для массового эфира на десятки тысяч зрителей ответ будет одним, для трансляции с интерактивом — другим.
В этом материале разберём, как устроены HLS и WebRTC, где проходит граница сильных сторон и в каких случаях рассматривать WebRTC как технологию для стриминга, а не только для видеосвязи.
Как устроен HLS-стриминг
HLS (HTTP Live Streaming, RFC 8216) доставляет видео через плейлисты и сегменты по HTTP. Исходный поток разбивается на файловые фрагменты, сервер публикует плейлист, плеер последовательно загружает сегменты.
Главная сила HLS вытекает из этой архитектуры: сегменты хорошо кешируются на граничных узлах CDN. Поэтому рост аудитории не приводит к пропорциональному росту числа соединений с сервером-источником — нагрузка ложится на сеть доставки контента.
Откуда у HLS берётся задержка
Задержка доставки в HLS — следствие сегментной модели, а не плохой настройки. При рекомендованной Apple длине сегмента в 6 секунд буфер составляет около 18 секунд. С учётом добавочной задержки CDN-кеша итоговая задержка «от камеры до экрана» в типичной конфигурации составляет 20–45 секунд.
Для многих сценариев это приемлемо: конференции, концерты, корпоративные эфиры, спортивные трансляции без интерактива. Это цена за масштаб и устойчивость.
Low-Latency HLS: что меняется
Low-Latency HLS снижает задержку за счёт частичных сегментов длиной 200–500 мс, блокирующих запросов плейлиста и подсказок предзагрузки. При грамотно настроенной цепочке достигается задержка 1,5–3 секунды.
Как устроен WebRTC-стриминг
WebRTC (RFC 8825) — набор протоколов для передачи аудио, видео и данных в реальном времени. WebRTC передаёт медиаданные с минимальным накоплением буфера, обычно поверх UDP. Задержка доставки составляет 150–500 мс — на порядок меньше, чем у классического HLS.
Что стоит за этой скоростью
Первая задача — прохождение через NAT и корпоративные файрволы через ICE и STUN. В 75–80% сессий соединение устанавливается напрямую. В остальных 20–25% трафик проходит через TURN-ретранслятор.
Вторая задача — обязательная защита трафика. Согласно RFC 8827, шифрование встроено в стандарт: обязательны DTLS для согласования ключей и SRTP для передачи потока.
Почему WebRTC — не только технология для звонков
В производственных архитектурах используют сервер избирательной пересылки (SFU). Источник отправляет поток один раз на SFU, а тот распределяет его зрителям. Это превращает WebRTC в инструмент вещания в реальном времени.
Где различия становятся критичными
| Параметр | HLS | Low-Latency HLS | WebRTC |
|---|---|---|---|
| Задержка | 20–45 сек | 1,5–3 сек | 150–500 мс |
| Масштабирование | CDN-кеш, массовая аудитория | CDN + поддержка LL-HLS | SFU-кластер, 100k+ сессий |
| Инфраструктура | Энкодер + CDN + плеер | То же + совместимый CDN | SFU + STUN/TURN + сигналинг |
| Интерактивность | Ограничена | Частично | Полноценная |
| Качество при потерях | TCP восстанавливает, буфер растёт | Похоже на HLS | FEC + адаптация без буфера |
| Совместимость | Высокая, Apple-нейтив | Высокая, зависит от CDN | Современные браузеры |
Масштабирование
HLS масштабируется через CDN-кеш. Рост аудитории означает рост нагрузки на сеть доставки, а не рост числа серверных соединений.
WebRTC не кешируется в CDN: каждое соединение привязано к сессии. Масштаб достигается через каскадирование SFU. Инженерные бенчмарки фиксируют обслуживание 100 тысяч viewer-сессий без деградации качества.
Инфраструктура и стоимость владения
Инфраструктура HLS близка к стандартному веб-стеку: энкодер, сервер-источник, CDN, плеер. WebRTC требует дополнительно: сигнальный слой, STUN-серверы, TURN-ретрансляторы (обязательны для 20–25% сессий), кластер SFU.
Что всплывает после выбора архитектуры
Кодеки и совместимость форматов
Для WebRTC обязательные браузерные видеокодеки и профиль совместимости описаны в официальном наборе спецификаций WebRTC; для аудио в браузерных сценариях ключевым остаётся Opus. В HLS де-факто основа — H.264, в экосистеме Apple важен также H.265.
Если поток принимается через WebRTC с аудио в Opus, для HLS-раздачи нужен AAC — это этап перекодирования, который нужно закладывать заранее.
Совместимость с плеерами
HLS нативно поддерживается на устройствах Apple и работает с множеством распространённых JS‑плееров. WebRTC поддерживается в Chrome, Firefox, Safari и Edge, но для стабильной работы в продакшене нужно учитывать поведение сети, корпоративные устройства и файерволы.
Когда HLS и WebRTC для онлайн-трансляций работают вместе
Для крупных событий технологии часто используют вместе. Типовая схема: участники эфира работают через WebRTC с минимальной задержкой; поток перекодируется и упаковывается в HLS для массовой раздачи через CDN.
Ограничения гибрида:
- Появляется дополнительный слой обработки между контуром реального времени и массовой доставкой.
- У зрителей HLS появляется дополнительная задержка по сравнению с участниками эфира в контуре WebRTC.
- Преобразование аудио из Opus в AAC нужно закладывать в архитектуру сразу.
Три мифа об HLS и WebRTC
WebRTC — только для видеозвонков
На практике WebRTC используют и для вещания: при работе через SFU и каскадирование он подходит для интерактивного стриминга на большую аудиторию.
HLS устарел из-за задержки
На практике LL-HLS снижает задержку до нескольких секунд и сохраняет совместимость с CDN, поэтому остаётся рабочим вариантом для массовой доставки.
Нужно выбрать что-то одно
На практике HLS и WebRTC часто работают вместе: WebRTC используют в контуре с минимальной задержкой, а HLS — для массовой раздачи через CDN.
Вывод
HLS и WebRTC — это два подхода к доставке видео, а не «старый» и «новый» варианты одной технологии.
- HLS подходит для сценариев, где важны масштаб, совместимость и доставка через CDN.
- WebRTC — для сценариев, где критичны минимальная задержка и взаимодействие в реальном времени.
- На практике HLS и WebRTC для онлайн-трансляций могут использоваться вместе: WebRTC — в контуре с минимальной задержкой, HLS — в контуре массовой доставки.
- В Facecast доступны оба подхода: трансляции можно вести как по HLS через CDN на аудиторию 10 000 одновременных зрителей и больше, так и по WebRTC с задержкой в 1–2 секунды.
