谁有资格用 MOQ 构建产品？

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/moq-architecture-impact/

MOQ 与 “民主化媒体访问” 背道而驰。表面上可能看不出来，但 MOQ 的发展方向就是如此。

如果你常看这个博客，大概知道我对 MOQ 的看法，它是一个拿着解决方案找问题的东西，却要重新定义流媒体。退一步说，这组合挺有意思。MOQ 又花了三个月寻找问题，找到了几个新候选，同时也让我对 MOQ 的现状（炒作与现实之间的差距）有了更多洞察。然后，我们将触及核心：MOQ 走的是与 WebRTC 完全相反的路线。

开始之前先说一句，我认为 MOQ 会成功。它背后的工程投入是实打实的。成功将来自纯粹的意志力，而非真正的技术缺口。

让我们深入分析，以便更好地理解这一点。

核心要点：TL;DR

WebRTC 通过在每个浏览器中内置一个完整、有主见的媒体引擎，免费且持续维护，实现了媒体访问的民主化。
MOQ 的构建方式恰恰相反：CDN 必须对你的应用一无所知，这将媒体逻辑推入你自己的客户端代码。
这包括最难的部分，拥塞控制就是最明显的例子，MOQT 根本没有对此进行具体说明。
没有任何浏览器厂商计划为 MOQ 打造一个 libWebRTC 级别的等价物，而今天每个交付 MOQ 的团队本身就已经拥有深厚的媒体流媒体经验。
四年过去了，基于 MOQ 运行的终端用户服务数量为零，所以该问的问题是：你有没有人去构建它没有交付的那一半。

WebRTC 真正给了你什么

要理解 MOQ，让我们从我最钟爱的话题，从 WebRTC 开始。

WebRTC 大约在 2011 年进入我们的世界。我记得当时看着它，心里涌起一股温暖而模糊的感觉：我的世界即将天翻地覆。在那之前，我已经做了 13 年的信令和视频会议。WebRTC 釜底抽薪，用一个让我的工作变得多余和不必要的解决方案，把我脚下的地毯抽走了。

WebRTC 所做的，是绕开信令这个问题，以 libWebRTC 的形式提供了一个坚如磐石的现代媒体引擎实现。SRTP 那部分不错，但从来不是决定性因素。你真正得到的是一个完整的、有主见的打包方案：抖动缓冲区、拥塞控制、回声消除、丢包掩盖、音视频同步、设备处理。这些东西没有一个写在任何规范里。每一个决策都是别人替你做的，而你很可能会做出不同的选择。它免费提供，并且有人维护。

不仅如此，这一切都已经嵌入并随每一个现代网页浏览器一起发布。你还能要求什么呢？

所有这些美好之处民主化了实时通信和视频会议。

它把一个需要特定技能的职业，向大众敞开了大门。

我记得在最初的几年里，我收集和整理了一份使用 WebRTC 的厂商数据集。大多数都没有 VoIP 背景。大多数以一种我起初无法理解的、奇怪而创新的方式来处理所谓的视频会议 —— 在 VoIP 和视频会议领域摸爬滚打 13 年后，我就是知道事情不是这么做的。看来我错了。

那种民主化？它给我们带来了远程医疗初创公司。在自己平台里直接加入通话功能的 CRM 厂商，不需要第三方呼叫中心。开始交付 WebRTC 应用的网页代理公司。

民主化。

WebRTC 消除了准入壁垒。

MOQ 给了你什么

MOQ 不一样。它最初可能是作为一个流媒体规范起步的。从那以后，它变成了一个什么都往里装的怪物。

MOQ 给你一个带有发布 / 订阅模型的传输层。一个足够通用、可以通过通用 CDN 进行路由的东西。这就是它的全部意义所在。我们还希望它对直播内容和缓存内容都能做到这一点。

基于 MOQ 最大粉丝的说法，MOQ 的第一条规则是什么？直接去 moq-dev/moq 看：

规则 1：CDN 绝不能知道任何关于你的应用、媒体编解码器，甚至可用轨道的信息。[…] 不允许有业务逻辑。

加粗的词是原文里就有的，不是我加的。

传输层本身不允许有业务逻辑，所有中继服务器（=CDN）都必须是通用的，结果就是媒体控制和处理逻辑的每一块实现都发生在边缘，在你的应用里。不是浏览器自己的实现。是你。那东西是用 JavaScript 和 WASM 写的。

这不是明年或后年就能解决的问题。这也不是标准制定者在 MOQ 规范成熟后会去处理的事情。它从设计上就是这样的。

MOQ 的最大优势在于可以大规模部署通用 CDN，而其最薄弱的环节是完全无法在网络中进行优化或作为业务逻辑运行 —— 客户端实现需要绕过其通用中继 counterpart 的限制。

钥匙给你了。现在去为我们给你的这辆闪亮新车造发动机吧。

你最终需要自己写什么

这部分内容很丰富。答案是：相当多。而且不是你期望在网页应用里写的那种东西。更像是你期望一个扎实的媒体引擎去做的底层、琐碎的事情。但是……MOQ 不是那个东西。

