Media over QUIC (MoQ): подробный разбор и поворотная точка 2026 года

Последняя проверка: 2026-05-21 по документам рабочей группы IETF Media over QUIC (MOQ): draft-ietf-moq-transport-latest (опубликован 1 мая 2026, intended status Standards Track) и предыдущей опубликованной редакции draft-ietf-moq-transport-17 (2 марта 2026); draft-ietf-moq-msf-00 (MOQT Streaming Format), draft-ietf-moq-cmsf (CMSF – CMAF поверх MSF) и draft-ietf-moq-secure-objects-00; RFC 9000 (QUIC v1), RFC 9114 (HTTP/3) и спецификация W3C WebTransport; устав и протоколы заседаний рабочей группы moq-wg с IETF 118–122; публичные анонсы Cloudflare о запуске MoQ-релейной сети, открытый код moq-rs и блог проекта moq.dev; совместная публикация Bitmovin и Cloudflare об interop-демо; демонстрации NAB Show 2026 от Ant Media, AWS, Bitmovin, Broadpeak, CacheFly, Cloudflare, Nomad Media, Norsk, Oracle, Red5, Synamedia, Wowza; академическая статья MOQtail с ACM MMSys 2026.

TL;DR

Media over QUIC (MoQ) – это новый IETF-транспорт типа publish/subscribe для живого и записанного видео, работающий поверх QUIC и WebTransport. MoQ организует любой поток как иерархию tracks → groups → subgroups → objects и использует промежуточные relay-узлы, которые подписываются один раз и фанаут-ят на многих, – фактически стирая структурную разницу между WebRTC SFU и HLS CDN внутри одной архитектуры. Поворотная точка 2026 года уже реальна: рабочая группа IETF выпускает новые редакции ежемесячно и движется к Working Group Last Call, Cloudflare развернула MoQ-relay на своих edge-серверах в более чем 330 городах, одиннадцать вендоров (Ant Media, AWS, Bitmovin, Broadpeak, CacheFly, Cloudflare, Nomad Media, Norsk, Oracle, Red5, Synamedia) показали взаимно совместимые реализации MoQ на NAB Show 2026, а CMAF-совместимый streaming format (CMSF / LOCMAF) уже находится в рабочей группе. Цель – широковещание с задержкой ниже 500 мс на масштабе миллионов зрителей поверх обычного QUIC, то есть закрытие давнего разрыва между почти-нулевой задержкой WebRTC и CDN-экономикой HLS. Честный контраргумент, который мы тоже разберём: в мае 2026 MoQ ещё не имеет чётко определённого «killer» use case, который не решался бы ничем другим, и до публикации в виде RFC остаются месяцы.

Почему это важно

Два десятилетия низкая задержка live и масштабируемая CDN-доставка жили в разных мирах. WebRTC давал около 300 мс glass-to-glass, но каждая сессия зрителя стоила слота на SFU, релеи были stateful, а CDN оставался отдельной статьёй расходов. HLS и DASH доставляли видео миллиардам зрителей дёшево, но даже LL-HLS и chunked CMAF в продакшене упирались в 1,5–3 секунды задержки. Инженеры, делающие live-спорт, ставки, аукционы, second-screen, live-commerce и интерактивные шоу, упирались в одну и ту же стену: либо задержка, либо масштаб.

MoQ – самая серьёзная попытка стереть этот выбор. Он берёт publish/subscribe-модель у WebRTC SFU, кладёт её напрямую на QUIC (тот же транспорт, что у HTTP/3), и позволяет любому кэширующему middlebox по пути работать как relay. Эти relay stateless относительно того, кто смотрит, и stateful относительно того, что доставляется, – именно эта инверсия и даёт CDN-edge возможность отдавать поток миллионам зрителей без per-viewer signalling-нагрузки. Развёртывания 2026 года уже не теоретические: первая MoQ-CDN от Cloudflare использует open-source-реализацию moq-rs на каждом сервере в 330+ дата-центрах; Bitmovin player получает поток из этой сети в публичной демонстрации; Norsk и Wowza поставляют origin-энкодеры, публикующие CMAF chunks прямо в MoQ tracks.

Эта статья – каноническая справка для инженеров, основателей и продактов, которые в 2026 году постоянно слышат «MoQ» в питчах и хотят точную картину: что такое MoQ на проводе, почему модель данных выглядит именно так, что уже стандартизовано и что ещё двигается, кто и что отгрузил, и жёсткий вопрос – какие production-нагрузки имеет смысл переводить на MoQ сейчас, а какие ждать. Мы цитируем draft-ietf-moq-transport-17 и майскую редакцию 2026 по номерам секций, называем 2026-возможности каждого вендора и в конце даём decision framework, который не предполагает, что MoQ нужен всем.

Что такое MoQ – на одной странице

MoQ – это прикладной publish/subscribe-протокол для медиа, работающий поверх QUIC (RFC 9000) или WebTransport (стек W3C/IETF, который через HTTP/3-апгрейд открывает QUIC-стримы браузеру). Протокол стандартизуется в IETF, в рабочей группе Media over QUIC. Основной документ – draft-ietf-moq-transport. Рабочая группа также ведёт небольшое семейство сопутствующих draft-ов: draft-ietf-moq-msf (MOQT Streaming Format – слой каталога и таймлайна), draft-ietf-moq-cmsf (CMSF – как класть CMAF в MSF) и draft-ietf-moq-secure-objects (end-to-end шифрование объектов). Текущая опубликованная редакция moq-transport – -17 (2 марта 2026), а в редакции -latest от 1 мая 2026 указан intended status Standards Track. Ни один из этих документов ещё не RFC – это случится после Working Group Last Call, ревью IESG и AUTH48.

