Media over QUIC 的现状 — 规范停在 draft-19，最大规模部署停在 draft-07，最初提案人转投 moq-lite

引言 — 明天维也纳的 IETF 126 就要开幕
MOQT 是什么 — 把 pub/sub 下沉到传输层的设计
规范的现状 — 线路格式每两个月就变一次
现实检验一 — 最大的中继停在 draft-07
现实检验二 — 最初提案人的分支，moq-lite
那现在可以放弃 WebRTC 了吗 — 不行
判断 — 什么时候该看，什么时候该等
结语
参考资料

引言 — 明天维也纳的 IETF 126 就要开幕

明天(2026 年 7 月 18 日)起，IETF 126 将在奥地利维也纳召开。看议程会发现，Media over QUIC(MoQ)工作组把会议排在了 7 月 20 日(周一)、23 日(周四)、24 日(周五) — 一周之内多达三场。而在十一天前的 7 月 6 日，核心文档 draft-ietf-moq-transport 更新到了第十九个修订版(-19)，这是一份 149 页的文档。

一边标准化进行得如火如荼，另一边部署的现实却停在一个微妙的位置。今天互联网上任何人都能接入的最大 MoQ 中继 — Cloudflare 于 2025 年 8 月开通的那个 — 仍然固定在 draft-07 子集上。而这个协议 -00 修订版的第一作者 Luke Curley，现在正在另外维护一个叫 moq-lite 的分支。

规范走到了哪一步、部署实际停在哪里、这道落差说明了什么 — 这三点我都用一手信源(datatracker 元数据、草案原文、厂商文档)核实并梳理如下。

MOQT 是什么 — 把 pub/sub 下沉到传输层的设计

MOQT(Media over QUIC Transport)是运行在 QUIC 和 WebTransport 之上的发布/订阅协议。照搬 -19 摘要的原话，它利用 QUIC 的流、数据报、优先级、部分可靠性(partial reliability)，既能点对点工作，也能经过中间中继工作，以此追求可扩展的低延迟传输。还有一句有意思的话 — "尽管名字里带着 media，MOQT 实际上与媒体无关(media agnostic)，可以用于广泛的用例。"值得注意的是，工作组章程(2025 年 4 月修订)把范围定义为面向直播、游戏、媒体会议的媒体传输解决方案 — 也就是说文档自身的野心已经超出了它自己的章程。

数据模型是分层的。轨道(Track)里有组(Group)，组里有对象(Object)，组内的对象还可以打包成子组(Subgroup)。规范给出的例子很能说明设计意图 — 用一个有时间可扩展性(temporal scalability)的编解码器发送高/低分辨率视频时，按分辨率拆分轨道(让接收方按带宽挑选)，把可独立解码的图像序列映射成组(随机接入点=加入点)，把时间层映射成子组(带宽不够时优先级机制会优先保留下层)，一帧对应一个对象。

操作分三种。SUBSCRIBE 接收从现在起到达的对象(实时观看)，FETCH 请求过去的一段区间(回放、类 VOD 访问)，PUBLISH 是发布者无需等待订阅请求就主动推送的推送模型。得益于这个结构，中继无需理解媒体内容 — 不需要知道编解码器、容器，(按设计)甚至不需要知道端到端加密密钥 — 就能完成扇出和缓存。端到端密钥建立机制本身，章程明确把它划在了范围之外。

到这里为止，都是设计上的承诺。把 WebRTC 的低延迟交互性和 HLS/DASH 的 CDN 可扩展性合并进一套架构 — 这句话其实也是 Cloudflare 公告里的原话。问题从这里开始。

规范的现状 — 线路格式每两个月就变一次

从 datatracker 的提交记录看最近的修订节奏是这样的：

修订版	提交日期
draft-16	2026-01-13
draft-17	2026-03-02
draft-18	2026-05-12
draft-19	2026-07-06