挑战很多。相当多。这里有两个，对于一个自诩要在直播媒体流媒体领域取代 WebRTC 的规范来说，是相当尴尬的。

处理拥塞控制。这是 2022 年的一场讨论，关于如何处理拥塞控制。如何应对 bufferbloat 和潜伏在我们现代网络中的其他麻烦事。Reno、CUBIC、BBR、GCC 等想法都被提出来作为潜在建议。WebRTC 显然免费做到了这一点，而且做得相当好，算法不断改进和精心调优。然而……MOQ 的决定是什么？

“MOQT 不指定拥塞控制器，但在为基于 MOQT 构建的应用选择拥塞控制器时，有一些重要的属性需要考虑。”

白纸黑字写在规范上。

你把实现中最难的部分拿出来，不去为你的目标用户解决它，而是让他们自己去处理这个头疼的问题。凭什么呢？又不是说你来这里是为了解决真正的问题（只是为你预先存在的解决方案找问题罢了）。

（WebRTC 在信令上也做了同样的事，但那从来不是最难的部分。它解放了开发者，进一步民主化了 WebRTC 的潜在解决方案和对更广泛受众的可用性）

这个真的让我无言以对。

我再给你留一个。伟大的 MOQ 规范是一份源源不断的礼物，只要你稍微刮开它抛光的表面。

假设你想做复杂的视频会议。或者只是想把更多责任放在发布端，让它用 SVC 处理分层。用 MOQ 怎么做？

嗯…… 根据提出这个方案的人的说法，这是关于 “MOQT 实现不得不偏离草案的场景”。

你有一个草案，跟不上人们试图在它之上构建的所有场景。它太通用了，反而害了自己。

这两个规范的对比如下：

是的。MOQ 真的是切片面包之后最棒的东西。他们只是忘了往里放面粉。还有酵母。但它确实是切好片的。被切成了一片片虚无的薄片。

看看真正在构建它的是谁

推动 MOQ 的同一批公司也在构建它。这些拥有媒体流媒体经验的工程密集型团队：Cloudflare、Meta、Google、Red5、nanocosmos、WINK Streaming、Software Mansion……

没有任何一个交付了 MOQ 应用的团队不是带着深厚的媒体流媒体背景进来的，一个都没有。

在 WebRTC 领域呢？通才们从第一天起就超过了视频会议和 VoIP 人群。

欢迎回到 1998 年！

这就是我们想要的未来样子吗？

能解决这个问题的那一层并不存在

没有任何浏览器厂商计划提供更高级别的 MOQ API。浏览器给你 WebTransport 和 WebCodecs。现在自己去造东西吧。

缺失的是：一个 MOQ 版的 libWebRTC 之类的东西。我们已经有了多个 MOQ 传输工具包：moq-rs、red5-moqpub、moq-kit、moqtail、aiomoqt、moqtransport。

看看 Meetecho，Janus 背后的公司 ——Janus 是一个 WebRTC 媒体服务器，也是最早采用 WebRTC 的产品之一。其首席开发者 Lorenzo Miniero 刚刚通过 MOQ 直播了 IETF 自己的 MOQ 工作组会议，通过将 WebRTC 网关接入 MOQ，并手写浏览器播放器。以下是他对这段经历本身的评价：

“事实上，虽然浏览器基本上是理想的 MoQ 参与者（使用 WebTransport 和 WebCodecs），但我们不能依赖浏览器开箱即用地为 WebRTC 提供的媒体栈，我们必须从零开始写一个，伴随这带来的所有痛苦和不幸。”

哎呀。

而我还以为 MOQ 会把我从 WebRTC 的所有痛苦和不幸中解放出来，结果却掉进了更多的痛苦和不幸。恰恰是 WebRTC 已经解决了的那种。

与此同时，MOQ 被提议用于一切

去读读关于 MOQ 建议用途的资料吧。它是互联网上一切的银弹。这不会让它走得太远。它最终会像 IPv6 一样，30 年后我们大多数人还是不会用它。我在一月份的 WebRTC Insights 里正是这么写的。八周后，Cisco、Google 和 Five9 提交了一份草案，把 JSON-RPC 放在了媒体传输上。

这是 2026 年的互联网万能药。我这儿有一瓶给你，包治百病。

MOQ 到底是用来干什么的？我以为它的目的是用它来取代 HLS 和 MPEG-DASH，同时提供低延迟流媒体。

现在它成了万能传输层。

语音、视频、数据，一切。

想要一些有趣的用途吗？

与 MCP 通信（因为 WebSocket 太 2025 年了）。draft-jennings-ai-mcp-over-moq-00 作者是 Cullen Jennings（Cisco）、Ian Swett（Google）、Jonathan Rosenberg（Five9）和 Suhas Nandakumar（Cisco）。这个把 MCP 资源、工具、提示词和 Agent Skills 映射到 MOQT 对象上。这个没有音频。没有语音。没有 WebRTC。没有 SIP。没有 VoIP。没有流媒体。它是 JSON-RPC 借用了一个媒体传输层，因为 WebSocket 没有优先级或中继。

