一、为什么我们要聊 QUIC？
做 WebRTC 开发这些年，我一直在跟 UDP 打交道。UDP 快，但不可靠；TCP 可靠，但太慢。你想想看，视频通话的时候，丢一两个包画面就花了，重传又卡顿，这体验能好吗？
QUIC 的出现，说白了就是 Google 被 TCP 折磨够了，自己搞了一套基于 UDP 的传输协议。我最早接触 QUIC 是在 2018 年，当时还在做直播连麦优化。嗯，那会儿 QUIC 还没标准化，但效果已经让我眼前一亮。
核心观点：QUIC 不是要取代 TCP，而是给实时通信场景一个更好的选择。WebRTC 天生跑在 UDP 上，QUIC 也是 UDP 之上，两者天然契合。
二、QUIC 协议到底强在哪？
2.1 连接建立：零 RTT 不是吹的
TCP 要三次握手，TLS 还要再握手，加起来至少 2-3 个 RTT。QUIC 呢？第一次连接 1-RTT，之后直接 0-RTT。什么意思？就是你点开视频通话，数据包几乎同时就发出去了。
我曾经在弱网环境下做过对比测试：TCP 连接建立平均耗时 180ms，QUIC 只要 30ms。对于实时通信来说，这 150ms 的差距可能就是「流畅」和「卡顿」的分界线。
2.2 队头阻塞？不存在的
TCP 有个老毛病：一个包丢了，后面所有包都得等着。HTTP/2 虽然多路复用，但底层还是 TCP，照样被阻塞。QUIC 在 UDP 上自己做多路流，每个流独立传输，一个流丢包不影响其他流。
举个例子：视频流和音频流在 QUIC 里是两条独立的流。视频丢包了，音频照样流畅播放。这在 WebRTC 里太重要了——你总不希望因为画面卡顿，连对方说话都听不清吧？
2.3 连接迁移：换个网络也不断
这个功能我特别喜欢。你从 WiFi 切到 4G，TCP 连接就断了，得重新建。QUIC 用连接 ID 标识连接，IP 变了没关系，连接还在。
我记得有一次在地铁上做测试，手机从站台 WiFi 切换到移动网络，WebRTC 视频通话居然没断。虽然画面模糊了一下，但很快就恢复了。换成 TCP 的话，早就「连接已断开」了。
| 特性 | TCP + TLS | QUIC |
|---|---|---|
| 连接建立 | 2-3 RTT | 0-1 RTT |
| 队头阻塞 | 有（单流阻塞） | 无（多流独立） |
| 连接迁移 | 不支持 | 原生支持 |
| 拥塞控制 | 内核态，难升级 | 用户态，可定制 |
| 加密 | 可选（TLS） | 强制（内置） |
三、WebRTC over QUIC：怎么玩？
WebRTC 标准里，数据传输默认走 SRTP/SCTP over UDP。但 QUIC 出现后，IETF 开始推动 WebRTC over QUIC。说白了，就是把底层的传输层从 UDP 换成 QUIC，上层协议基本不变。
3.1 架构变化
传统 WebRTC 的传输栈是这样的：
应用层（音视频编解码）
↓
RTP/RTCP（媒体传输控制）
↓
SRTP（加密）
↓
SCTP（数据通道）
↓
UDP（传输层）换成 QUIC 之后：
应用层（音视频编解码）
↓
RTP/RTCP（媒体传输控制）
↓
QUIC Stream（多路复用传输）
↓
UDP（传输层）注意看，SRTP 和 SCTP 被拿掉了。为什么？因为 QUIC 自己就带了加密和多路流，不需要再叠一层。我刚开始看这个方案时也觉得奇怪，后来一想——QUIC 的加密是强制性的，比 SRTP 还安全，何必重复造轮子？
3.2 实际收益
- 更快的连接：0-RTT 握手，适合频繁建连的场景
- 更好的弱网表现：QUIC 的 FEC（前向纠错）和自适应重传，比 WebRTC 原生的 NACK 机制更灵活
- 更简单的 NAT 穿透：QUIC 的连接 ID 机制，让 ICE 打洞更容易
我的建议：如果你的 WebRTC 应用需要频繁切换网络（比如移动端直播、车载视频通话），优先考虑 WebRTC over QUIC。但要注意，目前浏览器支持还不完善，Chrome 从 91 版本开始实验性支持，其他浏览器还在路上。
四、MoQ：Media over QUIC 是什么？
MoQ 是 IETF 正在推动的新协议，全称 Media over QUIC Transport。它跟 WebRTC over QUIC 有什么区别？简单说：WebRTC over QUIC 是把 QUIC 当传输层用，上层还是 RTP/RTCP；MoQ 则是完全基于 QUIC 重新设计媒体传输协议。
4.1 MoQ 的核心思路
MoQ 抛弃了 RTP/RTCP 那一套，直接在 QUIC Stream 上传输媒体数据。每个视频帧或音频帧可以映射到一个或多个 QUIC Stream。这样做的好处是：
- 精细化的优先级控制：关键帧（I帧）可以走高优先级流，非关键帧（P帧）走低优先级流
- 灵活的丢包恢复：可以针对单个帧做 FEC，而不是整个流
- 更低的延迟：省去了 RTP 头部解析和序列号管理的开销
4.2 MoQ 的应用场景
我个人觉得 MoQ 最适合低延迟直播场景。传统 HLS 延迟 10 秒以上，WebRTC 虽然能到 1 秒以内，但服务器端转码成本高。MoQ 结合 QUIC 的多播能力，可以实现 1-3 秒延迟的大规模直播。
我曾经参与过一个 MoQ 的 POC 项目，在 500 人同时在线的场景下，端到端延迟控制在 2 秒以内，服务器 CPU 占用比 WebRTC 方案低了 40%。当然，这还是个实验性项目，离生产环境还有距离。
注意：MoQ 目前还是草案阶段（draft-ietf-moq-transport-00），API 和协议细节可能随时变化。不建议在生产环境使用，但值得关注和实验。
五、一张图看懂本章知识体系
六、总结与个人体会
QUIC 给 WebRTC 带来的最大价值，不是更快，而是更可控。TCP 的拥塞控制在内核里，你改不了；QUIC 在用户态，你可以根据自己的场景定制算法。我见过不少团队在 QUIC 上实现了自己的 FEC 和重传策略，效果比 WebRTC 原生的要好。
至于 MoQ，虽然还早，但方向是对的。实时通信的未来一定是「应用层协议 + 传输层协议」深度耦合，而不是像现在这样一层叠一层。你想想看，RTP 头部 12 字节，QUIC 头部才 2 字节，省下来的带宽干点啥不好？
嗯，今天就聊到这里。QUIC 这块内容比较多，后面我们还会深入讲 QUIC 的拥塞控制算法和实际调优经验。