Media Over QUIC (MoQ) 缺乏令人信服的采用理由

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/moq-adoption-problem/
编译：小及狗

如今，Media Over QUIC(MOQ) 俨然成了舞会皇后。人人都在谈论它，似乎都对它很感兴趣。周围充斥着各种喧嚣和炒作，让人感觉如果不跟风，就会错失良机。作为一名“梦想粉碎者”，是时候对 MOQ 进行一番深入而严苛的审视了，并解释一下为什么我认为它不过是“为解决不存在的问题而存在的方案”。

这并非预言它不会成功。只是说，这幅拼图中缺失了关键的几块，导致它尚不完整。原因如下……

要点：简而言之

• MOQ 虽备受关注，却缺乏能展示其应用场景的标杆客户。
• 尽管供应商投入巨大，MOQ 面临的是市场问题而非技术挑战。
• MOQ 融合了现有协议的特性，但与 WebRTC、HLS 和 DASH 等成熟技术相比，其实际优势仍不明确。
• MOQ 要想取得成功，需要具备令人信服的应用场景、经过验证的性能，以及相较于现有解决方案的明显成本优势。
• 归根结底，MOQ 似乎是一个在市场上寻找真实痛点的解决方案。

为什么又要写一篇关于MOQ的文章？

2026 年 1 月，我曾预测 2025 年将是热议 MOQ 的一年，而 2026 年我们将开始看到其真正的概念验证（POC）。如今 2026 年已过去五个月，厂商的公告仍在持续发布，但概念验证却迟迟未见。

那篇文章是继一篇关于流媒体应用场景中 MOQ 的深度解析之后发表的。此后我与多人就 MOQ 进行了交流，上个月的 NAB 2026 展会上也有不少相关公告发布。其中一次对话让我深有感触，一位从事直播行业的人士，正在思考现在是否是投资 MOQ 的合适时机。他持怀疑态度，似乎想寻求认同。在交谈过程中，我突然意识到：MOQ 的问题并非技术层面的，而是市场层面的。

MOQ 仍处于起步阶段，市场上充斥着大量供应商的宣传声浪：

• Red5 发布了“Playa” MOQ 播放器以及由 CacheFly 驱动的 MOQ 中继网络，声称已获得六个独立播放器项目的联盟共识。
• Cloudflare的MOQ中继已在330多个数据中心上线，目前仍处于测试阶段，尚未公布任何旗舰客户。
• 在2026年NAB展会上，Wowza、Ant Media、AWS、Broadpeak、Nomad Media、Oracle、Norsk等公司展示了MOQ演示。其中大部分仍处于实验室阶段。
• IETF的MOQT草案于2026年3月更新至第17版。Sergio Garcia Murillo 指出，控制平面已从单个双向流重新设计为一对单向流——这是连续三个草案中的基础架构变更。
• 离开 Discord 加入 MOQ 团队的 Luke Curley，同时也是 IETF MOQT 规范草案的编辑之一，在其个人博客中写道：“不应将 MOQ 用于高质量内容。”

当一位从事 MOQ 工作的人公开告诉你“不该把 MOQ 用于什么”时，这值得我们停下来仔细思考。

客户确实会询问关于 MOQ 的问题。他们的提问方式总是千篇一律：“我们现在应该开始考虑这个问题了吗，还是为时过早？”这并非真正的需求驱动行为。这只是人们在寻求确认，以证明自己的怀疑是有道理的。

本文正是要探讨这一差距。

MOQ 的本质是什么

MOQ 的核心在于通过 QUIC 协议传输任意数据，其设计充分考虑了 CDN 和媒体流的应用。它与 HLS 和 MPEG-DASH 等其他网络流媒体技术有着相似或相同的互联网架构，因此能够很好地匹配。

这种对 QUIC 的改进使其在并行化数据流和兼顾低延迟与高质量数据方面具有巨大优势。

最终结果是将两种截然不同的协议/技术硬塞进了一个方案里。如果你想要延迟低于一秒，你需要使用 MOQ 中的特定指令集。如果你不太在意延迟，更注重质量，那么你就应该采用第二种方案。

对于 MOQ 来说，一切似乎都进展顺利，因为传输层（WebTransport）正在被所有现代浏览器原生支持。至于浏览器用例，目前也正在逐步完善。

这两种截然不同的协议/技术？它们正在两个不同的市场中争夺另外两种协议的关注度：

实时性，WebRTC 已胜出

如果你需要毫秒级的交互式视频，那么 WebRTC 就是最佳选择。作为一种协议，它甚至不会为了追求更高的画质而延迟传输，其核心宗旨是在保证足够良好的媒体质量的同时，为你提供尽可能低的延迟。就是这样，它几乎总是将延迟置于画质之上。

