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

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

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

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

Эта статья – каноническая справка для инженеров, основателей и продактов, которые в 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-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 со своим управлением потоком и без head-of-line-блокировки, а также datagrams для сообщений, которые вообще не требуют ретрансляции.

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

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

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

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

Рисунок 1. Стек MoQ от QUIC до приложения. Базовый транспорт – один документ; слой формата потоковой передачи и конечные защищённые объекты описаны в отдельных сопутствующих черновиках (draft-ах). Вместе они описывают, как live-edge CMAF преобразуется в MoQ на линии.

Модель данных – треки, группы, подгруппы, объекты

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

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

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

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

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

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

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

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

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

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

Потоки, датаграммы и почему MoQ выбрал QUIC

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

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

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

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

Есть и четвёртая, менее обсуждаемая причина – тот же транспорт использует HTTP/3. Это означает, что развёртывание MoQ делит инвестиции на уровне соединения – контроль перегрузки, ECN, эксперименты с BBR, защита от усиления – со всей экосистемой 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, именем трека и фильтром (последняя группа, диапазон групп, абсолютный старт), издатель отвечает SUBSCRIBE_OK и потоком медиаобъектов. SUBSCRIBE_UPDATE позволяет подписчику сузить окно; UNSUBSCRIBE разрывает подписку. Relay поддерживают «лес» подписок: подписка каждого нижестоящего подписчика агрегируется в одну upstream-подписку relay к издателю – это и есть механизм subscribe-as-aggregation.

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

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

Контрольная плоскость намеренно минимальна и работает на отдельном QUIC-стриме, чтобы сообщения управления не блокировали передачу медиа-объектов (и наоборот). Рабочая группа потратила несколько версий черновика на то, чтобы чётко определить, какие сообщения обязательны, а какие – нет, и как ретранслятор должен реагировать, если подписчик запрашивает пространство имён, которым ретранслятор не владеет; именно поэтому черновик прошёл уже более 17 ревизий.

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

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

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

Суммируя по проводным путям в пределах одного региона: 30 + 10 + 20 + 30 + 150 = около 240 мс. При переходе между регионами с трансатлантическим хопом в дереве маршрутизации добавляется по 100 мс на каждый RTT через Атлантику – итого 340–440 мс. Цифра «менее 500 мс» достижима в реальных production-развёртываниях; заявленные на демо Cloudflare + Bitmovin на NAB 400 мс согласуются с этой арифметикой.

Сравним с доставкой контента через WebRTC. WebRTC обеспечивает задержку около 300 мс «стекло к стеклу» при передаче в пределах одной зоны, но каждый зритель требует отдельной SFU-сессии – один RTT на сигнализацию и хранение состояния на SFU для каждого зрителя. MoQ даёт сопоставимую задержку, при этом ретрансляторы не хранят состояние относительно зрителей.

Сравним с LL-HLS: по спецификации задержка при подключении составляет 2 секунды (один запрос части + одна частичная часть сегмента + буфер из трёх частей); в реальных условиях в продакшене медиана – 3–5 секунд. MoQ технически ниже, потому что подключение требует лишь одного round-trip до ближайшего ретранслятора, а не загрузки манифеста и ожидания границы сегмента.

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

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

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

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

1. Принимает QUIC-соединения от издателей (publishers) и подчинённых подписчиков (subscribers).
2. Поддерживает набор подписок – как собственные подписки на upstream-ретранслятор или издателя, так и подписки своих подчинённых подписчиков.
3. Агрегирует: когда N подчинённых зрителей запрашивают один и тот же трек, ретранслятор поддерживает ровно одну upstream-подписку к издателю и рассылает входящие объекты всем N подписчикам.
4. Кэширует: при получении объекта ретранслятор хранит его в памяти (опционально – на диске), чтобы новый подписчик, подключившийся через один-два RTT, получил «тёплый» ответ, а не ждал следующего объекта от upstream.
5. Переопределяет приоритеты: ретранслятор сопоставляет приоритет объекта от upstream с downstream-стримом QUIC, чтобы локальные решения по управлению перегрузкой учитывали потребности каждого downstream-подписчика.

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

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

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

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

