iR
iReplay.tv

Streaming Cost Optimizer

降低CDN成本，避免超额费用。按需付费流媒体分发。

免费试用

什么是MoQ，您的流媒体产品真的需要它吗？

• •
本文由AI从英文翻译而来。 阅读原文

Media over QUIC — MoQ — 是2025-2026年讨论最多的新兴流媒体协议。博客文章不断涌现，会议演讲层出不穷，CDN厂商也在争相宣布对其的支持。如果你从事直播行业，很可能已经被问过：我们应该切换到MoQ吗？

对于目前大多数正在运行的产品，简短的回答是不——还不行。但MoQ值得了解，因为它所解决的问题是真实存在的，而且它达到生产就绪的时间线现在是以季度来衡量，而不是年。

本文将解释MoQ到底是什么，截至2026年3月它的现状如何，与HLS、WebRTC和SRT相比它带来了哪些变化——以及对于我们已经部署的两个真实产品来说它是否有意义：WeSpeakSports（基于WebRTC的实时球迷语音评论）和DJing Stream（基于SRT和HLS无损音频的广播级DJ音频）。

MoQ到底是什么

MoQ代表Media over QUIC。它是IETF于2022年启动的一项工作组项目，旨在定义一种构建在QUIC（HTTP/3背后的传输层）之上的新型媒体传输协议。

核心传输规范draft-ietf-moq-transport于2026年3月发布了第17版。流媒体格式规范（draft-ietf-moq-msf）也在制定中，此外还有CMAF封装和头部压缩的配套草案。这些都尚未成为最终的RFC。

MoQ的核心是一种publish/subscribe协议。发布者将命名的媒体对象（音频帧、视频帧、元数据）发送到中继节点，订阅者通过订阅命名轨道来接收它们。这与HLS（基于HTTP请求/响应获取分片）和WebRTC（通过SDP/ICE进行点对点会话协商）都有本质区别。

MoQ运行在QUIC流和数据报之上，可以是原生方式，也可以通过WebTransport（浏览器的QUIC API）。这使其能够利用QUIC的多路复用、优先级和部分可靠性特性——意味着该协议可以在设计上丢弃迟到的视频帧，而不是让整个流等待重传而停滞。

MoQ试图取代什么

正如Cisco的Cullen Jennings（MoQ工作组参与者）所言，当前的流媒体世界存在两个孤岛。一边是Netflix和YouTube等服务通过基于HTTP的CDN大规模传输媒体，但延迟达数秒。另一边是Zoom等会议工具和基于WebRTC的平台以近实时方式传输媒体，但无法经济高效地扩展到大规模受众。

MoQ旨在用单一协议桥接这两个世界，能够同时服务实时和近实时的使用场景，从贡献（采集）到分发（传输给观众），中间以兼容CDN的中继基础设施连接。

MoQ的现状（2026年3月）

让我们精确描述当前的状态：

规范接近完成但尚未定稿。传输草案已到第17版，迭代迅速。流媒体格式草案于2026年1月发布。CMAF封装和头部压缩的配套工作正在积极推进。但目前还没有正式批准的RFC。

Safari/WebTransport的差距正在缩小。浏览器中的MoQ依赖于WebTransport，而WebTransport需要HTTP/3和QUIC。Chrome和Firefox已经支持WebTransport。Safari曾是落后者——但Apple在Safari 26.4 beta版（2026年2月）中添加了WebTransport支持，并且这是WebKit的Interop 2026官方承诺项目。截至2026年3月，这尚未在Safari正式版中发布，但问题已不再是是否——而只是在下一个系统周期中何时发布。对于面向iPhone和iPad浏览器用户的产品来说，这一差距即将弥合。

早期生产部署已经存在但规模有限。Nanocosmos在MonteVIDEO Summer Project中展示了端到端的MoQ传输（从OBS采集到全球观众）。Cloudflare推出了MoQ beta版。Red5宣布将在2026年底前支持MoQ。但这些都是早期采用者的部署，而非主流基础设施。

社区对成熟度持诚实态度。即使是Luke Curley——他在Twitch（现在在Discord）构建了最早的MoQ实现之一，并撰写了moq-lite简化草案——也明确表示完整的MoQ传输规范"已经变得过于复杂"，有"太多的消息类型、可选模式和半成品功能"。他的moq-lite草案就是对这种复杂性的回应。