Механически MoQ заимствует две идеи из мира стриминга и одну из сетей. У WebRTC он берёт publish/subscribe-модель: издатель (encoder, origin-packager, браузер с getUserMedia) анонсирует track по имени, а подписчики (зрители, нижестоящие relay-узлы) запрашивают этот track и получают его объекты. У HLS и DASH – идею независимо декодируемых кусков медиа, адресуемых не по байтовому смещению, а по структуре, – за исключением того, что в MoQ эти куски являются объектами протокола первого класса, а не файлами в манифесте. У QUIC – идею, что одно соединение несёт множество независимых streams со своим flow control и независимой head-of-line-блокировкой, плюс datagrams для сообщений, которые вообще не нужно ретранслировать.

Иерархия, которая всё это организует, точна и заслуживает того, чтобы её запомнить: track – это именованный поток медиа (например, «видео 1080p канала 47» или «звук собеседника Боба»); group – наибольшая единица, с которой подписчик может независимо начать просмотр (как правило закрытый GOP или CMAF-сегмент, например «2 секунды GOP начиная с PTS 41200»); subgroup – подразделение группы, которое напрямую отображается на один нижележащий QUIC-стрим, объединяя объекты с общим приоритетом и порядком (например «срез base layer этого GOP»); object – одна неделимая порция полезной нагрузки (CMAF-чанк, аудиокадр, кусок метаданных – например «кадр 7 этого GOP, P-frame, 1,4 KB»).

Новый подписчик присоединяется на ближайшей границе group, забирает объекты этой группы по порядку через один или несколько subgroup QUIC-стримов и сразу начинает декодировать – потому что группа по построению декодируется независимо. Никаких manifest-fetch, никакого segment list, никакого DNS-обхода на другой хост; то же самое QUIC-соединение, которое несёт live edge, обслуживает и join. Это та архитектурная разница, которая позволяет MoQ метить на задержку меньше 500 мс на CDN-масштабных relay-сетях: цена входа – один RTT, а не цепочка fetch-ов.

Транспорт на проводе – QUIC. Прикладной стек выше намеренно тонкий: никаких JSON-манифестов, никакого XML, никакого DRM-специфичного фрейминга в базовом протоколе. Всё, что специфично для «как именно нести CMAF поверх MoQ», живёт в слое streaming format (MSF + CMSF). Всё, что специфично для шифрования сверх QUIC-канала, – в draft-ietf-moq-secure-objects. Всё, что специфично для много-relay-топологий, – в информационных сопутствующих draft-ах. Базовый документ moq-transport – намеренно один транспорт, одна publish/subscribe-модель, одна иерархия данных.

Нажмите, чтобы увеличить

Рисунок 1. Стек MoQ от QUIC до application. Базовый транспорт – один документ; слой streaming format и end-to-end secure objects идут рядом с ним как отдельные сопутствующие draft-ы. Вместе они описывают, как live-edge CMAF превращается в MoQ на проводе.

Модель данных – tracks, groups, subgroups, objects

Это та часть MoQ, которую инженерам, прожившим жизнь внутри RTP или CMAF, часто приходится перечитывать дважды. Модель небольшая, но непривычная – поэтому определим каждый термин точно и пройдёмся одним живым семплом по всей иерархии.

Track – именованная упорядоченная последовательность медиа. В мире MoQ «имя» – не file path, а структурированная пара: namespace (кортеж байтовых строк, который интерпретируется как иерархический идентификатор, аналогично DNS-имени) и track name (одна байтовая строка). Для спортивного вещателя namespace может быть ("acme-sports", "live", "match-2026-05-21-arsenal-spurs"), а track-имена – video-1080p, video-720p, audio-en, audio-es, captions-en. Издатель анонсирует эти имена контрольным сообщением ANNOUNCE; подписчик запрашивает их через SUBSCRIBE (или, в новом push-flow, издатель сам инициирует через PUBLISH, а relay отвечает PUBLISH_OK).

Group – наименьшая единица, с которой подписчик может независимо стартовать. Внутри group – последовательность объектов со строго возрастающими object ID, и group целиком декодируется независимо от начала: для видео это означает старт с key frame, для аудио – старт на configuration-стабильном кадре, для метаданных – определено приложением. В CMAF-over-MoQ workflow (профиль CMSF) каждый CMAF-сегмент превращается ровно в одну group. Границы group – это точки входа: переключение варианта плеером, присоединение нового зрителя, переподключение relay – все они приземляются на следующую границу group.

Subgroup – подразделение group. Определяющее свойство subgroup в том, что все объекты внутри неё используют один QUIC-стрим, а значит и его in-order delivery, retransmission и priority. Слоистые видео-кодеки используют subgroup, чтобы разделять base layer и enhancement layer; многие реализации – чтобы разделять данные кадра и метаданные кадра; академический прототип MOQtail (ACM MMSys 2026) тестировал subgroup-разделение как способ сбрасывать enhancement-слои под congestion, сохраняя base-слой. Простой H.264-поток без SVC обычно кладёт всю group в одну subgroup; сложный SVC-поток использует несколько.

