Meta 开始规模化部署 MoQ,用于 Instagram Live 推流

作者:Konstantin Tsoy, Aman Sharma, Hari Anil Kumar, Alan Frindell, Sandarsh Srivastava
原文:https://engineering.fb.com/2026/10/12/video-engineering/shipping-media-over-quic-at-meta-scale-for-instagram-live-ingest/

Instagram Live 如今在 iOS 与 Android 上,使用开放标准传输协议 Media over QUIC(MoQ) 来完成直播视频推流。MoQ 是为推流与播放两端共同设计的传输协议,它给了我们一个基础,去构建一套延迟更低、在不可靠网络上更具韧性、对创作者和观众都更灵敏的架构。它也为 Meta 各团队提供了一套共同基础,让他们能够把这类改进带到未来的直播与互动体验中,而不必在彼此独立的协议栈上重复建设。

MoQ:为每一个时间切片而生的媒体协议

互联网积累了种类丰富的媒体协议,每一种都是被眼前的特定问题塑造出来的。RTMP 用于推流,HLS 和 DASH 用于播放,WebRTC 用于实时通话,RUSH 用于那些无法被上述任何一类整齐容纳的场景。每一种协议在它所属的时代都是出色的答案,它们共同把这门行业带到了今天。但在 Meta,一个用户如果在同一个 App 里先开一场直播、再打一个语音电话,他会触碰到三套不同的协议栈,每一套都有自己的服务基础设施、监控体系和运维专长。

当这些体验彼此分明时,这种割裂是合理的。但随着直播视频、实时 AI 和生成式 AI 创作工具越来越多地共享同一个产品界面,这些用例之间的界线正开始模糊。一个贯穿推流、分发与播放的共同协议,能够减少工程团队需要长期维护与改进的定制传输协议数量与运营模式。

MoQ 是如何工作的

MoQ 是一项新兴的 IETF 标准,它基于 QUIC 传输层实现低延迟、可扩展的媒体分发(直播、实时通信)。它由 IETF 协作推进,Meta、Google、Akamai、Cisco、Cloudflare 以及学术界均积极参与其中。

近十年来,Meta 的直播视频一直运行在 RUSH(Reliable Ultra-low-latency Streaming over HTTP,基于 HTTP 的超低延迟可靠流传输)之上——这是自研的、基于 QUIC 的协议,初衷是超越 RTMP。RUSH 证明了 QUIC 能在大规模下承载直播媒体,也是 MoQ 的前身。在生产环境中运行 RUSH 所积累的经验,正是塑造我们押注 MoQ 的原因之一。

MoQ 的核心抽象是 Track(轨道)​:一条可寻址的媒体对象流,发布者推入对象,订阅者经由一组中继(relay)接收。中继会缓存并转发对象,但不会解析媒体载荷,它们只需理解 MoQ 的封装格式与投递元数据。

以下几个特性,决定了 MoQ 能作为贯穿全延迟谱系的单一传输协议来使用:

  • 构建于 QUIC 之上: QUIC 让相互独立的流各自推进,不会出现 TCP 那种跨流队头阻塞。它还支持更快的连接建立与连接迁移。Meta 早先的 QUIC 部署已经在请求错误、尾部延迟和视频卡顿上优于 HTTP/2。MoQ 把同样的传输基础应用到了直播与实时媒体上。QUIC 后续新增的任何特性(例如 FEC 前向纠错),MoQ 也会自动受益。
  • 原生 fan-out 与缓存: MoQ 中继内置了缓存与请求/流合并能力,因此媒体流开箱即可通过 CDN 中继横向扩展。请求合并、缓存与 fan-out 并非新东西(直播早已在做),但 MoQ 让它们成为协议设计的一部分,而非外挂补丁,并且它被设计为能够比传统 HTTP 流更高效地通过中继扩展。
  • 按用例可调的延迟: 同一条 Track 的两个订阅者可以同时运行在不同的延迟水平上。例如交互参与者约 100 ms,而归档或带缓冲的服务则为数秒,这取决于可按订阅调整的投递属性。
  • 感知 Track 的投递: 中继可以根据元数据丢弃、优先处理或重放对象,从而在丢包时获得优于字节流协议的拥塞行为。
  • 一等的媒体上下文: Track 及其清晰度变体被建模在协议本身之中,因此自适应码率(ABR)逻辑直接构建在 MoQ 的原生结构上,而无需在更高层重新拼装。
  • 基于标准的 TCP 回退: 当 QUIC 被阻断时,MoQ 可以通过标准化映射(例如基于 HTTP/2 的 WebTransport,或正在成形的 QMUX 映射)回退到 TCP,这样被阻断的网络就不会迫使整个生态退回多套并行传输协议的处境。
Meta 开始规模化部署 MoQ,用于 Instagram Live 推流
MoQ 能够在大规模应用的同时实现低延迟,并满足各种应用场景的需求。

首个规模化部署:Instagram Live

在 Meta 所有可以由 MoQ 承载的场景中,我们选择先落地直播视频推流,原因有三:

Instagram Live 是我们最大规模的试验场。​ Instagram Live 以 Meta 的体量为用户提供服务。在这个规模上验证 MoQ,意味着它跨过了最严苛推流负载的门槛,同时也与实时用例所看重的低延迟特性相辅相成。