大致每两个月一次，跟着 IETF 的会期走。重要的不是频率而是内容。读文档里的变更记录(附录 A)就会发现，到了这个阶段，线路格式和消息集合仍然在持续变动。

从 -18 到 -19(2026 年 5 月 → 7 月)，订阅新增了 Range Filter，一个轨道上允许同时存在多个订阅，PUBLISH_BLOCKED 消息改名为 PUBLISH_SKIPPED，此前允许中继重新排序或丢弃对象的例外条款被删除。再往前一步，从 -17 到 -18 的变化更大 — 统一了 moqt:// URI 方案，把 SUBSCRIBE_NAMESPACE 拆成了 SUBSCRIBE_NAMESPACE 和 SUBSCRIBE_TRACKS，删除了 PUBLISH_OK 消息类型(被并入 REQUEST_OK 的别名)，给 FETCH 响应引入了增量编码，还允许了 7 字节 varint。名字在变，消息在消失，编码在变化。截至 -19，控制消息从 SETUP 到 PUBLISH_SKIPPED 共有 18 种。

版本协商策略也值得了解。最终 RFC 的 ALPN 会是 moqt，但草案实现使用带草案编号的 ALPN，比如 moqt-19。而 -15 之前的所有草案都共用一个 ALPN——moq-00，版本协商在 SETUP 消息里完成。也就是说，不同的草案世代从 ALPN 字符串这一层就开始分道扬镳，除非服务器刻意同时实现多个世代，否则草案之间在结构上就不存在互操作性。

时间表目标是明确写出来的。工作组里程碑把传输协议(MOQT)和基于 Common Access Token 的认证的 IESG 提交定在 2026 年 12 月 31 日，把架在其上的 WARP 流格式、LOC 容器格式、Privacy Pass 认证定在 2027 年 3 月 31 日。目标日期终究只是目标日期，但至少工作组自己的计划是在今年年底前锁定底层协议。

现实检验一 — 最大的中继停在 draft-07

Cloudflare 于 2025 年 8 月 22 日宣布上线 MoQ 中继网络。按官方公告的说法，这是第一个由 330 多个城市的所有 Cloudflare 服务器共同充当中继的 MoQ 中继网络，任何人都可以在 relay.cloudflare.mediaoverquic.com 端点接入这个目前免费的技术预览。公告里也有"亚秒级"这类延迟数字，但那是厂商自述，测量条件明确的基准测试并未公开。

公告里真正重要的一句话是另一句。Cloudflare 的中继实现是 draft-ietf-moq-transport-07 的一个子集，用他们自己的话说，这个版本已经成为"多个开源项目之间事实上(de facto)的互操作目标"。为什么在上线时最新草案已经领先很多的情况下仍然停在 -07，Cloudflare 写得很坦率 — 与其不断追赶一个移动的靶子，不如就此停下，把力气花在中继网络本身的部署上。

这个状态延续至今。Cloudflare 的 MoQ 文档(2026 年 4 月 21 日更新)仍然明确写着支持 draft-07 子集。更有意思的是同一份文档里的 Known Issues 条目。Cloudflare 实现的子组头部里，多了一个 draft-07 里没有的 Subscribe ID 字段。

draft-ietf-moq-transport-07 的定义：       Cloudflare 实现实际收发的内容：

STREAM_HEADER_SUBGROUP Message {           STREAM_HEADER_SUBGROUP Message {
  Track Alias (i),                           Subscribe ID (i),      <- 多出来的字段
  Group ID (i),                              Track Alias (i),
  Subgroup ID (i),                           Group ID (i),
  Publisher Priority (8),                    Subgroup ID (i),
}                                            Publisher Priority (8),
                                           }