Рисунок 4. Сравнение WebRTC fan-out, HLS fan-out и MoQ fan-out на одном и том же контенте. Relay в MoQ – первая реализация middlebox, сочетающая приоритет WebRTC и низкую задержку с масштабируемостью stateless-кеша на уровне каждого зрителя, характерной для HLS.

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

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

WebRTC разработан для двустороннего, peer-ориентированного, встроенного в браузер медиа с задержкой менее 300 мс, где каждый участник одновременно выступает и отправителем, и получателем. Видеозвонки, конференции, голосовой чат, обмен экраном между пользователями – всё это сфера применения WebRTC, и она останется таковой, поскольку сигнализация, обход NAT, подавление эха, буферизация джиттера и оценка пропускной способности в WebRTC оптимизированы под небольшое количество участников, обменивающихся медиа в обоих направлениях в реальном времени. У MoQ отсутствует двусторонняя peer-модель: он работает по принципу «публикация-подписка», поддерживает однонаправленную передачу на трек и предназначен для сценариев one-to-many или few-to-many.

MoQ разработан для распространения «один ко многим» или «один к очень многим» с задержкой менее секунды, когда отправителей мало (энкодеры), а получателей – тысячи и миллионы. Прямые трансляции спорта, live-ставки, live-торговля, live-музыка, интерактивные игровые стримы, опыт использования второго экрана – вот сфера применения MoQ. Это те сценарии, в которых сессия SFU на каждого зрителя в WebRTC всегда была избыточной, а сегментированная задержка в HLS – слишком высокой.

Самая честная формулировка отношений в 2026 году: MoQ – дополнение к WebRTC, а не замена. Многие реальные production-стеки будут использовать оба протокола: WebRTC – для contribution-плеча (веб-камера стримера в платформу), а MoQ – для distribution-плеча (закодированный выход платформы аудитории). Несколько демонстраций на NAB 2026 явно показывали такой гибрид: WebRTC-паблишер подаёт поток в MoQ-ретрансляционное дерево, а ретрансляторы выполняют протокол-трансляцию на 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, а также способ выражения приоритета через relay. Working Group Last Call пока не объявлен; после него до публикации RFC останется 6–12 месяцев. Считайте wire-формат достаточно стабильным для разработки под него, но абсолютные номера полей пока могут измениться.

draft-ietf-moq-msf. Слой streaming format. Редакция –00 опубликована в начале 2026 года, первый черновик рабочей группы MSF. Описывает каталог (как издатель анонсирует метаданные трека), временную шкалу (как группа связана с реальным временем) и переключение ABR на уровне формата потоковой передачи. Ещё ранний; ожидайте значительной эволюции до 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, черновик рабочей группы. End-to-end-шифрование объектов независимо от QUIC-канала – так, чтобы ретранслятор мог пересылать объекты, не имея права их расшифровывать. Это важно для сценариев, где оператор ретранслятора не доверяет к тексту в открытом виде (например, когда ретранслятор – это CDN-узел третьей стороны, а контент защищён жёсткой моделью DRM). Пока что это ранняя версия; ещё не используется в продакшене.

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

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

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

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

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

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

Примеры применения – где MoQ действительно оправдывает переход

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

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

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

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

Second-creen-интерактивные опыты. Компаньон-приложение, синхронизирующее ставки, опросы или статистику с прямым эфиром, должно работать практически мгновенно – в пределах доли секунды. Аудитория масштабов вещания.

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

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

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

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

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

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

Это справедливо и стоит учитывать наряду с техническими достоинствами. Контр-аргумент против возражения: интегрированная архитектура relay+CDN структурно дешевле, чем масштабирование WebRTC SFU на тех же объёмах, а значит – по мере зрелости технологии – экономика будет на стороне MoQ. Стандартизация продвигалась быстрее, чем у многих рабочих групп: 17+ редакций за три года – стабильный, ровный темп.

Честная позиция на май 2026 года: MoQ – самый интересный протокол в секции, и аргумент в его пользу достаточно силён, чтобы любая серьёзная стриминговая команда прочитала draft, прошла туториал moq-rs и поняла архитектуру. Любая команда, для которой снижение задержки до 500 мс откроет новую фичу продукта, должна запустить POC.