语音 AI 组件（这就是我们知道需要解决的问题）。Draft-liu-moq-live-agent-interaction-01 这个来自阿里巴巴。它把 ASR 转录文本、LLM token 和 TTS 音频映射到 MOQT 对象，支持话轮转换和打断。因为 WebRTC 数据通道太老土了。不禁让人好奇…… 这与 OpenAI 采用 WebRTC 及其连续流式方法所走的路相比会如何……

有人提到过拿着解决方案找问题吗？

这个解决方案的新问题

我们现在看到另一组问题在 MOQ 里找到了归宿。或者也许是 MOQ 在找下一个试图解决的问题。远程操作和机器人技术。这个领域与监控市场紧密相连，并且非常适合它。

这里有一些道理。一种认为这需要比 WebRTC 更快、更低延迟的观念。没有语音路径意味着不需要唇音同步。需要一个比 WebRTC 里的更激进、更没耐心的抖动缓冲区。

问题是，为了达到这个目标，我们正在从零开始构建整个协议栈。同一个栈，只做了微小的调整。通过 WebRTC 的标准化和实现流程，把它弄进 libWebRTC，难道不是更合理吗？OpenAI 就是这么做的，当他们需要更快的建立时间和更少的往返时。

重新发明轮子要令人满足得多。

那么这对你意味着什么

MOQ 是一项具有挑战性的技术。看似简单，没有活动部件。

一个由第三方为你安装和运营 CDN 的承诺（你好，Cloudflare）。其余的开箱即用，没有活动部件。甩掉 WebRTC 那套丑陋的机器和基础设施，把它抛在身后。

然而……

四年过去了，基于 MOQ 运行的面向终端用户的服务仍然是零。没有消费级的东西。没有企业级的东西。只有同一个圈子里的少数厂商在互相编写和炫耀演示。声称一些关于 WebRTC 的不真实的事情。

数据呢？Chrome 中的 MoQ 需要 WebTransport，所以这只是我们在下图中看到的一个子集：

与 WebRTC 相比，这就是噪音。

MOQ 目前是 draft-19，148 页。线上格式仍未确定。

Red5、Cloudflare、nanocosmos 等都已经交付了 MOQ。Red5 在四月份正式 GA，几个月前我还公开质疑过。在 NAB 2026 上，他们展示了这个东西的互操作性：Bitmovin 的 Player Web X 从 Cloudflare 的中继网络拉取直播流，Ateme 编码进入 Oracle 的中继架构，展场上有十几家厂商在运行某种版本的 MOQ。

我的挑战算是被接住了。

只是圈子外有人接住了它。Nimble Ape 在六月份通过 MOQ 直播了 CommCon 2026：使用带 moq-obs 插件的 OBS，接入 Cloudflare 的中继，再进入他们自己写的浏览器播放器。该插件目标是 draft 15 及以上。Cloudflare 的中继在 draft 14 上。没有 FETCH，没有 SUBSCRIBE_NAMESPACE，这导致 VOD 和回放功能失效，并使调试更加困难。音视频同步漂移，需要重启流。音频卡顿。仅限 Chrome，因为 MediaStreamTrackGenerator 是将解码后的帧送入 video 元素的唯一方式，而 Safari 没有这个。他们自己的结论是：”一个概念验证，不是一个可用于生产的播放器。”

而这句话应该印在每一本 MOQ 宣传册的内封面上：”这些是每个流媒体栈内部都会做的事情，我们通常认为理所当然…… 在 MOQ 的这个阶段，你得自己交付它。”

四月份有十几家厂商在展场上展示了他们的演示。六月份，一个有能力的工程师把 OBS 接到公开的 Cloudflare 中继上，就撞上了草案版本的墙。

MOQ 采用的最大问题

我认为正在改变的是厂商的采用问题。

我们不应该问 “我应该为我的服务使用 MOQ 吗？它适合我应用中的交互部分吗？它能适应分发路径，取代 HLS 吗？”

需要问的是这个：”我们有没有人去构建 MOQ 没有交付的那一半？”

而且不。Vibe coding（凭感觉写代码）到不了那里。2026 年不行。让 Claude 读 WebRTC 的规范，然后用 WebAssembly 替你实现，这样你就可以在浏览器之上使用它 —— 听起来不错，但会惨败。今天大多数挑战不在于逐字重新实现规范。而在于理解网络、设备和用户行为如何塑造交互。尤其是在边缘情况下。尤其是在现实世界中。

你在这里交换的，是倾注到 WebRTC 实现中的大量真实生活经验，换来一个闪亮的新工具。

在 2026 年，我们正在从向大众民主化媒体访问，转向把这个领域的钥匙交到少数人手中。这真的是我们想做的吗？这叫进步吗？

要选择 MOQ？问问自己这两个问题：