行业资深人士态度谨慎。BlogGeek.me的Tsahi Levent-Levi预测，到2026年，开发者对WebRTC的抱怨会比对MoQ更多——不是因为MoQ更好，而是因为MoQ用户仍然是早期采用者，他们预期会有粗糙之处。WebRTC才是正在全面生产使用的技术，承受着真实世界的期望压力。

与HLS相比，MoQ带来了什么变化

HLS（HTTP Live Streaming）的工作方式是将媒体分割为分片，写入HTTP服务器，然后由播放器通过播放列表轮询新分片。它成熟、对CDN友好、广泛部署，在RFC 8216和Apple的HLS创作规范中有详细文档。低延迟HLS（LL-HLS）将延迟降低到大约2-4秒。

MoQ在多个方面改变了传输模型：

从轮询到推送。HLS播放器请求分片。MoQ订阅者在对象发布时即可收到。这消除了轮询延迟。

从分片到对象。HLS以多秒的分片（或LL-HLS中的部分分片）为单位操作。MoQ可以在帧级别操作。单个视频帧或音频帧可以是一个独立可寻址、独立可传输的对象。

从TCP到QUIC。HLS运行在HTTP/TCP之上。当TCP数据包丢失时，其后所有内容都会停滞（队头阻塞）。MoQ运行在QUIC之上，其中的流是独立的——一个流上的丢包不会阻塞其他流。

显式优先级。MoQ的传输草案在协议层面定义了优先级和传输顺序。在拥塞期间，中继节点可以丢弃低优先级对象（例如B-frames），而不是平均延迟所有内容。

统一采集和分发。如今，大多数直播工作流使用一种协议进行贡献（RTMP、SRT、WHIP），另一种协议进行分发（HLS、DASH）。MoQ有可能用单一协议同时服务两条路径，消除源服务器上的重新封装步骤。

HLS仍然更优的场景

这并不意味着HLS已经过时。在以下情况下，HLS仍然是更好的选择：

  • 几秒的延迟完全可以接受
  • 广泛的设备兼容性至关重要（每部手机、电视和机顶盒都能播放HLS）
  • 现有的CDN和工具投入运行良好
  • 运维简单性和久经考验的可靠性比降低延迟更重要

对于标准OTT直播和点播传输——这占了流媒体流量的绝大部分——HLS并没有问题，MoQ也不是在修复一个存在的问题。

与WebRTC相比，MoQ带来了什么变化

WebRTC的设计初衷是实时点对点通信：视频通话、屏幕共享、一对一或小组对话。业界已经将其远远扩展到了最初的范围之外，使用SFU（选择性转发单元）架构将WebRTC扩展到更大的受众。

MoQ与WebRTC在几个重要方面有所不同：

架构。WebRTC从根本上来说是一种面向会话的点对点协议，即使通过SFU进行中介也是如此。MoQ是一种客户端-服务器的publish/subscribe协议，从一开始就围绕中继和CDN式分发进行设计。

可扩展性模型。扩展WebRTC需要专门构建且成本高昂的SFU基础设施。MoQ中继节点被设计为与现有CDN基础设施集成——HTTP/3服务器可以扩展以处理MoQ流量，这也是Akamai和YouTube等CDN厂商积极参与的原因。

复杂性。WebRTC带有相当大的复杂性：SDP提议/应答协商、ICE候选者收集、用于NAT穿越的STUN/TURN服务器、用于加密的SRTP、用于数据通道的SCTP。MoQ的连接建立更为简单——一次QUIC握手，随后是subscribe/publish消息。

编解码器灵活性。WebRTC的编解码器协商与协议紧密耦合。MoQ在传输层面与编解码器无关——媒体格式由应用层处理（MSF、LOC或自定义容器）。

浏览器依赖。两种协议在基于Web的传输中都依赖浏览器API。WebRTC拥有通用的浏览器支持。MoQ依赖于WebTransport，而Safari直到beta版（26.4，2026年2月）才刚添加支持，且尚未发布正式版。这一差距正在缩小，但对于当前的MoQ来说仍然是一个实际考量。

WebRTC仍然更优的场景

在以下情况下，WebRTC仍然是更好的选择：

  • 需要真正的双向实时通信（视频通话、会议）
  • 需要跨所有平台（包括Safari/iOS）的浏览器兼容性
  • 使用场景是点对点或小组通信，不需要CDN级别的分发
  • 成熟的、生产级别的工具和SDK成熟度很重要

与SRT相比，MoQ带来了什么变化