Object – одна неделимая порция полезной нагрузки. Протокол вообще не интерпретирует тело объекта – это работа слоя streaming format. С точки зрения moq-transport объект – это «байты с Object ID, опциональным приоритетом, опциональными расширениями». В профиле CMSF тело каждого объекта содержит «как минимум один Movie Fragment Box (moof), за которым следует Media Data Box (mdat)» – то есть один CMAF-чанк. В raw-RTP-стилевом профиле (обсуждается в рабочей группе, но не production-путь) каждый объект мог бы нести один H.264 NAL или один Opus-пакет.

Чтобы привязать модель к реальности, пройдём один живой 1080p 50 fps поток от начала до конца:

• Encoder выдаёт закрытый GOP длительностью 2 секунды – каждые 100 кадров начинается новая group. Издатель задаёт namespace ("acme-sports","live","match-2026-05-21") и имя трека video-1080p, анонсирует и начинает публиковать.
• Для каждого GOP издатель открывает новую group. Group ID монотонно увеличивается – group 0, group 1, group 2 – и обычно привязан к wallclock-времени GOP.
• Внутри group 7 (GOP, начинающийся на 14-й секунде шоу) издатель открывает одну subgroup, которая на нижнем уровне – это один QUIC-стрим. CMAF-packager отдаёт издателю 100 чанков: chunk 0 – это IDR-чанк (key frame + moof+mdat), chunk-и 1–99 – P/B-frame чанки. Издатель пишет каждый чанк как один MoQ-объект с object ID от 0 до 99 в этот QUIC-стрим.
• Relay, подписанный на этот трек, получает объекты по мере прихода, кэширует их в памяти (опционально на диске для VOD-replay) и пересылает на каждый downstream QUIC-стрим, который запросил эту group. Поскольку объекты внутри subgroup идут по одному QUIC-стриму, in-order-доставка автоматическая; поскольку разные subgroup (например, audio и video) идут по разным QUIC-стримам, head-of-line-блокировки между модальностями нет.
• Новый зритель, присоединившийся на 14,7 с, подписывается на трек с фильтром «latest group». Relay запускает его с group 7, object 0 – он получает IDR и сразу начинает декодировать. Цена – один RTT на подписку плюс время прохождения object 0 от relay до зрителя.

Этот walkthrough – весь фундаментальный ритм MoQ. Всё остальное – приоритетные крутилки, partial-reliability-режимы, сообщения SUBSCRIBE_UPDATE, которые двигают live edge, сообщения FETCH для caталожной выборки – это policy поверх «опубликовать трек, организовать медиа в groups, адресовать объекты, дать relay их кэшировать».

Нажмите, чтобы увеличить

Рисунок 2. Модель данных MoQ. Track – это то, на что подписывается зритель; group – то, с чего он может независимо стартовать; subgroup – отображается на один QUIC-стрим; object – это один кусок байтов медиа. CMAF-чанки становятся объектами; границы GOP становятся границами group.

Streams, datagrams и почему MoQ выбрал QUIC

Читатель, знакомый с HLS или DASH, имеет полное право спросить: зачем QUIC? CMAF поверх HTTP/1.1 с chunked transfer encoding уже даёт задержку около одной секунды. Ответ – в трёх свойствах QUIC, которые не может повторить ни один TCP-основанный протокол.

Первое – независимые streams без head-of-line блокировки. QUIC-соединение несёт миллиарды двусторонних и односторонних streams одновременно. Потеря на одном стриме блокирует только его; остальные стримы продолжают идти. Для медиа это ровно то свойство, которое нужно SFU-стилевому фанауту: медленный зритель, отстающий по высокобитрейтному видео, не блокирует ни аудио, ни субтитры, ни стримы других зрителей. MoQ намеренно использует одну subgroup на один QUIC-стрим – чтобы cancel- и priority-семантика QUIC-стримов применялась прямо к медиа-единицам с общей судьбой.

Второе – datagrams. QUIC поддерживает расширение unreliable datagrams (RFC 9221), которое доставляет прикладные сообщения по тому же соединению, что и streams, но без ретрансмиссий. «Datagram forwarding preference» в MoQ говорит транспорту: «этот объект слишком чувствителен ко времени, чтобы ждать retransmit; если сеть его уронила – уроните и в приложении». Классический use case – низколатентное аудио, где потерянный 20 мс-пакет лучше уронить, чем восстанавливать его 200 мс ретрансмитом; рабочая группа также обсуждает datagrams для телеметрии, сигналинга и метаданных с собственной прикладной надёжностью.

Третье – 0-RTT и 1-RTT установление соединения. Криптографический handshake QUIC объединяет TLS с транспортным handshake: первый RTT одновременно устанавливает соединение и завершает TLS 1.3, а возвращающийся клиент может отправить 0-RTT данные первым пакетом. Новый подписчик, входящий в MoQ-поток, платит примерно вдвое меньше стоимости установления соединения, чем аналогичный HLS-over-HTTPS join поверх TCP+TLS.