WebRTC 问世至今已逾十年，它解决了视频通话、会议、在线观影、云游戏、公共安全、无人机远程操控、呼叫中心、远程医疗等领域的技术难题……应用场景不胜枚举。

市场已经做出了选择。虽然有人对此颇有微词，但总体而言，WebRTC 表现稳健。其可靠性之高，甚至让 OpenAI 公开表示，他们在语音 AI 工作负载中大规模采用了该技术。

WebRTC 之所以存在，而MOQ却遥不可及，是有原因的。MOQ 缺乏 WebRTC 所具备的所有内置双向工具，例如 NACK 和抖动缓冲。正是这些细节使得 WebRTC 能够满足实时通信中所有相关的交互性需求。所有这些功能都是免费的，而使用 MOQ 时，你只能自己动手构建。

所谓自己构建？你会发现，这会带来许多人们对 WebRTC 抱怨的弊端。

就连公开支持 MOQ 的供应商，也明确指出其用途和实用性仅限于流媒体和直播。WebRTC 是双向的，而 MOQ 仅支持单向多点传输。

大家忽略的一点是，WebRTC 其实也支持直播，且已有供应商提供了成熟的解决方案。而针对 WebRTC 的抱怨（主要是价格问题）在 MOQ 上同样会存在，这是因为定价高度依赖带宽成本，而非缓存优化（直播中的缓存优化几乎不存在），而且， MOQ 在传输相同画质时，通过网络发送的数据量与 WebRTC 完全相同。

谁来承担这些额外的研发成本？

流媒体：HLS 和 DASH 已提供全面支持

那么说说流媒体。对于延迟超过几秒的内容，MOQ 可以取代 HLS 和 DASH 进行流媒体传输。

问题在于，所有这些 HLS、LL-HLS、DASH 和 LL-DASH 早已深入人心。CDN、ABR 梯度、DRM、广告插入、字幕、分析。每个环节都已得到解决并实现了商业化。

苹果、谷歌、奈飞，每一家大型广播公司都运行在这些系统之上。基础设施已收回成本，工具链已臻成熟，人才也易于招募。

MOQ 不仅需要在技术上出色，还必须足够优秀，才能取代那些已在全球范围内运行良好的系统。这一门槛远高于发布一份 RFC 的标准。

而且，要想取代这些技术，还有一个微不足道的前提：用户必须真正需要它。用 MOQ 取代 HLS 能给消费者带来什么？给广播公司带来什么？给 CDN 带来什么？对他们而言，选择 MOQ 而不是 HLS 的决定性因素是什么？

没有。

MOQ 实际上能改变什么，以及它无法改变什么？

让我们来面对现实。

MOQ 是一个很棒的协议，但它是否真正解决了现实生活中人们面临的实际问题？一个值得投入的、足够棘手的问题。

在单一传输层和协议上实现可调延迟是一个不错的解决方案。MOQ 通过在内部融合两种协议来实现这一点。目前尚无定论，究竟哪些 CDN 最终会同时实现这两种协议，还是会专注于其中一种。

在同一协议和会话中实现 200 毫秒到 5 秒之间的延迟滑动，是 HLS/DASH 无法做到的。按会话滑动的情况很少见。大多数产品会选择一个延迟目标并保持不变。组合方案则更有趣。目前，同时运营交互式（2秒以内）和直播（5秒）服务的运营商需要运行两个技术栈。MOQ 承诺仅需一个。但一个支持双模式的技术栈在运营成本上是否真能显著低于两个专用技术栈，这仍是个悬而未决的问题。我尚未看到有人就此公布具体数据。如果有相关文章，我很乐意阅读。

事实上，在网络传输过程中，这些数据包本质上是相同的，处理它们的 CPU 也大同小异。优化程度可能略有不同，但都无足轻重。

最明显的理论优势在于，由于 MOQ 基于 WebTransport（即在 QUIC 之上添加了JS API），因此无需TURN 协议，且信令与媒体传输合二为一。随着时间推移，当 HTTP/3 能够跨越网络、NAT 和防火墙时，MOQ 也能做到这一点。组件越少总是越好的。

但问题在于：运营商获得了这一优势。终端用户本来就看不到 TURN。网络性能的提升归功于基础设施的运营者，而非需求方。这正是供应商兴奋而客户却不买账的又一个原因。

但这足以引发技术变革吗？

推还是拉？

最近，MOQ 在市场上正被大力推广。

推动这一趋势的是一批声势浩大且信誉良好的供应商：Akamai、思科、YouTube、Cloudflare、谷歌（Shaka）、Bitmovin、Synamedia、Red5、CacheFly。这代表着真正的工程投入，与用户的需求是两码事。