SRT（Secure Reliable Transport）擅长在不可预测的网络上将高质量媒体从A点传输到B点。它提供AES加密、通过ARQ（自动重传请求）进行丢包恢复以及自适应比特率支持。SRT在采集工作流中被广泛采用（摄像机到演播室、远程制作到云编码器），同时也作为点对点分发协议使用——正如DJing Stream所展示的那样。

MoQ和SRT服务于重叠但不同的目的：

SRT是点对点的；MoQ是publish/subscribe的。SRT连接一个发送者和一个接收者。MoQ通过中继节点原生支持一对多分发。

SRT保证传输；MoQ可以选择不保证。SRT的ARQ机制重传每个丢失的数据包，确保无损传输，但在丢包情况下会增加延迟。MoQ可以配置为部分可靠性——丢弃迟到的对象而不是重传它们——这对延迟敏感的直播传输更好，但在每个采样都至关重要时则不可接受。

SRT已经成熟并投入部署；MoQ正在崛起。SRT拥有广泛的硬件和软件支持（OBS、vMix、FFmpeg、Haivision以及每个主要编码器）。MoQ目前只有早期阶段的实现。

SRT仍然更优的场景

在以下情况下，SRT是更好的选择：

  • 使用场景是点对点的（信号源到编码器、编码器到源站，或直接到场馆的分发）
  • 无损传输比绝对最低延迟更重要
  • 工作流涉及已经支持SRT的专业广播设备
  • 比特级音频保真度不可妥协

案例研究：WeSpeakSports——基于WebRTC的实时球迷评论

WeSpeakSports是一个实时球迷语音评论平台。球迷可以在体育比赛期间创建或收听实时语音评论——包括足球、篮球、橄榄球、F1等。该应用可在iPhone、iPad、Mac（Apple Silicon）和Vision Pro上使用。

当前架构使用WebRTC进行音频流传输。球迷评论员从其设备广播音频，听众近实时地接收。音频是语音质量而非音乐质量——清晰度和低延迟远比发烧级保真度重要。

MoQ对WeSpeakSports有意义吗？

从理论上说，是的——这个使用场景非常契合。WeSpeakSports是一种一对多的实时音频广播，有实时性要求。这恰好是MoQ旨在填补的空白：对于高效的WebRTC扩展来说听众太多，但对于HLS来说又太需要低延迟。

MoQ的publish/subscribe模型自然映射到WeSpeakSports的架构：评论员发布音频轨道，听众订阅它，CDN中继节点处理分发。这比WebRTC SFU基础设施更简单、更经济地扩展。

在实践中，还不行——有两个硬性原因：

  1. Safari/iOS几乎准备好了，但还没有。WeSpeakSports要求iOS 18.0。该应用的主要受众在iPhone上。浏览器中的MoQ依赖于WebTransport，Apple在Safari 26.4 beta中添加了支持但尚未在正式版中发布。即使对于原生iOS应用，目前也没有生产就绪的Apple平台MoQ SDK。iOS上的WebRTC栈（通过Apple内置的WebKit支持和成熟的第三方SDK）已经过验证并可正常工作。
  2. 成熟度。WeSpeakSports是一个已发布的产品，拥有真实用户。将传输层从经过验证的协议替换为1.0版之前的规范为时尚早。WebRTC正在处理当前的规模。迁移的复杂性成本在当前用户基础下并不合理。

何时重新评估

MoQ在以下条件满足时值得为WeSpeakSports进行评估：

  • WebTransport在Safari正式版中发布——鉴于Safari 26.4 beta的进展，这已经迫在眉睫——并且出现成熟的iOS/macOS原生MoQ SDK
  • 用户规模增长到WebRTC SFU成本成为真正的业务约束
  • 至少有两家CDN提供商提供带SLA承诺的MoQ中继基础设施
  • MoQ传输规范达到RFC状态

届时，MoQ可以切实简化分发架构并降低每个听众的成本。评论员到中继节点再到听众的模型是教科书式的MoQ用例。这是时机问题，而不是契合度问题。

案例研究：DJing Stream——基于SRT的广播级DJ音频

DJing Stream是一款macOS应用，专为一个非常具体的使用场景设计：通过互联网将广播级音频从DJ的设备实时流传输到场馆的音响系统。该架构将音频质量置于一切之上。

