Meta 在 Instagram Live 推流链路部署 Media over QUIC，规模与 RUSH 持平
来源Meta Engineering查看原文
速览
- Instagram Live 推流已在 iOS 和 Android 上切换到 MoQ，规模与 RUSH 持平。
- MoQ 是 IETF 开放标准，Meta 从自研 RUSH 转向共建标准。
- 落地采用边缘转换层，后端不改，转换层为临时脚手架。
- 客户端基于开源库 moxygen 与 QUIC 栈 mvfst，单参数切换协议。
- 同一 Track 可按订阅者设定不同延迟，约 100 ms 到数秒不等。
- UDP/443 被封锁时按握手结果选择 TCP 或 QUIC，会话内不变。
- 下一步扩展直播播放与实时交互 AI，并推进 QMUX 标准化回退。
- Meta 称这是已知业界规模最大的 MoQ 应用之一。
Meta 工程团队宣布，Instagram Live 在 iOS 和 Android 上的直播推流（ingest）已开始使用 IETF 正在制定的开放传输协议 Media over QUIC（MoQ）。此前 Meta 的直播推流依赖自研的 RUSH 协议（基于 QUIC，用于替代 RTMP），运行近十年。Meta 表示，经过数月实验，MoQ 路径在推流质量与可靠性指标上与 RUSH 持平，因此正式上线。选择 Instagram Live 作为首个规模化落地场景，是因为它是 Meta 体量最大的直播场景，能验证 MoQ 在最苛刻的推流负载下的表现。落地方式上，客户端通过 Meta 开源 MoQ 库 moxygen 集成发布端，边缘节点做 MoQ 到 RUSH 的格式转换，后端无需改动；服务端按实验分组路由流量，便于快速扩缩实验。Meta 称这是目前已知业界规模最大的 MoQ 应用之一（按推流路数和总流量计），下一步将把 MoQ 扩展到直播播放、实时交互 AI 等场景，并推进 QMUX 标准化 TCP 回退，最终目标是退役 RUSH。
关键事实
- Instagram Live 的 iOS 与 Android 推流已使用 Media over QUIC（MoQ），这是 Meta 首个 MoQ 生产工作负载。
- MoQ 是 IETF 正在制定的开放标准，Meta、Google、Akamai、Cisco、Cloudflare 及学术界均有参与。
- Meta 直播推流此前近十年运行在自研 QUIC 协议 RUSH 上，RUSH 是 MoQ 的前身。
- MoQ 路径在 Instagram Live 上与 RUSH 在推流质量和可靠性指标上持平，这是本阶段的目标。
- 客户端 MoQ 发布端基于 Meta 开源库 moxygen，并接入其 QUIC 栈 mvfst；一个配置参数即可在 MoQ 与 RUSH 之间切换。
- 边缘节点设有转换层，把 MoQ 帧转成后端已理解的 RUSH 格式，后端无需改动；该转换层为临时方案。
本站视角
这件事对做直播、实时音视频和 Agent 的中文团队有直接参考价值。第一，Meta 用 Instagram Live 这个体量最大的场景验证了 MoQ 能在生产环境跑通且不劣化指标，等于替整个行业做了一次大规模压力测试——此前 MoQ 更多停留在 IETF 草案和实验实现阶段，缺少超大规模生产案例。国内做直播推流、连麦、实时互动的团队，如果正在评估是否从 RTMP/WebRTC 迁移到 MoQ，这份工程细节（边缘转换层、按实验分组路由、握手竞速选传输）是可以直接借鉴的落地路径。第二，Meta 明确把「实时交互 AI」列为 MoQ 的探索方向，理由是对话式 AI 需要持续的人到服务器通信，而单一低延迟双向传输能同时承载信令和媒体。这对做语音 Agent、实时多模态应用的团队是一个信号：传输层的选择可能和模型选型一样重要，值得提前关注。第三，Meta 把自研 RUSH 换成开放标准，并开源了 moxygen，这本身是行业协作模式的转变——协议演进从一家公司主导变成多方共建，对依赖这些协议的中小团队来说，标准稳定性与互操作性预期会更好。 我们的判断是：这次发布是实质性的工程进展，而非营销包装，但需要区分「持平」和「更好」。Meta 自己说得很清楚，本阶段目标是 metric parity，MoQ 并没有在质量指标上超过 RUSH，真正的收益要等到端到端架构铺开、部分可靠性让播放器跳过过期视频、自适应码率在协议层直接工作时才会体现。因此现在就说 MoQ 会带来体验跃升为时过早。 可疑之处有两点。其一，Meta 称这是「已知业界规模最大的 MoQ 应用之一」，但原文没有给出任何具体数字——推流路数、总流量、延迟改善幅度都没有披露，这个说法目前无法独立验证，读者应把它当作厂商自述而非可核实的事实。其二，Meta 是 MoQ 标准的主要推动者之一，同时又是最大规模的使用者，这种双重身份意味着它在标准走向上有较大话语权；对依赖该标准的第三方实现者来说，标准是否会向有利于 Meta 既有基础设施的方向倾斜，需要持续观察。另外，UDP/443 在企业与运营商网络被封锁或限速的问题，Meta 自己承认是「non-trivial slice」，这意味着 MoQ 在真实网络中的覆盖率仍受制于 QUIC 的普及程度，QMUX 标准化回退落地之前，双协议并存的运维成本不会消失。
背景与影响
直播传输长期由多套协议分担：推流用 RTMP，播放用 HLS 和 DASH，实时通话用 WebRTC，Meta 还有自研的 RUSH 处理不适用上述场景的情况。Meta 在原文中指出，一个用户在同一 App 里开直播再打语音通话，会触及三套协议栈，各自有独立的服务基础设施、监控和运维经验。当直播视频、实时 AI 与生成式 AI 创作工具越来越多地出现在同一产品界面时，这种割裂的成本开始显现。MoQ 的核心抽象是 Track——可寻址的媒体对象流，发布者推送、订阅者接收，中间由 relay 缓存转发，relay 无需解析媒体负载，只需理解 MoQ 的封装与投递元数据。由于构建在 QUIC 之上，MoQ 天然继承 QUIC 的多路复用、快速连接建立与连接迁移能力；Meta 早年的 QUIC 部署已证明其在请求错误率、尾延迟和视频卡顿上优于 HTTP/2。MoQ 还把 fan-out、缓存、请求合并做进协议设计而非外挂，并支持按订阅调优延迟、基于元数据丢弃或重放对象、以及协议内建的自适应码率建模。这意味着如果 MoQ 在 Meta 内部铺开，工程团队维护的自定义传输与运维模型数量可能减少，而实时交互 AI 这类需要持续双向通信的场景，也可能复用同一套低延迟传输，而不必另起炉灶。需要观察的是，MoQ 目前仍是 IETF 草案，Meta 在开发期间需要锁定特定草案版本并为老客户端保留兼容层，标准的最终形态尚未固定。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
