13 ноября 2026
Почему WebRTC и LL-HLS стали базовыми вариантами для живого видео
В январском бенчмарке компании Ceeblue за 2024 год задержка WebRTC на выходе составила 240 мс при приёме потока по RTMP, а LL-HLS в тестах без перекодирования показал от 2,8 до 3,22 секунды. Разница почти на порядок объясняет, почему два протокола давно не воспринимаются как конкуренты в лоб. Они решают разные задачи, хотя оба появились из одной потребности: зритель не хочет ждать.
Обычная трансляция с десятком секунд запаздывания годится, пока зритель только смотрит. Но если участники общаются, голосуют, задают вопросы ведущему или реагируют на происходящее в кадре, отставание в несколько секунд разрушает сам сценарий. Ответ приходит на реплику, которую все уже забыли. Для таких случаев и нужны протоколы, которые сокращают путь от камеры до экрана до секунд или долей секунды.
Классические HLS и DASH строились иначе. В академической статье 2024 года о сверхнизкой задержке в стриминге отмечено, что они опираются на сегментную доставку: видео нарезается на фрагменты, которые нужно записать, передать и накопить в буфере плеера. Из-за этого опуститься ниже 3–4 секунд крайне трудно. Ceeblue в сводной оценке по реальным тестам называет ориентиры в 10 000 мс для HLS и 5 000 мс для DASH.
WebRTC изначально создавался для связи в реальном времени и, как пишет разработческий блог Mux, способен давать задержку меньше секунды. Low-latency HLS, напротив, не отказывается от привычной модели, а старается сократить задержку обычного HLS до нескольких секунд. Поэтому выбор между ними начинается не со сравнения цифр, а с вопроса, что именно зритель должен успеть сделать за время между событием и его появлением на экране.
Чем WebRTC достигает задержки в сотни миллисекунд
Главное отличие WebRTC лежит на уровне транспорта. Как объясняется в той же академической статье, он использует передачу поверх UDP, где требования к порядку пакетов и гарантированной доставке мягче, чем в протоколах с жёсткой надёжностью. Клиенту не нужно ждать, пока потерянный пакет будет отправлен повторно, и можно держать небольшой буфер. Меньше буфер — меньше задержка, но и меньше запас прочности при нестабильной сети.
Именно поэтому цифры у WebRTC такие маленькие. В тесте Ceeblue выход по WebRTC дал 240 мс при приёме по RTMP, 400 мс при приёме по SRT и 250 мс при приёме по WebRTC. Это одна конфигурация из набора, и обобщать её на любую сеть нельзя. Но она показывает две вещи: порядок величин остаётся в сотнях миллисекунд, а выбор способа доставки потока на сервер способен сдвинуть результат заметно. Интересно, что вариант с WebRTC на входе не оказался самым быстрым: сквозной путь складывается из нескольких звеньев, и выигрыш в одном не гарантирует выигрыша в целом.
Отдельная тема — приём потока от источника, или contribution ingest. По данным статьи Streaming Media за февраль 2024 года, стандарт WHIP добавили, чтобы WebRTC можно было использовать для такого приёма по UDP по умолчанию. Прежде вещатели обычно отправляли сигнал на сервер по RTMP или SRT, а WebRTC оставался прежде всего способом раздачи зрителям. WHIP делает схему единообразной: тот же стек может работать и на входе, и на выходе.
Стоит оговорить и другой результат. Авторы статьи 2024 года сообщили о задержке порядка 2 секунд при использовании каналов данных WebRTC (data channels). Это заметно выше субсекундных значений Ceeblue, но речь идёт о другом способе доставки и другой постановке эксперимента. Вывод практический: «WebRTC» сам по себе не равен «меньше полсекунды». Итоговая цифра зависит от архитектуры, настроек буферов и маршрута.
Почему LL-HLS всё ещё нужен для масштабируемых трансляций
Если WebRTC быстрее, зачем вообще нужен LL-HLS? Потому что он остаётся в рамках знакомой модели сегментной HTTP-доставки и лишь сокращает её задержку. Mux описывает его задачу как снижение задержки обычного HLS до нескольких секунд, и измерения это подтверждают: у Ceeblue в тестах passthrough получилось от 2,8 до 3,22 секунды, а в общей оценке по реальным тестам фигурирует ориентир в 3 000 мс.
Три секунды — это не «почти реальное время», но по сравнению с десятью секундами классического HLS выигрыш в несколько раз. Для спортивной трансляции, концерта или вебинара с редкими вопросами такая задержка часто приемлема. Зритель не общается с ведущим в режиме диалога, ему важнее, чтобы картинка не рассыпалась и воспроизведение работало на разных устройствах. Модель, которая строится на HTTP, позволяет использовать ту инфраструктуру доставки, к которой уже привыкли команды, работающие с обычным HLS.
Есть и обратная сторона. Как отмечают авторы статьи 2024 года, сама сегментная природа HLS и DASH делает задержки ниже 3–4 секунд трудно достижимыми. LL-HLS подбирается к этой границе, но не пересекает её с запасом: измеренные 2,8–3,22 секунды лежат как раз у неё. Если сервису нужен ответ на реплику за доли секунды, никакая тонкая настройка сегментов этого не изменит, придётся менять протокол.
Практически это означает, что LL-HLS выбирают не из-за рекордной скорости, а из-за баланса. Он заметно быстрее обычного HLS и при этом не требует перестраивать всю схему доставки под другой транспорт. Для проектов, где важнее охват и предсказуемость, чем разговорный темп, это разумный компромисс.
Проверка отклика интерактивных потоков на международных узлах связи
Цифры из лабораторных тестов полезны как ориентир, но реальное поведение протокола проверяется на конкретном маршруте. Пакеты до зрителя в другой стране идут через другие узлы, чем в тестовой сети, и именно здесь UDP-транспорт WebRTC и сегментная модель LL-HLS ведут себя по-разному. Поэтому команды, которые строят интерактивные сервисы, обычно измеряют не только среднюю задержку, но и её разброс при нескольких подключениях в разное время суток.
Оценить быстродействие и стабильность отклика интерактивных медиапотоков на зарубежных серверах можно с помощью простых практических тестов. В качестве наглядного примера подойдут площадки вроде spill live casino online, где видеопоток передаётся в реальном времени и любая задержка картинки заметна сразу. Подобное наблюдение не заменяет точных измерений, но помогает быстро понять, укладывается ли отклик в нужные рамки. После этого стоит перейти к цифрам и сравнить момент события в кадре с моментом его появления на экране зрителя.
Бенчмарк Ceeblue показывает, на что обращать внимание при такой проверке. Один и тот же выходной протокол даёт разные результаты в зависимости от способа приёма потока: 240 мс при RTMP, 250 мс при WebRTC и 400 мс при SRT. Поэтому тестировать нужно всю цепочку целиком, от источника до плеера, а не отдельный её участок. Если менять только протокол раздачи и не трогать приём, часть возможного выигрыша останется незамеченной.
Полезно и просто зафиксировать условия измерения: тип соединения, устройство, время, способ приёма. Без этого сравнивать результаты через месяц будет не с чем. А если сервис работает для аудитории в разных странах, имеет смысл повторить замеры на каждом ключевом направлении отдельно и не полагаться на одно удачное значение.
Как онлайн-сервисы выбирают протокол под сценарий использования
Выбор в итоге сводится к тому, какая задержка допустима и сколько зрителей ожидается. Для разговорных и интерактивных форматов, где участники отвечают друг другу, подходит WebRTC с его сотнями миллисекунд. Для массовых трансляций, где достаточно нескольких секунд, логичнее LL-HLS. Классические HLS и DASH остаются вариантом там, где задержка не критична. Сводные ориентиры Ceeblue по реальным тестам удобно держать перед глазами:
| Протокол | Ориентировочная задержка |
|---|---|
| WebRTC | около 300 мс |
| LL-HLS | около 3 000 мс |
| DASH | около 5 000 мс |
| HLS | около 10 000 мс |
Эти значения — ориентиры, а не гарантии: в отдельных тестах WebRTC показывал 240–400 мс, а LL-HLS укладывался в 2,8–3,22 секунды. Академическая статья 2024 года добавляет предупреждение, что даже при использовании WebRTC задержка может оказаться выше ожидаемой, если решение построено на каналах данных: там зафиксировано около двух секунд.
Отдельный вопрос — приём потока от вещателя. Появление WHIP, о котором писал Streaming Media, делает схему «WebRTC на входе и на выходе» более доступной, но Ceeblue показывает, что она не всегда выигрывает по скорости у связки с RTMP. Поэтому выбирать вход стоит по результатам собственных замеров, а не по общему впечатлению о «современности» протокола.
Практический порядок действий несложный. Сначала нужно записать, на какой отклик рассчитан сценарий: диалог, реакция аудитории или просто просмотр. Затем прогнать оба протокола на реальных маршрутах и сравнить не только среднюю задержку, но и её разброс. И только после этого решать, нужен ли сервису WebRTC, хватит ли LL-HLS или стоит использовать оба — каждый для своей части аудитории.
Читайте также