Есть и четвёртая, менее обсуждаемая причина – тот же транспорт использует HTTP/3. Это значит, что MoQ-развёртывание делит инвестиции на уровне соединения – congestion control, ECN, BBR-эксперименты, anti-amplification – со всей экосистемой HTTP/3. moq-rs от Cloudflare построен прямо на том же стеке quiche и tokio-quiche, который обслуживает HTTP/3-трафик Cloudflare. Этот код прошёл годы production-укрепления на петабайтах трафика.

Компромисс – и его честно надо назвать – в том, что QUIC требует UDP, а значимая доля корпоративных firewall-ов до сих пор блокирует UDP на портах, отличных от 53 и 123. Прагматичный ответ рабочей группы – WebTransport: спецификация W3C / IETF, позволяющая браузеру открыть QUIC-соединение через HTTP/3-апгрейд, который сам может откатиться на HTTP/2 поверх TCP, когда UDP заблокирован. WebTransport-MoQ жертвует производительностью ради охвата. Браузерно-ориентированные развёртывания 2026 года обычно поддерживают оба пути – прямой QUIC и WebTransport – и дают клиенту выбрать.

Control plane – SUBSCRIBE, ANNOUNCE, PUBLISH, FETCH

Над data plane живёт небольшой набор двусторонних control-сообщений на выделенном QUIC-стриме, которые обмениваются между каждой соседней парой MoQ-эндпоинтов (publisher↔relay, relay↔relay, relay↔subscriber).

Изначальная «pull»-модель subscribe-driven: подписчик шлёт SUBSCRIBE с namespace + track name + фильтром (latest group, диапазон group, абсолютный старт), издатель отвечает SUBSCRIBE_OK и потоком медиа-объектов. SUBSCRIBE_UPDATE позволяет подписчику сузить окно; UNSUBSCRIBE рвёт подписку. Relay поддерживают forest подписок: подписка каждого нижестоящего подписчика сворачивается в одну upstream-подписку relay к издателю – это и есть механизм subscribe-as-aggregation.

Более новая «push»-модель, добавленная в недавние редакции draft-а, publish-driven: издатель шлёт PUBLISH на relay ещё до того, как кто-либо подписался, relay отвечает PUBLISH_OK, и объекты начинают течь в его кэш – так что первый подписчик попадает уже на тёплый кэш. Это та модель, которую production-развёртывания, особенно live-event-вещание, обычно предпочитают: relay начинает тянуть данные, не дожидаясь первого зрителя.

ANNOUNCE даёт издателю возможность сообщить relay «я владею этим namespace; ожидайте имена треков под ним», ещё не публикуя данных; relay может затем анонсировать namespace на вышестоящие relay, чтобы маршрутизировать подписки. FETCH – недавнее добавление для каталог-стилевого извлечения: «отдайте мне последние N групп этого трека». Именно FETCH делает возможным VOD-replay поверх MoQ без переархитектуры под HLS-манифесты. GOAWAY позволяет relay или publisher красиво сбросить соединения.

Control plane намеренно мал и намеренно живёт на собственном QUIC-стриме, чтобы control-сообщения не блокировали медиа-объекты (и наоборот). Рабочая группа потратила несколько редакций draft-а, чтобы зафиксировать, какие сообщения обязательные, а какие – нет, и как relay должен отвечать, когда подписчик просит namespace, которого relay не владеет; именно поэтому draft уже прошёл 17+ ревизий.

Откуда берётся «менее 500 мс»

Заголовочное «sub-500 ms broadcast at million-viewer scale» – не маркетинг, а бюджет, который можно расписать. Возьмём живой 50 fps поток с 2-секундным GOP, закодированный с одним CMAF-чанком на кадр, опубликованный в relay-дерево глубиной в 2 хопа до зрителя. Бюджет задержки с цифрами:

• Encoder. Один кадр приходит каждые 20 мс. CMAF-packager закрывает чанк (moof+mdat) как только encoder отдаёт slice. Современные железные encoders закрывают чанк за 10–30 мс после завершения кадра. Итого: 30–50 мс от съёмки кадра до закрытия чанка.
• Публикация в ingest relay. Publisher пишет чанк как один MoQ-объект на live subgroup QUIC-стриме. Ingest relay получает его за один RTT плюс время по проводу. По fibre-uplink это 5–20 мс.
• Relay → relay. Дерево из 2 хопов добавляет ещё один inter-relay leg – обычно 5–50 мс по backbone-пути. Развёртывание Cloudflare в 330+ городах ставит большинство зрителей в 1–2 хопах от encoder-а.
• Relay → viewer. Edge-relay пересылает объект на каждый subscriber-стрим, попросивший эту group. Edge → viewer: 10–100 мс в зависимости от access-сети.
• Player jitter buffer. Плеер держит маленький jitter buffer, чтобы один задержанный объект не вызвал stall. Агрессивно-низколатентные MoQ-плееры идут с 100–250 мс буфером – гораздо меньше, чем 1–3-секундный HLS-эквивалент, потому что per-stream priority + datagram drop в MoQ структурно снижают риск stall.

Суммируя по same-region wired-пути: 30 + 10 + 20 + 30 + 150 = около 240 мс. Через регионы с transatlantic-хопом в дереве: +100 мс на каждый transatlantic RTT, итого 340–440 мс. «Sub-500 ms» – это достижимо на реальных production-развёртываниях; «400 мс», заявленные на демо Cloudflare + Bitmovin на NAB, согласуются с этой арифметикой.