需求端却缺失了。

这究竟是为谁服务的？最终受益的是谁？他们会为这项技术升级买单吗，无论是直接还是间接？标准制定过程似乎是由供应商在寻找突破口，而非由具体应用场景在寻找协议。

Cloudflare 是最典型的例子。他们已在 330 多个数据中心部署了 MOQ，却仍无法列举出一个旗舰客户。没有流量的基础设施，正是最响亮的信号，表明该协议是在找到用例之前就被推出。

这恰恰与 WebRTC 的发展路径相反。WebRTC 之所以出现，是因为浏览器和用例（零安装成本的视频通话）在同一时刻出现。应用开发者迫切需要它，以便在网页浏览器中支持他们的用例。他们无视以下事实：规范尚未完全标准化，各浏览器实现的规范存在差异，且不同浏览器实现之间存在互操作性问题。代码和应用程序仍被大规模部署到了生产环境中。

但 HTTP/3 同样也是由厂商推动的

此时一个合理的反例是 HTTP/3。浏览器和 CDN 推动它已有数年之久，但终端用户从未提出过需求。如今，它已承载了相当一部分的网络流量。为什么 MOQ 会不同呢？

机制。HTTP/3 的成功在于其升级对应用程序来说是透明的。浏览器、CDN 和源服务器负责处理这一切。应用程序开发者无需编写任何代码。终端用户从未察觉。它不仅在技术上更优，更解决了实际问题，这正是其价值所在。它提供了 HTTP/2 现有方案所缺乏的切实益处。

MOQ 并非无感升级。MOQ 需要应用层变更：播放器重写、编码器重构，以及媒体格式选择（WARP、LOC、CMSF 与 MSF，目前在 IETF 工作组中存在分歧）、发布/订阅模型以及命名空间设计。之所以存在六种独立的播放器实现，正是因为相关领域如此之大，以至于容易产生分歧。

HTTP/3 是一次传输层升级。MOQ 则是一种应用层协议。形态不同，采用曲线也不同。

MOQ 已获得厂商支持。但其具体应用场景仍在探索中。

什么能改变我的想法

以下是我从 MOQ 支持者那里听到的最有力反驳。当然，最终用户目前尚未采用 MOQ。该协议尚未作为 RFC 发布。供应商之所以会抢在需求出现之前就构建基础设施，是因为互联网协议向来如此。18 个月后再看吧。

这是一个合理的论点。但它并不适用于 MOQ 这一具体案例。

WebRTC 之所以胜出，是因为它提供了一种在协议出现前不存在的用例——零安装成本的浏览器内视频通话。而 MOQ 的提案针对的却是已经存在且已有成熟解决方案的用例。这属于不同的范畴。“预部署”的前提是该用例正在等待技术框架的支撑。但目前尚不清楚究竟有哪些用例是在专门等待 MOQ 的。

此外，18 个月的期限只有在 RFC 发布能够扫清采用障碍的情况下才有效。IETF MOQ 工作组自身的里程碑目标是在 2026 年 12 月之前将 MOQT 提交给 IESG。加上 IESG、IETF Last Call 和 RFC 编辑队列，实际的 RFC 发布日期应该在 2027 年末到 2028 年中。WARP 和 LOC 的目标是在 2027 年发布。即使考虑到等待时间，用户需求不足的问题也与标准化时间表无关。

我热爱科技。我认为 MOQ 在某种程度上确实独具匠心。在供应商的推动下，它最终很可能会取得成功。几年后，除了 MOQ 之外，流媒体服务可能就没什么其他可买了。这最终将成为推动行业发展的关键因素。

能否让这一进程来得更早、更快？当然可以。只需做到三点：

某家旗舰级消费级服务宣布大规模采用 MOQ 进行交付，占其流量的 30% 至 50%。YouTube Live、Twitch，或其他服务。选定一家，付诸实施，证明低延迟在消费级规模下确实至关重要。
针对相同内容，提供比 HLS/LL-HLS 更优的实际生产成本或性能数据；或者在相同交互性下，表现优于 WebRTC。而非来自供应商博客的基准测试数据。真实数据。流媒体服务通过现有技术无法实现的切实成本节约。我怀疑这些数据短期内难以浮出水面
一个能彻底突破 WebRTC 和 HLS/DASH 局限、且 MOQ 是唯一合理解决方案的应用场景。目前我无法举出这样的例子。如果你能举出，那正是我想读到的文章。

在那之前？MOQ 不过是“为了解决一个并不存在的问题而提出的解决方案”。