RUSH 正在落后于开放生态。​ 直播推流此前一直运行在 RUSH 上,RUSH 是 Meta 基于 QUIC 协议的务实型 RTMP 解决方案。RUSH 在大规模应用方面保持了近十年的稳定性和高性能,但转向 MoQ 将开发重心从主要由 Meta 运营的协议转移到共享标准制定工作。多个实现者可以贡献经验、测试互操作性并改进规范,而不是像以前那样主要由 Meta 独自开发传输协议。 

指标持平是其他一切的前提。​ 证明 MoQ 能在 Meta 体量下、为其最大的直播场景服务且不出现回退,就给了我们一个干净的基线去探索更多方向,其中包括直播播放等。

在 Instagram Live 上推行 MoQ

替换 Instagram Live 的直播推流协议,意味着要更换该服务上每一场直播底下的地基。我们必须在不影响创作者和观众体验的前提下完成这项工作,并且不能将网络格式的更改与所有下游系统的重写捆绑在一起。

在直播生产系统中替换传输协议之所以困难,原因大多与协议本身无关——主播端 App 需要学会它,后端管线期待旧的分帧格式,灰度发布必须能在数秒内回滚,而且有相当一部分网络根本无法承载这种新传输。

我们把这些问题拆成三个受约束的问题来应对:

四个 App 的客户端集成。​ 一个基于 moxygen(Meta 开源的 MoQ 库)构建的 MoQ 发布器被集成进我们的 App。moxygen 提供发布者、订阅者和中继三种角色,与我们的 QUIC 栈(mvfst)集成,并暴露了供自定义媒体处理器接入的钩子。一个配置参数即可为某一场直播选择使用 MoQ 还是 RUSH。

在边缘做转换,而不是重写后端。​ MoQ 推流连接在专用的边缘端点终止,在那里由一个转换层把 MoQ 帧转换为既往后端已经理解的 RUSH 格式。在切换客户端传输的同时,下游一切保持不变。这个转换器只是临时脚手架;一旦 MoQ 成为唯一的推流路径,后端将原生消费 MoQ,这层垫片就会被移除。

为快速放量做服务端路由。​ 流 URL 生成会根据实验分组,把符合实验条件的直播路由到支持 MoQ 的端点,因此分阶段发布不依赖 App 版本的采用率,实验规模也能在几分钟内调整。

运维层面的障碍

  • 规范仍在演进: 作为一个活跃的 IETF 标准,MoQ 草案在我们构建期间持续变化。我们把版本锁定到特定草案,为旧客户端保留兼容垫片,并把改进回馈给 IETF 工作组。
  • 防火墙: 在相当一部分企业网与运营商网络中,UDP/443 仍被阻断或限速。我们在直播开始时,根据 TCP 与 QUIC 哪个握手先成功来选择传输方式,并在整个会话期间沿用这一选择。
  • 调试: QUIC 的加密让分帧格式对中间盒不可见,对我们自己的抓包也同样不可见。我们在边缘构建了能识别 MoQ 的追踪能力,从而无需解密线缆数据即可看到对象级事件。

结果

在 Instagram iOS 与 Android 上经过数月实验后,我们为 Instagram Live 推流上线了 MoQ。MoQ 路径在灰度期间所用的各项流媒体质量指标与可靠性指标上,都与 RUSH 持平。

达到指标持平是这一阶段的目标,它证明了我们能够在不打扰创作者与观众的前提下替换一套生产传输协议。这也为下一阶段留下了一套经过生产检验的传输、一套发布控制机制,以及可观测性。

这由此成为把 MoQ 扩展为端到端直播视频分发与播放架构的基础。在那套目标架构中,媒体可以在被生产出来的同时即被推送;部分可靠性(partial reliability)能让播放器在丢包后跳过过期视频,而不是任由延迟累积;自适应码率工作可以在带宽变化时以分辨率换连续性。我们相信这些能力将构成下一代直播视频架构的基础,为创作者和观众带来更丰富、更灵敏的体验。

接下来:Meta 内部的其他探索

Instagram Live 是 Meta 的第一个 MoQ 工作负载。在 Instagram Live 规模上达到持平,给了我们一个干净的基线,去追问:一套基于 QUIC 的单一传输还能在哪些地方,把一组特例协议栈收敛成一套?以下是我们正在探索的方向:

把直播推流的故事讲完。​ 接下来的顺理成章之举,是在已有成果之上继续推进。把 MoQ 扩展到 Meta 其余 App,使用 MoQ 原生结构(如 subgroup)把音频、视频与元数据承载在相互独立的流上,以获得更强的抗丢包韧性;并加入基于标准的 TCP 回退(QMUX)。如今,我们在 QUIC 被阻断的网络上,是权宜地依赖 RUSH 既有的 TCP 回退;标准化到 QMUX 之后,这种依赖将被移除,被阻断的网络不再需要我们准备第二套协议,最终也为下线 RUSH 打开大门。

实时交互 AI。​ 会话式与实时 AI 场景正把架构推向持续的人机(人—服务器)通信。一个把信令与媒体一起承载、低延迟的双向传输天然契合这一需求。满足实时通信所要求的延迟、丢包恢复与媒体质量指标,是我们正在积极探索的方向。

为 Instagram Live 落地 MoQ,使得它成为我们所知业界规模最大的 MoQ 应用之一,无论从推流路数还是总流量来看都是如此。一套开放的 IETF 标准传输,如今正承载着 Meta 体量的媒体,而它所开启的未来令人兴奋。

深入了解 Meta 的 MoQ 部署

想了解更多?请查看 MoQ Transport IETF 草案 以及我们的 moxygen 开源库。

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

赞 (0)

相关推荐