Сравним с WebRTC-доставкой того же контента. WebRTC даёт около 300 мс glass-to-glass на чистом same-region-пути, но каждый зритель требует SFU-сессии – один RTT на сигналинг и per-viewer state на SFU. MoQ даёт сопоставимую цифру при том, что relay stateless относительно зрителей. Сравним с LL-HLS: спецификационный пол LL-HLS – 2 секунды на join (один part-fetch + один partial-segment + 3-part буфер); медиана в продакшене – 3–5 секунд. MoQ механически ниже, потому что join – это один round-trip до ближайшего relay, а не fetch манифеста + ожидание segment-boundary.

Нажмите, чтобы увеличить

Рисунок 3. Четыре модели доставки на одной диаграмме бюджетов задержки. MoQ занимает 400 мс через one-RTT-подписки и плеер с маленьким буфером; relay-модель сохраняет эту задержку при масштабировании до миллионов зрителей.

Relay – где архитектура MoQ обыгрывает и WebRTC, и HLS

Relay – это та единственная архитектурная находка, которая оправдывает существование протокола. Если убрать абстракции, MoQ-relay – процесс, который:

1. Принимает QUIC-соединения от publishers и нижестоящих subscribers.
2. Поддерживает набор подписок – как собственные подписки к upstream relay или publisher, так и подписки своих нижестоящих subscribers.
3. Aggregates: когда N нижестоящих зрителей хотят один и тот же трек, relay держит ровно одну upstream-подписку к publisher и фанаут-ит входящие объекты всем N подписчикам.
4. Caches: когда приходит объект, relay держит его в памяти (опционально на диске), чтобы новый subscriber, появившийся через один-два RTT позже, получил warm hit вместо ожидания следующего объекта от upstream.
5. Re-prioritises: relay переотображает приоритет объекта от upstream на downstream QUIC-стрим, чтобы локальные congestion-решения отражали потребности каждого downstream.

Свойства 1–3 – это то, что механически делает HLS CDN edge. Свойства 4–5 – это то, что делает WebRTC SFU. MoQ – первый протокол, чей relay делает обе работы в одном процессе. Это и есть инженерное утверждение, ради которого MoQ воспринимают всерьёз: один однородный middlebox обслуживает и «дёшево фанаут до 10 миллионов зрителей» как у CDN, и «сохранение sub-second задержки с приоритетом и partial reliability» как у SFU.

В развёртывании Cloudflare relay – это moq-rs, та самая open-source-реализация на Rust, которую Cloudflare выпускает под MIT/Apache-2.0. Relay-узлы крутятся на каждом сервере в каждом дата-центре Cloudflare – на тех же машинах, что обслуживают HTTP/3 и Cloudflare Workers – и используют Durable Objects, чтобы координировать межрегиональное состояние (publisher, анонсирующий в Лондоне, делает namespace доступным для subscriber-а в Сингапуре). Первая MoQ CDN, анонсированная Cloudflare в середине 2025 и масштабированная в течение 2025 – начала 2026, работает в 330+ городах. NAB-демо Norsk 2026 публиковало именно в эту relay-сеть и отдавало sub-second-задержку зрителям в нескольких регионах через неё.

Существуют и другие production-реализации relay. Red5 поставляет managed MoQ relay через партнёрство с CacheFly (анонсировано в феврале 2026). Wowza показала на NAB 2026 Wowza Streaming Engine origin, публикующий CMAF-чанки через CMSF прямо в relay-as-CDN – либо собственный, либо партнёрский. Несколько академических прототипов (MOQtail, статья о DiVA) реализуют relay на Rust и Go для бенчмаркинга. Стоимость базового relay невелика – relay-бинарь moq-rs – это несколько тысяч строк Rust поверх quiche. Сложность – в операционном укреплении: congestion-control при сотнях нижестоящих подписчиков, fair-queueing под нагрузкой, защита от DoS (для которой существует отдельный draft draft-englishm-moq-relay-dos).

Нажмите, чтобы увеличить

Рисунок 4. WebRTC fan-out, HLS fan-out и MoQ fan-out на одном и том же контенте. Relay в MoQ – первая форма middlebox, объединяющая WebRTC-priority и low-latency-поведение с stateless-cache-per-viewer-масштабом HLS.

Частая ошибка – «MoQ заменит WebRTC»

Удивительно большая доля vendor-разговоров 2026 года намекает, что MoQ заменит WebRTC. Это не так, и сама рабочая группа этого не утверждает. Два протокола решают разные задачи и блестящи в разных вещах.

WebRTC спроектирован под двустороннее, peer-driven, browser-native медиа с задержкой sub-300 мс, где каждый участник одновременно и отправитель, и получатель. Видеозвонки, конференции, голосовой чат, peer-to-peer screen sharing – это территория WebRTC и она ею останется, потому что сигналинг, NAT traversal, echo cancellation, jitter buffer и bandwidth estimation WebRTC настроены под небольшое число peer-ов, обменивающихся обоими направлениями медиа в реальном времени. У MoQ нет двусторонней peer-модели: он publish-and-subscribe, одно направление на track, спроектирован под one-to-many или few-to-many.