当前的技术栈使用SRT进行实时分发——以48 kHz的采样率将24位PCM立体声音频（大约2.3 Mbps）从DJ的Mac传输到场馆的音响系统。对于向远程听众的更广泛分发，音频也可以通过HLS无损音频提供。整个设计理念是DJ的音频应当拥有与物理线缆连接相同的保真度。

MoQ对DJing Stream有意义吗？

不——这不是时机问题。MoQ与DJing Stream的需求根本不匹配。

原因如下：

  1. 无损传输不可妥协。DJing Stream发送未压缩的PCM音频。每个采样都至关重要。SRT的ARQ重传机制保证每个数据包都能到达——在丢包时会增加延迟而不是丢弃音频。MoQ的部分可靠性模型——这是其在直播视频中的关键优势之一——对于广播级音频来说恰恰是错误的权衡。在俱乐部音响系统上，丢弃一个音频帧就是一次可感知的故障。这是不可接受的。
  2. 点对点是主要使用场景。DJing Stream的核心场景是一个DJ向一个场馆流传输。这是一个点对点链路，而非分发问题。MoQ的publish/subscribe中继模型为这种拓扑结构增加了复杂性却没有带来好处。
  3. 不需要浏览器。DJing Stream是一个原生macOS应用，连接到场馆硬件。整个过程中没有Web浏览器。WebTransport/Safari的差距无关紧要，但MoQ的主要优势——浏览器原生传输——同样也不相关。
  4. SRT已经是正确的工具。SRT正是为此而设计的：在不可预测的网络上可靠、加密、低延迟地传输高质量媒体。它在广播制作中久经考验。每个编码器和媒体服务器都支持它。用MoQ替换SRT作为DJ到场馆的分发链路，意味着放弃有保证的传输却没有获得任何实质性收益。
  5. HLS无损音频处理了分发端。对于向更广泛受众（网页听众）分发的次要使用场景，带无损音频编解码器的HLS已经过验证且兼容所有设备。远程听众对延迟的容忍度高于场馆本身，因此HLS基于分片的模型完全足够。

何时重新评估

说实话？对于核心的DJ到场馆链路，可能永远不需要。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 beta中但尚未正式发布）
  • 几秒的延迟可以接受（选择HLS/LL-HLS）
  • 你需要有保证的无损传输（选择SRT）
  • 你需要真正的双向实时通信（选择WebRTC）

在以下情况下开始评估MoQ

  • 面向大规模受众的超低延迟是产品价值的核心（实时博彩、拍卖、同步第二屏体验）
  • 你控制从采集到播放的完整技术栈，并且能够接纳一种新协议
  • WebRTC扩展成本正在成为真正的业务问题
  • 你正在构建一个要到2026年底或2027年才会上线的新产品
  • 你能接受规范在达到RFC之前可能仍会发生变化

在以下情况下密切关注MoQ

  • 你运营CDN或中继基础设施（MoQ被设计为与HTTP/3 CDN配合使用）
  • 你构建有同步需求的体育直播产品
  • 你希望将采集和分发整合到单一协议上
  • 你对RTMP/SRT采集到HLS分发之间的重新封装开销感到沮丧

结论

MoQ是真实的，它设计精良，解决了当前流媒体协议格局中的真正局限性。其愿景——一种协议同时服务实时和近实时场景，从采集到分发，支持CDN级别的中继——是令人信服的。

但愿景并不等于就绪。规范尚未定稿。Safari的WebTransport还在beta阶段，尚未在正式版中发布。生产部署仅限于早期采用者。使HLS、WebRTC和SRT在生产中可靠运行的SDK、工具和运维知识生态系统，对于MoQ来说还不存在。

对于2026年正在发布的大多数流媒体产品来说，MoQ是应该跟踪的东西——而不是应该采用的东西。当它成熟时（它一定会成熟），它有潜力简化那些目前需要将多种协议通过重新封装层拼接在一起的架构。

在那之前：如果HLS满足你的传输需求，继续用它。如果WebRTC满足你的实时需求，继续用它。如果SRT满足你的点对点链路需求，继续用它。最好的协议是正在运行且工作正常的那个，而不是在会议幻灯片上最令人兴奋的那个。

参考资料

Need Help With Your Streaming Project?

This article was written by experienced professionals available through iReplay.tv. Whether you need expertise in hls, webrtc, cdn—our network of specialists can bring your project to life.

Hire a Professional →

降低您的流媒体成本

Streaming Cost Optimizer

停止为CDN带宽多付费。我们的按需付费分发消除意外超额费用，降低流媒体成本。

计算您的节省