文档里写明这是从早期草案遗留下来的问题，将在后续版本中修复。也就是说，现在这个"事实标准"既不是 draft-07 本身，也不是别的什么，而是 draft-07 加上某一个具体实现的偏差。这就是 2026 年 7 月、标准化第四年的这个协议的互操作现实 — 公告里列出的互操作测试对象(Luke Curley 的 moq.dev、Lorenzo Miniero 的 imquic、Meta 的 Moxygen、moq-rs、moq-js、Norsk、Vindral)也都是照着这片 draft-07 附近的靶子对齐的结果。

把这个和前面规范一节看到的 ALPN 策略放在一起看，结论就很清楚了。如果照今天最新的规范(-19)去实现客户端，连唯一一个有规模的公开中继都连接协商不上。

现实检验二 — 最初提案人的分支，moq-lite

在 datatracker 上打开 draft-ietf-moq-transport-00(2023 年 7 月)会看到第一作者是 L. Curley(当时任职于 Twitch)。-19 的作者名单是 Cisco 的 Nandakumar、Google 的 Vasiliev 和 Swett、Meta 的 Frindell — 没有 Curley 的名字。他现在维护着一份个人草案 draft-lcurley-moq-lite，最新的修订版(-05)日期是 2026 年 6 月 30 日，一共 40 页。和 MOQT 的 149 页放在一起，这本身就是一种信号。

分支的理由在 moq-lite 草案的 Rationale 一节里写得异常直白。概括来说 — 他完全相信 MoQ 的初衷和潜力，但用委员会的方式设计这种实验性协议很难，MoqTransport 已经变得太复杂。消息太多，可选模式太多，半成品(half-baked)功能太多。标准化过程反而在阻碍实战中的实验，与其争论假设中的应用场景，不如把真正的应用做出来。所以 moq-lite 只保留了"想替代 WebRTC 的实时应用所需要的最低限度"，其余全部砍掉。像分组顺序(group order)这种连他自己都承认是好主意的东西，也被他以"等真正需要了再加"为由拿掉了，草案本身也直言不讳地写着"这份文档代表的是当前状态，而不是最终状态"。

看看它在结构上到底有多不一样：

数据模型是 Broadcast → Track → Group → Frame，没有 MOQT 那样的子组层级，对象(Object)也按媒体术语的习惯改名成了帧(Frame)。
双向流类型一共只有六种：Announce、Subscribe、Fetch、Track、Probe、Goaway。对比之下 MOQT 有 18 种控制消息类型。
但也有 MOQT 没有的东西 — -05 除了 QUIC、WebTransport 之外，还定义了 Qmux over TCP/TLS 和 Qmux over WebSocket，一共四种传输绑定。规范里内置了一条 TCP 回退路径，专门给 QUIC 被封锁的网络和没有 WebTransport 的浏览器(Safari)用。数据报只在 QUIC/WebTransport 绑定上受支持。

Curley 在 Cloudflare 上线次日写的《The First MoQ CDN》把这个立场表达得更露骨。按他的统计(截至 2025 年 8 月)，moq-transport 仓库已经积压了 650+ 个 issue、500+ 个 PR，他估计底层网络层要变成 RFC "至少还要 3 年"。他拿来对比的是 QUIC — Google 在 2012 年开始部署，2015 年开始标准化，RFC 在 2021 年才出来。而且 QUIC 当年有海量的生产数据可以用来打磨规范，MoQ 目前却还只有演示级别的使用经验。顺带一提，他称 Cloudflare 自己的中继代码是从他的 Rust 实现分叉出来的(这是他的说法，Cloudflare 的公告并未说明代码的来源脉络)。上线时没有认证、不支持 ANNOUNCE 因而无法做广播开始/结束的发现、Safari 不可用，这些局限也都在他的文章里列了出来。

归纳一下，今天的 MoQ 生态里存在两条路线。IETF 路线(MOQT，目标是 2026 年底提交 IESG)和 moq-lite 路线(个人草案 + 可运行的实现 + 他自己运营的一些演示)。两条路线共享概念和术语，但在线路层面并不兼容。

那现在可以放弃 WebRTC 了吗 — 不行