MoQ спроектирован под one-to-many или one-to-very-many sub-second-вещание, где отправителей мало (encoder-ы), а получателей – тысячи и миллионы. Live-спорт, live-ставки, live-commerce, live-музыка, интерактивные игровые стримы, second-screen-опыты – это территория MoQ, те use case-ы, где per-viewer SFU-сессия WebRTC всегда была не той формы, а segment-aligned latency HLS всегда был слишком медленным.

Самая честная формулировка отношений в 2026 году: MoQ – дополнение к WebRTC, а не замена. Многие реальные production-стеки будут использовать оба – WebRTC для contribution-плеча (вебкамера стримера в платформу) и MoQ для distribution-плеча (закодированный выход платформы аудитории). Несколько демо NAB 2026 явно показывали этот гибрид: WebRTC publisher кормит MoQ relay tree, а relay делает протокол-трансляцию на edge.

Что уже стандартизовано, а что ещё двигается

Это первый вопрос любого CTO и тот вопрос, на который vendor-питчи отвечают уклончиво. Точная картина мая 2026 по документам:

draft-ietf-moq-transport. Базовый транспорт. Редакция -17 опубликована 2 марта 2026; редакция -latest опубликована 1 мая 2026, intended status Standards Track. Модель данных (tracks, groups, subgroups, objects), control-сообщения (SUBSCRIBE, ANNOUNCE, PUBLISH, FETCH, UNSUBSCRIBE, GOAWAY) и привязки к QUIC и WebTransport – всё сошлось. Рабочая группа обсуждает остаточные вопросы – точный формат расширений метаданных объекта, границы между SUBSCRIBE и PUBLISH flow-ами, как выражать приоритет через relay. Working Group Last Call ещё не объявлен; после него до публикации RFC остаётся 6–12 месяцев. Считайте wire-формат достаточно стабильным, чтобы под него писать; считайте абсолютные номера полей ещё потенциально изменяемыми.

draft-ietf-moq-msf. Слой streaming format. Редакция -00 опубликована в начале 2026, первый working-group MSF draft. Описывает catalog (как publisher анонсирует метаданные трека), timeline (как group связан с wallclock) и ABR-переключение на уровне streaming format. Ещё ранний; ожидайте значительной эволюции до RFC.

draft-ietf-moq-cmsf (и более ранний draft-wilaw-moq-cmsf). CMAF-over-MSF биндинг. Точно определяет, как CMAF init-сегмент становится catalog initData, как CMAF-фрагмент (moof+mdat) становится одним MoQ-объектом и как границы сегмента/GOP отображаются на границы group. Именно этот документ инженеры из CMAF-шопа читают, чтобы понять «как мне перевести существующий pipeline на MoQ». Инициатива LOCMAF (Low Overhead CMAF for MOQ, locmaf.dev) – отраслевое движение, пересекающееся с CMSF по тем же вопросам.

draft-ietf-moq-secure-objects. Редакция -00, working-group draft. End-to-end-шифрование объектов независимо от QUIC-канала – так, чтобы relay мог пересылать объекты, не имея права их расшифровывать. Это важно для use case-ов, где оператор relay не доверен с plaintext (например, когда relay – третья сторона CDN edge, а контент имеет жёсткую DRM-модель). Ранний; ещё не в production.

draft-englishm-moq-relay-dos и другие информационные draft-ы. Сопутствующие документы по операционным темам – защита от DoS, гайдлайны по топологии relay-сети, биндинг для ИИ-агентов. Не standards-track; полезное чтение для relay-операторов.

Честный итог по стандартизации: базовый транспорт сошёлся настолько, что production-развёртывания 2026 года отслеживают спеку плотно и потребуют только минимальных правок при переходе на финальный RFC. Слой streaming format – раньше по фазе и будет двигаться сильнее. Любая команда, строящая MoQ-продукт в 2026, должна следить за рассылкой moq-wg и пинить конкретную редакцию draft-а в своём коде, а не «latest».

Карта развёртываний 2026 – кто и что отгрузил

Таблица ниже суммирует покрытие MoQ в мае 2026 по платформам, которые streaming-продукт 2026 года, скорее всего, будет рассматривать. Важны три колонки: origin/encoder (может ли ваш contribution-pipeline выдать MoQ-трек), relay/CDN (может ли сеть пересылать MoQ на масштабе) и player (может ли устройство зрителя декодировать и отрисовать поток). «Draft tracked» – какую редакцию moq-transport упоминают публичные материалы вендора; mismatch требует interop-тестов.

Две вещи бросаются в глаза. Во-первых, сторона origin имеет самое широкое покрытие – у большинства encoder-вендоров к NAB 2026 уже был рабочий MoQ origin, потому что задача в основном «опубликовать CMAF-чанки как MoQ-объекты», что механически прямолинейно при наличии QUIC-стека. Во-вторых, сторона relay доминируется Cloudflare; второй эшелон (CacheFly, Oracle OCI, vendor-self-hosted relay у Norsk / Ant Media / Wowza) – реальный, но небольшой. Сторона player – самая фрагментированная: нативной поддержки в браузерах ещё нет (нет MoQ-aware video-элемента), поэтому каждый плеер сегодня – это JavaScript-движок поверх MSE или WebTransport, и каждый плеер несовместим с плеером другого вендора на уровне catalog / manifest, пока MSF и CMSF не стабилизируются.

Практический эффект этой карты: MoQ-развёртывание 2026 года выполнимо, если (а) ваш encoder-вендор в списке, (б) Cloudflare приемлем как relay-уровень или вы готовы держать собственные relay, и (в) ваша аудитория согласна на vendor-специфичный MoQ-плеер. «All-MoQ end-to-end» – это для определённого населения зрителей (ваше приложение, ваш embed, ваша ставочная платформа). Смешанные развёртывания, где MoQ – одно из нескольких distribution-плеч (MoQ для интерактивных зрителей, LL-HLS для остальных), – доминирующий production-паттерн.

Use case-ы – где MoQ действительно оправдывает переход

Кластер use case-ов, где MoQ объективно лучше альтернатив, уже не такой узкий, как кажется по маркетингу, но и не такой широкий, как звучит в питчах. Честная формулировка: MoQ выигрывает там, где нагрузка комбинирует broadcast-масштаб с требованием sub-second-задержки, которое не вытягивает LL-HLS, и где per-viewer SFU-модель WebRTC слишком дорога. В грубом порядке чистоты кейса:

Live sports betting и iGaming. Зрителей – от тысяч до миллионов; терпимость к задержке – менее 500 мс, потому что коэффициенты двигаются быстрее картинки; готовность платить за любую архитектуру, надёжно дающую эту задержку. Несколько демо NAB 2026 целились именно сюда.

Live commerce и shopping-стримы. Sub-second – это разница между «зритель видит, как ведущий поднимает товар, и нажимает купить» и «зритель видит устаревший кадр и нажимает слишком поздно». Аудитория большая (тысячи на стрим); задержка – дифференцирующая фича продукта.

Live-аукционы. Ставка в финальные секунды аукциона должна быть видна аукционисту в пределах окна, что меньше секунды. Аудитория варьируется, но соотношение задержка/масштаб – на территории MoQ.

Second-screen-интерактивные опыты. Компаньон-приложение, синхронизирующее ставочный prompt, опрос или статистику с live-вещанием, должно ощущаться синхронным – а это sub-second. Аудитория broadcast-масштаба.

Большие интерактивные игровые стримы и концерты. Когда chat и реакции аудитории должны быть частью шоу.

Cloud gaming и удалённое продакшн. Где per-stream-приоритет и partial-reliability MoQ ближе к нагрузке, чем SFU-модель WebRTC.

Где MoQ не оправдывает переход в 2026:

• Стандартный VOD-просмотр. Задержка не важна; HLS и DASH дешевле, более совместимы, кэшируются лучше и поддерживаются на каждом устройстве.
• Линейный OTT, где 3–6 секунд приемлемо. LL-HLS и LL-DASH уже работают; замена на MoQ добавляет операционную сложность без headline-выигрыша.
• Видеозвонки и конференции. WebRTC – правильный ответ и им останется.
• Нагрузки, где аудитория не может поставить кастомный плеер. Нет нативной поддержки в браузерах – нужен JS-плеер вендора; если контекст развёртывания не позволяет, MoQ выпадает.

Честный контраргумент

Стоит всерьёз воспринять и противоположную позицию, публично проговорённую Tsahi Levent-Levi (BlogGeek.me) и другими. Сильная версия аргумента: WebRTC выиграл потому, что у него был новый use case (in-browser-видеозвонок), которого до протокола вообще не существовало – не было предыдущего решения, которое надо было сдвинуть. MoQ предлагается под use case-ы (live-вещание, sub-second), у которых уже есть решения (LL-HLS, WebRTC-доставка, HESP); выигрыш надо мерить против установленной базы, а не против пустоты. Реальность пяти-месячного 2026 года: vendor-анонсов стало больше, но production-POC, в смысле trafic-bearing развёртываний, где бизнес зависит от MoQ, – ещё редкие и небольшие по масштабу.

Это справедливо и стоит держать рядом с техническими достоинствами. Контр-контр-аргумент: интегрированная архитектура relay+CDN структурно дешевле, чем гонять WebRTC SFU на том же масштабе, а значит по мере зрелости экономика будет в пользу MoQ; стандартизация шла быстрее многих рабочих групп (17+ редакций за около трёх лет, ровным темпом). Но честная позиция в мае 2026: MoQ – самый интересный протокол в секции, и аргумент в его пользу достаточно силён, чтобы любая серьёзная стриминговая команда прочитала draft, прогнала туториал moq-rs и поняла архитектуру; и любая команда, для которой пол задержки в 500 мс откроет фичу продукта, должна гонять POC. Аргумент за замену работающего LL-HLS или WebRTC сегодня без конкретной latency-driven фичи – гораздо слабее.

Нажмите, чтобы увеличить

Рисунок 5. Когда выбирать MoQ в 2026. Только вопрос product-feature (sub-500 мс на масштабе) оправдывает переход; вопрос технического любопытства – не тот же самый вопрос.

Числовой пример – расчёт MoQ-развёртывания

Чтобы привязать архитектуру к цифрам, посчитаем рабочий пример: платформа live-ставок транслирует одно событие 100 000 одновременным зрителям, ladder из трёх видео-битрейтов (1080p 6 Mbps, 720p 3 Mbps, 480p 1,5 Mbps) плюс стерео-аудио 128 kbps, 2-секундный GOP, 50 fps.

