Термин

Media over QUIC (MoQ)

Короткое определение

Рабочая группа IETF (учреждена в 2022 году), разрабатывающая pub/sub-протокол стриминга поверх QUIC и WebTransport. Цель – стать преемником как HLS, так и WebRTC для нового стриминга с низкой задержкой.

Media over QUIC, сокращённо MoQ, – это попытка IETF разработать единый протокол, способный охватить как сценарии с кэшированием через CDN (где доминируют HLS и DASH), так и сценарии с задержкой менее секунды для прямого вещания (где лидирует WebRTC). Основная идея – модель публикации/подписки: издатели отправляют медиа в «треки», идентифицируемые URI; подписчики получают треки по имени; промежуточные ретрансляторы кэшируют и раздают данные так же, как это делает CDN для HLS, но через потоки QUIC вместо HTTP-ответов.

Архитектура описана в `draft-ietf-moq-transport` (последняя версия драфта – 2025 год), а также в `draft-ietf-moq-streaming-format` и `draft-ietf-moq-warp` для медиа-специфичных фреймингов. В основе – QUIC и WebTransport для браузеров. Главная особенность – восстановление потерь на уровне отдельных треков: один релей может обслуживать тысячи подписчиков, при этом для каждого работает поведение на уровне потока в QUIC. Это устраняет проблемы head-of-line blocking и состояния на каждого подписчика, которые ограничивают масштабируемость SFU в WebRTC.

К 2026 году MoQ находится на стадии proof-of-concept у нескольких крупных операторов: Cloudflare, Meta, Twitch и Akamai уже проводили эксперименты с MoQ. Протокол пока не готов к массовому внедрению – драфты всё ещё в разработке, поддержка в браузерах ограничена, инструментов для настройки мало. Ожидается, что в 2027–2028 годах появятся первые стандартизованные RFC и начнётся первая волна развёртываний в продакшене в интерактивных live-приложениях, которым сегодня приходится выбирать между LL-HLS (слишком медленно) и WebRTC (слишком сложно в эксплуатации).

Считаете параметры для своего продукта?

Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.