MoQ 阵营的目标本身确实是取代 WebRTC(moq-lite 草案就是这么明说的)。但截至 2026 年 7 月，还有三个理由让你现在还不能切换过去。

第一，浏览器覆盖率。MOQT 要求浏览器端具备 WebTransport，而 Safari 的 WebTransport 还不完整。按 Cloudflare 文档的梳理，Safari 只是从 18.4 版(2025 年 3 月 31 日)起，在开发者标志后面加入了一个早期的(尚未完全可用的)实现。同一份文档的结论也很说明问题 — 在 Safari 具备完整的 WebTransport 之前，部分 MoQ 用例必须回退到 WebRTC 或 WebSocket。只要还得回退到自己声称要取代的对象，那就不是取代，而是并存。

第二，运维成熟度。公开中继是一个没有认证的技术预览(不可猜测的路径名目前就等于访问控制)，而标准如上文所示，还处在消息名称都在变的阶段。视频会议、直播电商这类挂着 SLA 的流量，还不到往上放的阶段。

第三，一项悄悄跟过来的成本。用 QUIC 接收媒体，也意味着接收路径上的 CPU 成本结构和 TCP+TLS 不一样。这个话题我昨天已经在《QUIC 接收端 CPU 成本与尚未到来的内核 QUIC》一篇里用测量数据讲过了，如果要从服务端评估 MoQ，建议对照着一起看。

与此同时，今天的实时技术栈落在哪里，我已经另有文章梳理过 — WebRTC 媒体基础设施和 WHIP/WHEP 生态在《WebRTC 媒体基础设施 2026》一篇里，包含 WebTransport 在内的实时 Web 传输选项在《2026 年的实时 Web》一篇里。语音 AI 这类双向对话延迟就是生命线的技术栈今天为什么还架在 WebRTC 之上，也能和《AI 语音技术栈对比》一篇的语境衔接上。MoQ 要取代这些，标准得先定型，浏览器覆盖率得跟上，认证、计费这类运维功能也都得补齐，而这些目前一项都还没完成。

判断 — 什么时候该看，什么时候该等

现在就值得尝试的情况：

你直接拥有一条直播流水线(接入 → 扇出)，并且实实在在撞上了 WebRTC SFU 的扩展成本或 LL-HLS 的延迟下限。用免费的预览中继和开源实现，今天就能把概念验证做出来。
你对协议本身有利益关切 — 现在是反馈还能反映进规范里的最后一段窗口期。按工作组里程碑的计划，今年年底就要转交 IESG。

该等待的情况：

挂着生产 SLA 的媒体流量。没有认证的预览中继、每两个月就变一次的线路格式、草案之间不兼容 — 这三条里随便一条都足够成为理由。
需要包括 Safari 在内的全浏览器覆盖率的服务。没有 WebTransport 回退方案就没法开始。
需要拿"MoQ 的延迟比 WebRTC 好/差"作为决策依据的情况 — 目前还没有测量条件明确的公开对比数据。厂商公告里的延迟描述，应当当作营销文案来读。

结语

归纳一下：MOQT 规范已经走到 -19，工作组的目标是年内提交 IESG，但线路格式仍然随每个修订版而变动。与此同时，部署的重心停在 draft-07 附近 — 最大的公开中继停在那里，成了事实上的互操作目标，而这一份实现本身还带着已被写入文档的线路偏差。协议最初的提案人则运行着一份只有六分之一篇幅的分支，主张"实验应当先于标准"。

这幅图景与其说是失败的迹象，不如说更接近协议标准化过程中正常的阵痛 — QUIC 当年在部署和 RFC 之间也隔了九年。不过作为工程师的实用结论是明确的：今天的 MoQ 是一个值得观察和实验的对象，而不是一个可以直接迁移过去的对象。接下来值得盯住的两个节点是 — 下周 IETF 126 上 MoQ 会议的结果，以及 2026 年底 IESG 提交是否真的落地。