Аргумент за полную замену работающего LL-HLS или WebRTC сегодня без конкретной latency-ориентированной фичи – гораздо слабее.

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

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

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

Чтобы привязать архитектуру к цифрам, рассмотрим рабочий пример: платформа live-ставок транслирует одно событие для 100 000 одновременных зрителей с использованием ladder из трёх видео-битрейтов – 1080p (6 Мбит/с), 720p (3 Мбит/с), 480p (1,5 Мбит/с) – плюс стереоаудио со скоростью 128 кбит/с, GOP длиной 2 секунды и частотой кадров 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 Гбит/с и обслуживает 100 000 stateful-сессий. Каждая сессия включает сигналинг, ICE, DTLS, SRTP-контекст и буфер джиттера – в худшем случае это занимает около 5 КБ, что в сумме даёт 500 МБ памяти на релей.

В модели HLS CDN издатель пишет контент один раз в origin, после чего CDN распределяет его на 373 Гбит/с через stateless-кэши. Объём состояния сессии – почти нулевой (TCP-соединение, несколько килобайт). Минимальная задержка – 3–5 секунд.

В модели MoQ-relay издатель пишет один раз в relay-дерево, после чего relay рассылает данные на 373 Гбит/с через агрегацию подписок; состояние каждой downstream-подписки минимально – указатель control-stream и таблица in-flight метаданных (около 200 байт), что позволяет использовать всего 20 МБ памяти на relay при 100 000 зрителей. Целевая задержка – 400 мс.

MoQ-модель примерно в 25 раз эффективнее по памяти, чем SFU-модель (20 МБ против 500 МБ на 100 000 сессий), обеспечивает масштабируемость, сопоставимую с HLS, и задержку, отличающуюся от WebRTC не более чем на 100 мс. Именно эта арифметика лежит в основе предложения MoQ. Выходная пропускная способность одинакова во всех трёх моделях; различия заключаются в стоимости middlebox, выполняющего фанаут, и в минимальной задержке.

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

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

Частая ошибка – воспринимать MoQ как HLS

Удивительно частая инженерная ошибка в ранних реализациях 2026 года: создавать MoQ-источник, который публикует один трек на CMAF-сегмент и одну группу на сегмент, а затем удивляться: «почему задержка такая же, как у HLS?» Проблема – в гранулярности. В HLS сегмент является атомарной адресуемой единицей, а в MoQ такой единицей выступает object, и CMAF-чанк внутри сегмента становится отдельным объектом. Двухсекундный сегмент при 50 кадрах в секунду даёт 100 объектов на группу – именно на таком уровне гранулярности реально работают приоритеты, отбрасывание и кэширование на уровне каждого объекта в MoQ. Если же объединить все 100 чанков в один объект, вы снова получите задержку, характерную для HLS с выравниванием по сегментам. CMSF-draft в этом вопросе однозначен: «тело каждого объекта должно содержать как минимум один Movie Fragment Box (moof), за которым следует Media Data Box (mdat)» – «как минимум один», то есть один – это правильный выбор, а не объединение всех чанков в один.

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

• MoQ – это транспорт publish/subscribe поверх QUIC, организующий медиа по иерархии: треки → группы → подгруппы → объекты.
• Модель ретрансляции объединяет агрегацию подписок в стиле WebRTC-SFU со stateless-кэшем в духе HLS-CDN.
• Цель – вещание с задержкой менее 500 мс при масштабировании на миллионы зрителей; в продакшене достигнуты показатели 400 мс.
• draft-ietf-moq-transport-17 / -latest – текущая базовая спецификация, предназначенная для статуса Standards Track, пока не стала RFC.
• Cloudflare запустила первую CDN на базе MoQ в 330+ городах; одиннадцать вендоров провели межплатформенную совместимость на NAB 2026.
• Продакшн-ориентированные сценарии 2026 года: прямые ставки, live-торговля, аукционы, интерактивные приложения для второго экрана – это не стандартный VOD и не двусторонние звонки.

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

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

CTA

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