Media over QUIC — MoQ — это наиболее обсуждаемый новый протокол потоковой передачи 2025-2026 годов. Количество публикаций в блогах множится, доклады на конференциях накапливаются, а CDN-провайдеры наперегонки объявляют о его поддержке. Если вы работаете в области live-стриминга, вас наверняка уже спрашивали: стоит ли нам переходить на MoQ?
Краткий ответ для большинства продуктов, находящихся сегодня в продакшене: нет — пока нет. Но MoQ стоит изучить, потому что проблемы, которые он решает, реальны, а сроки его готовности к продакшену теперь измеряются кварталами, а не годами.
В этой статье объясняется, что такое MoQ на самом деле, каково его состояние на март 2026 года, что он меняет по сравнению с HLS, WebRTC и SRT — и имел бы он смысл для двух реальных продуктов, которые мы развернули: WeSpeakSports (аудиокомментарии болельщиков в реальном времени через WebRTC) и DJing Stream (DJ-аудио вещательного качества через SRT и HLS Lossless).
Что такое MoQ на самом деле
MoQ расшифровывается как Media over QUIC. Это инициатива рабочей группы IETF, начатая в 2022 году, по определению нового протокола доставки медиа, построенного поверх QUIC (транспортного уровня, лежащего в основе HTTP/3).
Основная транспортная спецификация, draft-ietf-moq-transport, достигла версии 17 в марте 2026 года. Спецификация формата потоковой передачи (draft-ietf-moq-msf) также находится в разработке, наряду с сопутствующими черновиками по упаковке CMAF и сжатию заголовков. Ни один из этих документов ещё не является финализированным RFC.
По своей сути MoQ — это протокол publish/subscribe. Издатель отправляет именованные медиаобъекты (аудиокадры, видеокадры, метаданные) на ретрансляторы, а подписчики получают их, подписываясь на именованные дорожки. Это фундаментально отличается как от HLS (HTTP-запрос/ответ для сегментов), так и от WebRTC (одноранговое согласование сессий через SDP/ICE).
MoQ работает поверх потоков и датаграмм QUIC, как нативно, так и через WebTransport (браузерный API для QUIC). Это даёт доступ к мультиплексированию, приоритизации и частичной надёжности QUIC — а значит, протокол может по замыслу отбросить запоздавший видеокадр, а не останавливать весь поток в ожидании повторной передачи.
Что MoQ стремится заменить
Как выразился Cullen Jennings из Cisco (участник рабочей группы MoQ), мир стриминга в настоящее время разделён на два лагеря. С одной стороны, сервисы вроде Netflix и YouTube доставляют медиа в масштабе через CDN на базе HTTP, но с задержкой в секунды. С другой стороны, инструменты конференцсвязи вроде Zoom и платформы на базе WebRTC доставляют медиа практически в реальном времени, но не могут экономически эффективно масштабироваться на большую аудиторию.
MoQ стремится объединить эти два мира единым протоколом, который может обслуживать как реальное, так и близкое к реальному времени использование — от вклада (приёма) через распределение (доставку зрителям) — с CDN-совместимой инфраструктурой ретрансляторов между ними.
Где MoQ находится сегодня (март 2026)
Давайте точно определим текущее состояние:
Спецификация близка к завершению, но ещё не готова. Транспортный черновик находится на версии 17 и быстро итерируется. Черновик формата потоковой передачи был опубликован в январе 2026 года. Ведётся активная сопутствующая работа над упаковкой CMAF и сжатием заголовков. Но ратифицированного RFC пока нет.
Разрыв с Safari/WebTransport сокращается. MoQ в браузере зависит от WebTransport, который требует HTTP/3 и QUIC. Chrome и Firefox уже поддерживают WebTransport. Safari был последним — но Apple добавила поддержку WebTransport в бета-версии Safari 26.4 (февраль 2026), и это официальное обязательство Interop 2026 от WebKit. По состоянию на март 2026 года это ещё не вышло в стабильном релизе Safari, но вопрос уже не будет ли — а когда в следующем цикле ОС. Для продуктов, нацеленных на пользователей iPhone и iPad через браузер, разрыв практически закрыт.
Ранние продакшен-развёртывания существуют, но ограничены. Nanocosmos продемонстрировала сквозную доставку MoQ (приём из OBS до глобальной аудитории) на MonteVIDEO Summer Project. Cloudflare запустила бета-версию MoQ. Red5 объявила о поддержке MoQ к концу 2026 года. Но это развёртывания ранних пользователей, а не массовая инфраструктура.
Сообщество честно оценивает зрелость. Даже Luke Curley, создавший одну из первых реализаций MoQ в Twitch (сейчас Discord) и написавший упрощённый черновик moq-lite, прямо заявляет, что полная транспортная спецификация MoQ «стала слишком сложной» с «слишком большим количеством сообщений, опциональных режимов и недоработанных функций». Его черновик moq-lite — это ответ на эту сложность.
Ветераны индустрии осторожны в оценках. Tsahi Levent-Levi из BlogGeek.me предсказал, что в 2026 году разработчики будут жаловаться больше на WebRTC, чем на MoQ — не потому что MoQ лучше, а потому что пользователи MoQ всё ещё являются ранними последователями, ожидающими шероховатостей. WebRTC — тот протокол, который повсеместно в продакшене и несёт на себе груз реальных ожиданий.
Что MoQ меняет по сравнению с HLS
HLS (HTTP Live Streaming) работает путём разделения медиа на сегменты, записи их на HTTP-сервер и опроса плеерами новых сегментов через плейлисты. Он зрелый, дружественный к CDN, широко развёрнутый и хорошо документированный в RFC 8216 и Apple HLS Authoring Specification. Low-Latency HLS (LL-HLS) снижает задержку примерно до 2-4 секунд.
MoQ меняет модель доставки несколькими способами:
От опроса к push-доставке. HLS-плееры запрашивают сегменты. Подписчики MoQ получают объекты по мере их публикации. Это устраняет задержку опроса.
От сегментов к объектам. HLS оперирует многосекундными сегментами (или частичными сегментами в LL-HLS). MoQ может оперировать на уровне кадров. Отдельный видеокадр или аудиокадр может быть индивидуально адресуемым, индивидуально доставляемым объектом.
От TCP к QUIC. HLS работает поверх HTTP/TCP. Когда пакет TCP теряется, всё позади него останавливается (блокировка начала очереди — head-of-line blocking). MoQ работает поверх QUIC, где потоки независимы — потерянный пакет в одном потоке не блокирует другие.
Явная приоритизация. Транспортный черновик MoQ определяет приоритет и порядок доставки на уровне протокола. При перегрузке ретранслятор может отбросить объекты с более низким приоритетом (например, B-frames), а не задерживать всё одинаково.
Единый приём и распределение. Сегодня большинство live-потоков используют один протокол для вклада (RTMP, SRT, WHIP) и другой для распределения (HLS, DASH). MoQ потенциально может обслуживать оба направления единым протоколом, устраняя этап переупаковки на сервере-источнике.
Когда HLS всё ещё выигрывает
Ничто из этого не означает, что HLS устарел. HLS остаётся более сильным выбором, когда:
- Задержка в несколько секунд вполне допустима
- Широкая совместимость с устройствами имеет критическое значение (каждый телефон, телевизор и приставка воспроизводит HLS)
- Существующие инвестиции в CDN и инструменты работают хорошо
- Операционная простота и проверенная временем надёжность важнее, чем снижение задержки
Для стандартной OTT live- и VOD-доставки — а это подавляющее большинство потокового трафика — HLS не сломан, и MoQ не решает проблему, которой не существует.
Что MoQ меняет по сравнению с WebRTC
WebRTC был спроектирован для одноранговой коммуникации в реальном времени: видеозвонки, демонстрация экрана, разговоры один на один или в малых группах. Индустрия растянула его далеко за пределы первоначального назначения, используя архитектуры SFU (Selective Forwarding Unit) для масштабирования WebRTC на более широкую аудиторию.
MoQ отличается от WebRTC несколькими важными аспектами:
Архитектура. WebRTC — это по сути сессионно-ориентированный одноранговый протокол, даже при посредничестве SFU. MoQ — это клиент-серверный протокол publish/subscribe, изначально спроектированный вокруг ретрансляторов и CDN-подобного распределения.
Модель масштабирования. Масштабирование WebRTC требует специально построенной и дорогой SFU-инфраструктуры. Ретрансляторы MoQ спроектированы для интеграции с существующей CDN-инфраструктурой — HTTP/3-серверы могут быть расширены для обработки MoQ-трафика, поэтому CDN-провайдеры вроде Akamai и YouTube активно вовлечены.
Сложность. WebRTC несёт значительную сложность: согласование предложения/ответа SDP, сбор ICE-кандидатов, STUN/TURN-серверы для обхода NAT, SRTP для шифрования, SCTP для каналов данных. Установка соединения MoQ проще — QUIC-рукопожатие с последующим обменом сообщениями subscribe/publish.
Гибкость кодеков. Согласование кодеков в WebRTC тесно связано с протоколом. MoQ агностичен к кодекам на транспортном уровне — формат медиа обрабатывается на уровне приложения (MSF, LOC или пользовательские контейнеры).
Зависимость от браузера. Оба протокола зависят от браузерных API для веб-доставки. WebRTC имеет универсальную поддержку браузеров. MoQ зависит от WebTransport, который Safari добавил только в бета-версии (26.4, февраль 2026) и ещё не выпустил в стабильной версии. Этот разрыв сокращается, но всё ещё остаётся практическим фактором для MoQ сегодня.
Когда WebRTC всё ещё выигрывает
WebRTC остаётся лучшим выбором, когда:
- Необходима истинная двунаправленная коммуникация в реальном времени (видеозвонки, конференцсвязь)
- Требуется совместимость браузеров на всех платформах, включая Safari/iOS
- Сценарий использования — одноранговый или в малой группе, без необходимости CDN-масштабного распределения
- Важны проверенные, готовые к продакшену инструменты и зрелость SDK
Что MoQ меняет по сравнению с SRT
SRT (Secure Reliable Transport) превосходно справляется с передачей высококачественного медиа из точки А в точку Б по ненадёжным сетям. Он обеспечивает шифрование AES, восстановление при потере пакетов через ARQ (Automatic Repeat Request) и поддержку адаптивного битрейта. SRT широко применяется в рабочих процессах приёма (камеры к студиям, удалённое производство к облачным энкодерам), а также служит протоколом двухточечной передачи — как демонстрирует DJing Stream.
MoQ и SRT служат пересекающимся, но разным целям:
SRT — двухточечный; MoQ — publish/subscribe. SRT соединяет одного отправителя с одним получателем. MoQ нативно поддерживает распределение «один ко многим» через ретрансляторы.
SRT гарантирует доставку; MoQ может отказаться от неё. Механизм ARQ в SRT повторно передаёт каждый потерянный пакет, что обеспечивает безпотерьную доставку, но добавляет задержку при потерях пакетов. MoQ может быть настроен на частичную надёжность — отбрасывая запоздавшие объекты вместо их повторной передачи — что лучше для живой доставки, чувствительной к задержке, но неприемлемо, когда важен каждый сэмпл.
SRT зрелый и развёрнутый; MoQ — новый. SRT имеет широкую аппаратную и программную поддержку (OBS, vMix, FFmpeg, Haivision, все основные энкодеры). MoQ имеет реализации на ранней стадии.
Когда SRT всё ещё выигрывает
SRT — более сильный выбор, когда:
- Сценарий использования — двухточечный (источник к энкодеру, энкодер к серверу-источнику или прямая доставка на площадку)
- Безпотерьная доставка важнее минимальной задержки
- Рабочий процесс включает профессиональное вещательное оборудование, которое уже поддерживает SRT
- Побитовая точность звука не подлежит компромиссу
Практический пример: WeSpeakSports — аудиокомментарии болельщиков в реальном времени через WebRTC
WeSpeakSports — это платформа живых аудиокомментариев болельщиков. Фанаты создают или слушают аудиокомментарии в реальном времени во время спортивных матчей — футбол, баскетбол, регби, Формула 1 и другие. Приложение доступно на iPhone, iPad, Mac (Apple Silicon) и Vision Pro.
Текущая архитектура использует WebRTC для аудиостриминга. Комментатор-болельщик транслирует аудио со своего устройства, а слушатели получают его практически в реальном времени. Аудио имеет качество голоса, а не музыки — разборчивость и низкая задержка значат гораздо больше, чем аудиофильская точность.
Имеет ли MoQ смысл для WeSpeakSports?
В теории — да, это отличное соответствие для данного сценария. WeSpeakSports — это живая аудиотрансляция «один ко многим» с требованиями реального времени. Это именно тот пробел, который MoQ призван заполнить: слишком много слушателей для эффективного масштабирования WebRTC, но слишком чувствительно к задержке для HLS.
Модель publish/subscribe в MoQ естественно накладывается на архитектуру WeSpeakSports: комментатор публикует аудиодорожку, слушатели подписываются на неё, а CDN-ретрансляторы обеспечивают распределение. Это было бы проще и дешевле масштабировать, чем инфраструктуру WebRTC SFU.
На практике — пока нет, по двум серьёзным причинам:
- Safari/iOS почти готов, но ещё нет. WeSpeakSports требует iOS 18.0. Основная аудитория приложения — на iPhone. MoQ в браузере зависит от WebTransport, который Apple добавила в бета-версии Safari 26.4, но ещё не выпустила в стабильном релизе. Даже для нативных iOS-приложений сегодня не существует готового к продакшену MoQ SDK для платформ Apple. Стек WebRTC на iOS (через встроенную поддержку WebKit от Apple и зрелые сторонние SDK) проверен и работает.
- Зрелость. WeSpeakSports — это выпущенный продукт с реальными пользователями. Замена транспортного уровня с проверенного протокола на спецификацию версии до 1.0 была бы преждевременной. WebRTC справляется с текущей нагрузкой. Стоимость сложности миграции не оправдана текущей пользовательской базой.
Когда стоит вернуться к этому вопросу
MoQ становится достойным оценки для WeSpeakSports, когда:
- WebTransport выйдет в стабильной версии Safari — что теперь неминуемо с учётом бета-версии Safari 26.4 — и появится зрелый нативный MoQ SDK для iOS/macOS
- Пользовательская база вырастет до масштаба, при котором затраты на WebRTC SFU станут значимым ограничением
- Инфраструктура MoQ-ретрансляторов станет доступной как минимум у двух CDN-провайдеров с обязательствами по SLA
- Транспортная спецификация MoQ получит статус RFC
В этот момент MoQ сможет существенно упростить архитектуру распределения и снизить стоимость на слушателя. Модель «комментатор → ретранслятор → слушатели» — это классический сценарий применения MoQ. Это вопрос времени, а не соответствия.
Практический пример: DJing Stream — DJ-аудио вещательного качества через SRT
DJing Stream — это приложение для macOS, спроектированное для очень специфического сценария: потоковая передача аудио вещательного качества с DJ-установки на звуковую систему площадки через интернет в реальном времени. Архитектура ставит качество звука выше всего остального.
Текущий стек использует SRT для распределения в реальном времени — доставляя 24-битный стерео PCM-звук с частотой 48 кГц (приблизительно 2,3 Мбит/с) с Mac диджея на звуковую систему площадки. Для более широкого распределения удалённым слушателям аудио также может передаваться через HLS с lossless-аудио. Вся философия проектирования заключается в том, что аудио диджея заслуживает той же точности, что и физическое кабельное соединение.
Имеет ли MoQ смысл для DJing Stream?
Нет — и это не вопрос времени. MoQ фундаментально не соответствует требованиям DJing Stream.
Вот почему:
- Безпотерьная доставка не подлежит компромиссу. DJing Stream передаёт несжатый PCM-звук. Каждый сэмпл важен. Механизм ARQ в SRT гарантирует доставку каждого пакета — он добавит задержку при потерях, но не отбросит аудио. Модель частичной надёжности MoQ, которая является одним из его ключевых преимуществ для live-видео, — это именно неправильный компромисс для аудио вещательного качества. Отброшенный аудиокадр — это слышимый щелчок на клубной звуковой системе. Это недопустимо.
- Двухточечная передача — основной сценарий. Базовый сценарий DJing Stream — один диджей стримит на одну площадку. Это двухточечная связь, а не задача распределения. Модель publish/subscribe с ретрансляторами в MoQ добавляет сложность без пользы для такой топологии.
- Браузер не нужен. DJing Stream — это нативное macOS-приложение, подключающееся к оборудованию площадки. В цепочке нет веб-браузера. Разрыв WebTransport/Safari не имеет значения, но и основное преимущество MoQ — нативная доставка через браузер — тоже.
- SRT уже является правильным инструментом. SRT был спроектирован именно для этого: надёжная, зашифрованная, низколатентная передача высококачественного медиа по ненадёжным сетям. Он проверен в вещательном производстве. Каждый энкодер и медиасервер поддерживает его. Замена SRT на MoQ для канала доставки «диджей → площадка» означала бы отказ от гарантированной доставки без какого-либо значимого выигрыша.
- HLS Lossless решает задачу распределения. Для вторичного сценария — распределения на более широкую аудиторию (веб-слушатели) — HLS с lossless-аудиокодеками проверен и совместим с каждым устройством. Допустимая задержка для удалённых слушателей выше, чем для самой площадки, поэтому сегментная модель HLS вполне адекватна.
Когда стоит вернуться к этому вопросу
Честно? Вероятно, никогда для основного канала «диджей → площадка». SRT делает именно то, что нужно DJing Stream, а цели проектирования MoQ (масштабируемое распределение с допустимой потерей качества при перегрузке) противоположны целям проектирования DJing Stream (безпотерьная доставка каждого аудиосэмпла).
Единственный сценарий, при котором MoQ мог бы стать актуальным для DJing Stream, — если продукт расширится в сторону масштабного распределения для фанатов с более низкими ожиданиями по точности — например, трансляция сжатой версии DJ-сета тысячам слушателей одновременно. Но даже тогда HLS или LL-HLS, скорее всего, останутся проще и шире совместимы.
Система принятия решений
После обширного исследования MoQ — черновиков IETF, отраслевых комментариев от Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho и Nanocosmos — вот простейшее правило принятия решений, которое я могу предложить:
Сохраняйте текущий стек, когда
- Ваш продукт уже в продакшене, и текущий протокол работает
- Вам нужна поддержка браузера Safari/iOS сегодня (WebTransport в бета-версии Safari, но ещё не в стабильной)
- Задержка в несколько секунд допустима (-> HLS/LL-HLS)
- Вам нужна гарантированная безпотерьная доставка (-> SRT)
- Вам нужна истинная двунаправленная коммуникация в реальном времени (-> WebRTC)
Начинайте оценивать MoQ, когда
- Сверхнизкая задержка для большой аудитории — ключевая ценность вашего продукта (ставки в реальном времени, аукционы, синхронизированный second-screen опыт)
- Вы контролируете весь стек от приёма до воспроизведения и можете интегрировать новый протокол
- Затраты на масштабирование WebRTC становятся реальной бизнес-проблемой
- Вы создаёте новый продукт, который не выйдет до конца 2026 или 2027 года
- Вы готовы принять, что спецификация может ещё измениться до получения статуса RFC
Внимательно следите за MoQ, если
- Вы управляете CDN или инфраструктурой ретрансляторов (MoQ спроектирован для работы с HTTP/3 CDN)
- Вы создаёте продукты для живого спорта с требованиями синхронизации
- Вы хотите объединить приём и распределение в одном протоколе
- Вас раздражают накладные расходы на переупаковку при приёме RTMP/SRT -> распределении HLS
Итог
MoQ реален, хорошо спроектирован и решает настоящие ограничения в сегодняшнем ландшафте протоколов потоковой передачи. Амбиция — один протокол для реального и близкого к реальному времени, от приёма до распределения, с поддержкой ретрансляторов CDN-масштаба — впечатляет.
Но амбиция — это не то же самое, что готовность. Спецификация не финализирована. Safari поддерживает WebTransport в бета-версии, но ещё не в стабильном релизе. Продакшен-развёртывания ограничены ранними пользователями. Экосистема SDK, инструментов и операционных знаний, которая делает HLS, WebRTC и SRT надёжными в продакшене, для MoQ пока просто не существует.
Для большинства стриминговых продуктов, выходящих в 2026 году, MoQ — это то, за чем нужно следить, а не то, что нужно внедрять. Когда он созреет — а он созреет — у него есть потенциал упростить архитектуры, которые сейчас сшивают несколько протоколов с промежуточными слоями переупаковки.
А пока: если HLS работает для вашей доставки — оставьте его. Если WebRTC работает для ваших задач реального времени — оставьте его. Если SRT работает для ваших двухточечных каналов — оставьте его. Лучший протокол — тот, который работает в продакшене, а не тот, который выглядит наиболее впечатляюще на слайде конференции.
Источники
- IETF MoQ Transport draft (v17, март 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite draft: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF Blog — What's the deal with MoQ: ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: How it will redefine realtime media: bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ by Use Case: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Apple HLS overview: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport commitment): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz