此内容已使用自动机器翻译服务进行翻译，仅供您参考及阅读便利。其中可能包含错误、遗漏，或与原始英文版本存在理解方面的细微差别。如有疑问，请参考原始英文版本。
二十多年来，我们一直使用拼凑而成的各种专门工具在互联网上建立实时通信。RTMP 为我们提供了 ingest。HLS 和 DASH 帮助我们实现了规模。WebRTC 给我们带来了交互性。它们各自解决了当时的特定问题，共同驱动着我们今天所依赖的全球流式传输生态系统。
但是，在 2025 年一起使用它们，感觉就像使用来自不同时代的工具构建一个现代应用程序。接缝开始显现——复杂性、延迟，以及下一代应用程序所需的灵活性——从亚秒级实时拍卖到大规模交互活动。我们经常被迫在延迟、规模和运营复杂性之间进行痛苦的权衡。
今天，Cloudflare 推出首个 Media over QUIC (MoQ) 中继网络，该网络在分布在 330 多个城市的数据中心的每一台 Cloudflare 服务器上运行。MoQ 是全行业工程师在 IETF 上开发的一个开放协议，而不是 Cloudflare 的专有技术。起订量结合了 WebRTC 的低延迟交互性、HLS/DASH 的可扩展性以及单一架构的简单性，全部建立在现代传输层上。我们将加入 Meta、Google、Cisco 和其他公司的行列，构建无缝协同工作的实现，为互联网上的下一代实时应用程序创建一个共同的基础。
要理解最小起订量的承诺，首先我们必须回顾引领我们走到今天的历史——这是一系列架构妥协定义的旅程，解决一个问题不可避免地产生了另一个问题。
RTMP 时代：克服延迟，权衡规模
21 世纪初，RTMP（实时消息协议）是一个突破。通过在 Flash 客户端和服务器之间创建一种持久的、有状态的 TCP 连接，它解决了早期网络视频播放中令人沮丧的“下载并等待”体验。这实现了低延迟的流媒体传输（2-5 秒），支持 Justin.tv（后来的 Twitch 前身）等第一波直播平台。
但它的优势也是其劣势。这种有状态的连接必须为每一位观看者进行维护，从架构上不利于扩展。它需要昂贵的专用媒体服务器，并且无法使用基于 HTTP 的商品化内容分发网络（CDN），而后者开始为网络的其他部分提供支持。它对 TCP 的依赖也意味着一个丢失的数据包可能会冻结整个流——这种现象称为队头阻塞——从而造成刺耳的延迟峰值。业界为从摄像机到服务器的“第一英里”保留了 RTMP（摄取），但需要为从服务器到屏幕的“最后一英里”提供新的解决方案（交付）。
HLS 和 DASH 时代：解决规模问题，在延迟方面做出妥协
下一个时代的催化剂是 iPhone 对 Flash 的摒弃。为此，Apple 创建了 HLS（HTTP 实时流式传输）。HLS 及其对应的开放标准 MPEG-DASH 放弃了有状态连接，并将视频视为通过标准 HTTP 交付的一系列小静态文件。
这实现了更大的可扩展性。通过转向可互操作的开放 HTTP 标准作为底层传输，视频现在可以通过任何网络服务器分发并通过全球 CDN 缓存，使平台能够以相对低成本可靠地服务数百万观众。妥协呢？重大的权衡延迟。为确保播放流畅，播放器需要缓冲至少三个视频片段才能开始。由于分段持续时间为 6-10 秒，因此架构中直接嵌入了 15-30 秒的延迟。
虽然像低延迟 HLS (LL-HLS)这样的扩展最近出现了，以实现 3 秒范围内的延迟，但它们仍然是与该协议的基本设计相抗争的复杂补丁。这些扩展引入了一个有状态的实时通信层（使用巧妙的变通方法，例如将播放列表请求保持打开状态），最终给对 HTTP 可扩展性和可组合性至关重要的无状态请求-响应模型带来压力。
WebRTC 时代：克服对话延迟，对架构的妥协
在此期间，WebRTC（网络实时通信） 出现了，解决一个不同的问题：无需插件，双向对话视频在浏览器中实现不超过 500 毫秒的延迟。它的工作原理是创建直接的点对点（P2P）媒体路径，消除了等式中的中央服务器。
但这种点对点模式从根本上与广播规模是不一致的。在网状网络中，连接数随着每个新参与者的二次函数增长（“N 方问题”）。对于不止少数的用户来说，模型会在自身复杂性的重压下崩溃。为解决这个问题，业界开发了基于服务器的拓扑，例如选择性转发单元 (SFU) 和多点控制单元 (MCU)。这些措施行之有效，但需要构建一个本质上私有的、有状态的实时 CDN——这是一项复杂和昂贵的工作，而且没有在基础设施提供商之间实现标准化。
这段征程给我们留下了一个由专门、不可互操作的孤岛组成的支离破碎的环境，迫使开发人员将多种协议拼凑在一起，并接受延迟、规模和复杂性之间痛苦的三向紧张。
这就是 Media over QUIC (MoQ) 应运而生的背景。这不仅仅是另一个协议，全新的设计理念从头开始构建，旨在解决这个历史悠久的三难问题。MoQ 脱胎于 IETF 进行的一项开放、社区驱动的努力，旨在成为一项基础互联网技术，而非专有产品。
它承诺通过提供以下功能来统一流媒体的不同世界：
广播规模的亚秒延迟：结合 WebRTC 的延迟、HLS/DASH 的规模以及 RTMP 的简单性。
架构简单：创建单一、灵活的协议用于摄取、分发和交互用例，无需在不同技术之间进行转码。
传输效率：在 QUIC（一种基于 UDP 的协议）上构建，以消除 TCP 队头阻塞等瓶颈。
最初的重点是“媒体”而不是 QUIC，但核心概念——计时、有序但独立数据的命名轨道——非常灵活，以至于工作组现在直接将该协议称为“MoQ”。这个名字反映了抽象的力量：它是一种通用传输工具，适用于任何需要高效、大规模地交付的实时数据。
现在，最小起订量非常通用，是一个数据扇出或发布/订阅系统，适用于从音频/视频（高带宽数据）到体育赛事分数更新（低带宽数据）的一切内容。
起订量的优雅源于在正确的层解决正确的问题。让我们从基础开始，看看它如何大规模实现亚秒级延迟。
选择 QUIC 作为最小起订量的基础并非任意——它解决了困扰流式传输协议数十年的问题。
通过构建于 QUIC（一种也为 HTTP/3 提供支持的传输协议），MoQ 解决了一些关键的流式传输问题：
无队头阻塞：与 TCP 不同，在 TCP 中一个丢失的数据包会阻塞其后方的所有内容，而 QUIC 的数据流是独立的。一个流（例如音轨）上的数据包丢失不会阻塞另一个流（例如主视频轨道）。仅此一点就消除了困扰 RTMP 的卡顿问题。
连接迁移：当您的设备中途从 Wi-Fi 切换到蜂窝网络时，连接无缝迁移而不会中断——无需重新缓冲，无需重新连接。
快速建立连接：QUIC 的 0-RTT 续传意味着返回的观众可以立即开始播放。
内置的强制加密：所有 QUIC 连接默认使用 TLS 1.3 加密。
通过 QUIC 解决传输问题，MoQ 引入了其关键创新：将媒体视为发布/订阅系统中的可订阅轨道。但与传统的 pub/sub 不同，这是专门为 CDN 规模的实时媒体而设计的。
不再使用复杂的会话管理 (WebRTC) 或基于文件的分块 (HLS)，MoQ 让发布者公告订阅者可以请求的媒体轨道命名。中继网络无需了解媒体本身即可处理分发。
在了解媒体如何在网络中流动之前，让我们先了解一下 MoQ 是如何构建网络的。MoQ 以层次结构组织数据：
Tracks：命名的媒体流，例如"video-1080p" 或 "audio-english"。订阅者按名称请求特定轨道。
Groups：轨道的可独立解码的块。对于视频，这通常意味着以关键帧开始的 GOP（图片组）。新订阅者可以在任何组边界加入。
Object：网络上发送的实际数据包。每个对象都属于一个跟踪，并在组中具有一个位置。
这个简单的层次结构支持两种功能：
订阅者可从 Groups 边界开始播放，无需等待下一个关键帧
中继可以在不解析或了解媒体格式的情况下转发 Object
MoQ 的网络组件也很简单：
中继充当订阅者，从上游接收跟踪（与原始发布者一样），同时充当发布者，将这些相同的跟踪转发给下游。这种模型是 MoQ 可扩展性的关键：一个上游订阅可以呈扇形展开，为成千上万的下游观众提供服务。
MoQ 的架构可以理解为三个不同的层，每层都有明确的工作：
Transport Foundation（QUIC 或 WebTransport）：这是现代一切的基础。MoQT 可以直接在原始 QUIC 上运行（这对于原生应用程序是理想的选择，或在 WebTransport 上运行，这是需要在网络浏览器中使用）。至关重要的是，WebTransport 协议及其相应的 W3C 浏览器 API 使浏览器应用程序可以直接访问 QUIC 的多路复用可靠流和不可靠数据报。这是一个颠覆性的变革。像 SRT 这样的协议可能是高效的，但由于缺乏原生浏览器支持，它们只能扮演仅摄取的角色。WebTransport 在网络上为 MoQ 提供了一等公民身份，因而适合于摄取和直接向客户端大规模分发。
MoQT 层：MoQT 层位于 QUIC（或 WebTransport）之上，为“发布-订阅”系统提供信号和结构。这是 IETF 工作组的主要重点工作。它定义了核心控制消息（如宣布和订阅）以及我们刚刚涵盖的基本数据模型。MoQT 本身也刻意做到简洁；它不知道或关心它移动的数据是 H.264 视频、Opus 音频，还是游戏状态更新。
流格式层：这是特定于媒体的逻辑所在。流式传输格式定义了清单、编解码器元数据和打包规则等内容。WARP 就是 IETF 与 MoQT 一起开发的一种格式，但它并不是唯一的格式。另一个标准机构，例如 DASH-IF，可以通过 MoQT 定义一种基于 CMAF 的流媒体格式。同时控制原始发布者和最终订阅者的公司可以开发自己的专有流格式，在不受传输协议约束的情况下尝试新的编解码器或交付机制。
通过这种层的分离，不同的组织可以构建可互操作的实现，同时仍能在流格式层进行创新。
现在我们已经了解了架构和数据模型，下面我们来看看这些部分是如何组合在一起提供流媒体的。该协议很灵活，但是典型的广播流依赖于宣布和订阅消息来通过中继网络建立从发布者到订阅者的数据路径。
如下对这一流程的逐步细分：
启动连接：当充当客户端的端点连接到中继网络时，这个过程就开始了。原始发布者向它最近的中继（我们称之为中继 A）发起连接。另外，最终订阅服务器发起与自己的本地中继（中继 B）的连接。这些端点与其各自的中继执行 SETUP 握手，以建立起订量会话并声明支持的参数。
公告命名空间：为了使其内容可以发现，发布者向中继 A 发送宣布消息。该消息声明，发布者是给定跟踪命名空间的权威来源。中继 A 接收到此消息，并在共享控制平面（一个概念数据库）中注册，自己现在是网络中此命名空间的来源。
订阅跟踪： 当最终订阅者想要接收媒体时，它会向其中继（中继 B）发送一条订阅消息。此消息是对特定跟踪名称中的特定跟踪命名空间的请求。
连接中继：中继 B 收到订阅请求并查询控制平面。它查找所请求的命名空间，发现中继 A 是来源。然后，中继 B 发起与中继 A 的会话（如果还没有会话），并将订阅请求转发给上游。
完成路径和转发对象：中继 A 在收到来自中继 B 的订阅请求后，将其转发给原始发布者。建立完整路径后，发布者开始发送所请求跟踪的对象。对象从发布者流到中继 A，中继 A 将它们转发给中继 B，中继 B 再将它们转发给最终订阅者。如果另一个订阅者连接到中继 B 并请求相同的轨道，中继 B 可以立即开始向他们发送对象，而无需创建新的上游订阅。
MoQ 规范的较新草稿引入了另一种使用发布消息的基于推送的模型。在这个流程中，发布者可以有效地请求允许，将跟踪的对象发送到中继，而无需等待订阅请求。发布者发送一条发布消息，中继的 PUBLISH_OK 响应表明它是否接受这些对象。这特别有用于摄取场景，即发布者希望将其流立即发送到网络的入口点，确保媒体在第一个订阅者连接的瞬间可用。
当网络发生拥塞时，最小起订量的优势才真正大放异彩。最小起订量 包括用于处理现实网络流量的机制。一种这样的机制就是 Subgroups。
子组是组内的细分部分，它们实际上直接映射到底层 QUIC 流。同一子组内的所有对象通常通过相同的 QUIC 流发送，以保证它们的传递顺序。子组编号还提供了一个编码优先级的机会：在一个组中，编号较小的子组被认为具有较高的优先级。
这会实现智能质量降级，尤其是在分层编解码器（例如 SVC):
当中继检测到拥塞时，它可以丢弃编号较大的子组中的对象，从而保留基础层。观众看到的是质量下降而不是缓冲。
起订量规范定义了一种调度算法，用于确定所有“准备发送”的对象的顺序。当中继有多个对象时，它首先按组顺序（升序或降序）对它们进行优先级排序，然后在组中按子组 id 为它们确定优先级。我们的实现支持组顺序首选项，这对于低延迟广播可能很有用。如果查看者落后了，并且其订阅使用组降序排列，则中继会优先发送最新“活动”组中的对象，从而有可能取消较旧组中未发送的对象。这可以帮助观众快速跟上实时边缘，对于许多交互式流式传输用例来说，这是一个非常理想的功能。如何使用这些功能来改善特定用例的 QoE 仍是一个开放的研究问题。我们诚邀开发人员和研究人员使用我们的网络进行实验，并帮助找到答案。
理论是一回事，实践是一回事。实施是另一回事为了验证协议并了解其现实挑战，我们正在打造首批全球最小起订量中继网络之一。Cloudflare 的网络将计算和逻辑置于边缘，非常适合于此。
我们的架构将最小起订量的抽象概念连接到 Cloudflare 堆栈。在我们的深入探讨中，我们提到，当发布者宣布命名空间时，中继需要在“共享控制平面”中注册此可用性，以便正确路由订阅请求。对于状态管理的这一关键部分，我们使用 Durable Objects 。
当发布者向位于例如伦敦的中继宣布一个新的命名空间时，该中继将使用我们的强一致性单线程存储解决方案 Durable Object 来记录，此命名空间现在在该特定位置可用。当巴黎的订阅者想要该命名空间中的轨道时，网络可以查询此分布式状态以找到最近的源并相应地路由订阅请求。这种架构建立在我们为 Cloudflare 实时服务开发的技术基础上，提供了一种解决方案来应对全球范围内的状态管理挑战。
以公开方式构建一个新协议意味着要实施一个不断变动的目标。为了让社区能够享受起订量，我们深思熟虑地做了一个权衡取舍：我们当前的中继实现基于 Draft-ietf-moq-transport-07 中定义的功能子集。这个版本成为了几个开源项目之间事实上的互操作性目标，暂停在这里让我们能够将精力用于部署中继网络的其他方面。
此协议草案对访问“过去”的内容和访问“未来”的内容进行了区分。订阅用于在未来对象到达时接收其订阅请求，就像收看实时广播节目以了解从那一刻起以后的所有内容。相比之下，FETCH 提供了一种机制来访问中继在其缓存中可能已经拥有的 过去 的内容，就像要求提供刚刚播放的歌曲的录音。
两者属于同一规范，但对于最紧迫的低延迟用例，订阅的高性能实现最为重要。因此，我们最初的努力中心化了那里，尚未实施 FETCH。
这是我们路线图灵活的地方，也是社区可以产生直接影响的地方。您是否需要 FETCH 来构建按需或追赶式功能？或者是对您的用例的订阅中的优先级功能提供更完整的支持？从早期开发人员那里获得的反馈将帮助我们决定下一步要构建什么。
一如既往，我们将在开发人员文档页面上宣布我们继续开发过程中对实现的更新和更改。
我们相信构建社区是为了开放和互操作性。MoQ 不是 Cloudflare 技术，而是一项基础互联网技术。为此，我们推出的第一个演示客户端是一个开源社区示例。
您可以在这里访问演示：https://moq.dev/publish/
尽管这是预览版，但我们正在以 Cloudflare 的全规模运行起订量中继，就像我们所做的每一项生产服务一样。也就是说，在超过 330 个城市，Cloudflare 网络中的每一台服务器现在都是一个最小起订量中继。
诚邀您体验 MoQ 所实现的近乎即时的亚秒级流式传输延迟的令人惊叹的时刻。如果您有一个能提供全球广播规模的视频通话速度，您会如何使用这种协议？
我们一直与 IETF 工作组社区及其他地方的其他人进行合作，研究开发者、播放器以及 MoQ 生态系统其他部分之间的互操作性。到目前为止，我们测试过：
互联网的媒体堆栈正在被重构。二十年来，我们一直被迫在延迟、规模和复杂性之间做出选择。我们做出的妥协解决了一些问题，但也导致了一个碎片化的生态系统。
最小起订量代表了一个有希望的新基础——一个统一这些孤岛并在可扩展协议上构建下一代实时应用的机会。我们致力于帮助建立这一公开基础，而我们才刚刚开始。
起订量限制是一种现实的前进方式，基于 QUIC 构建，不会过时，比 WebRTC 更容易理解，能不同于 RTMP 与浏览器兼容。
协议在发展，实现在成熟，社区在成长。无论是构建下一代实时流式传输，探索实时协作，还是挑战交互式媒体的极限，请考虑最小起订量是否可以提供您所需的基础。
我们希望开发人员今天就可以起订量开始构建。为实现这一点，Cloudflare 提供了技术预览版，这意味着它可以免费用于测试（任何规模）。请访问我们的开发者主页，获取更新和潜在的重大变化。
独立开发者和大型企业在采用新技术之初都会询问定价。我们将保持透明、明确的最小起订量定价。在普遍可用时，自助客户应该支付 5 美分/GB 的出站费用，而不是发送到 Cloudflare 的流量。
Enterprise 客户可以享受与常规媒体交付定价一致的定价，与现有协议相比具有竞争力。这意味着，如果您已经在使用 Cloudflare 进行媒体交付，那么就不应该因为成本而对采用新技术保持警惕。我们会全力支持您的。
如果您有兴趣与 Cloudflare 合作尽早采用该协议或为其开发做出贡献，请通过 moq@cloudflare.com 联系我们！对互联网的未来充满希望的工程师们已蓄势待发。