Per-viewer bandwidth (типичная ABR-смесь с уклоном к середине): 60% на 720p + 30% на 1080p + 10% на 480p + 128 kbps аудио. Средний per-viewer битрейт: 0,6 × 3 + 0,3 × 6 + 0,1 × 1,5 + 0,128 = 3,728 Mbps ≈ 3,73 Mbps. Суммарный egress на edge: 100 000 × 3,73 Mbps = 373 Gbps.

В WebRTC-SFU-модели publisher пишет один раз в SFU, SFU фанаут-ит на 373 Gbps и держит 100 000 stateful-сессий. Каждая сессия – сигналинг, ICE, DTLS, SRTP-контекст, jitter buffer – допустим 5 KB worst-case, 500 MB памяти на relay.

В HLS CDN-модели publisher пишет один раз в origin, CDN фанаут-ит на 373 Gbps через stateless-кэши. Состояние сессии – почти ноль (TCP-соединение, несколько KB). Floor задержки – 3–5 секунд.

В MoQ-relay-модели publisher пишет один раз в relay-дерево, relay фанаут-ит на 373 Gbps через subscription aggregation; состояние каждой downstream-подписки маленькое (control-stream-указатель и таблица in-flight метаданных – около 200 байт), 20 MB памяти на relay на 100 000 зрителей. Target задержки: 400 мс.

MoQ-модель примерно в 25 раз эффективнее по памяти, чем SFU-модель (20 MB против 500 MB на 100 000 сессий), даёт HLS-сопоставимый scaling-профиль и приземляется в пределах 100 мс от задержки WebRTC. Это и есть арифметика, стоящая за MoQ-питчем. Egress-полоса одинакова во всех трёх моделях; разница – в стоимости middlebox, выполняющего фанаут, и в floor задержки.

Где здесь Фора Софт

Фора Софт строит видео-инфраструктуру с 2005 года – 239+ запущенных проектов в WebRTC, видеоконференциях, OTT, телемедицине, e-learning, видеонаблюдении и AR/VR. В 2026 наша работа всё чаще лежит на стыке WebRTC contribution и современной HTTP-доставки – той самой территории, на которую целится MoQ. Мы отслеживаем редакции draft-а moq-transport, гоняем внутренние POC на moq-rs для интерактивного низколатентного видео и консультируем клиентов в iGaming, live shopping и second-screen-спорте по тому, ждать RFC или переходить на vendor-tracked production-стек сейчас. Решение, как правило, упирается в то, насколько фича продукта требует sub-second-задержки; мы видели нагрузки, где ответ – «ждать», нагрузки, где «отгружать сейчас на Cloudflare + Bitmovin + vendor-плеер», и нагрузки, где «строить мост: WebRTC для contribution, MoQ для distribution, LL-HLS как long-tail fallback».

Частая ошибка – обращаться с MoQ как с HLS

Удивительно частый инженерный pitfall в ранних реализациях 2026 года: писать MoQ origin, который публикует один трек на CMAF-сегмент и одну group на сегмент, а потом спрашивать «почему задержка как у HLS?» Ошибка в гранулярности. В HLS сегмент – атомарная адресуемая единица; в MoQ ею является object, и CMAF-чанк внутри сегмента становится одним объектом. 2-секундный сегмент при 50 fps даёт 100 объектов на group – это та гранулярность, на которой per-object-priority, per-object-drop и per-object-cache-hit MoQ реально работают. Если схлопнуть все 100 чанков в один объект, получите HLS-овский segment-aligned latency обратно. CMSF draft в этом месте недвусмысленный: «тело каждого объекта должно содержать как минимум один Movie Fragment Box (moof), за которым следует Media Data Box (mdat)» – «как минимум один», то есть один – правильный ответ, а не все вместе.

Ключевые выводы

• MoQ – это publish/subscribe-транспорт поверх QUIC, организующий медиа как tracks → groups → subgroups → objects.
• Relay-модель объединяет WebRTC-SFU-стилевую subscription aggregation с HLS-CDN-стилевым stateless-кэшем.
• Цель – sub-500 мс broadcast на масштабе миллионов зрителей; production-развёртывания показывают 400 мс.
• draft-ietf-moq-transport-17 / -latest – текущая базовая спека, intended status Standards Track, пока не RFC.
• Cloudflare запустила первую MoQ CDN в 330+ городах; одиннадцать вендоров провели interop на NAB 2026.
• Production-fit 2026 года: live-ставки, live-commerce, аукционы, second-screen interactive – не стандартный VOD и не двусторонние звонки.

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

• HESP: HTTP-доставка с задержкой 400 мс и где она нужна
• WHEP: HTTP-egress для WebRTC
• QUIC: новый транспортный уровень

CTA

• Поговорить с инженером по стримингу – забронируйте 30-минутный scoping-звонок с нашей командой по дизайну MoQ POC, выбору вендоров и последовательности миграции.
• Посмотреть кейсы – почитайте, как Фора Софт строила low-latency live и интерактивный стриминг для клиентов iGaming, e-learning, телемедицины и OTT с 2005 года.
• Скачать MoQ Readiness Checklist – одностраничный чеклист архитектурных, вендорских и операционных вопросов, на которые нужно ответить перед запуском MoQ-пилота. Скачать (PDF).