4、传输协议选型（下）：SRT协议特性、QUIC协议在流媒体中的应用、协议对比矩阵
上一讲我们把 WebRTC 和 HLS 低延迟扩展聊透了。这一讲咱们继续，把剩下的两个重要选手——SRT 和 QUIC 讲清楚。说实话，这两个协议在流媒体圈子里争议不小。有人觉得 SRT 是广电级的救星，有人觉得 QUIC 才是未来。我的看法是：没有银弹，只有合适的场景。
4.1 SRT 协议：专为不稳定网络设计的“可靠 UDP”
SRT（Secure Reliable Transport）是 Haivision 开源的一个传输协议。它本质上是 UDP 上面加了一层可靠传输和加密。我最早接触 SRT 是在一个跨国直播项目中，公网丢包率经常飙到 5% 以上，TCP 直接卡死，RTMP 更是惨不忍睹。当时团队差点要上卫星链路了，后来换成 SRT，问题居然解决了。
4.1.1 SRT 的核心机制
SRT 最厉害的地方，是它的丢包重传和动态调整。它不像 TCP 那样“死板”，而是根据网络状况实时调整发送速率。
- ARQ（自动重传请求）：丢包后只重传丢失的包，不阻塞后续数据。
- FEC（前向纠错）：可以提前发送冗余数据，减少重传次数。
- 动态带宽估计：根据 RTT 和丢包率，自动调整发送窗口。
关键参数：SRT 的延迟设置通常在 120ms 到 8s 之间。我个人习惯在公网直播时设 500ms 左右，既能抗丢包，又不至于让观众觉得卡。
4.1.2 SRT 的典型应用场景
SRT 最适合的场景是点对点传输，尤其是上行链路不稳定的情况。比如：
- 野外直播（卫星、4G 聚合）
- 跨国视频会议
- 广电级信号回传
我曾经在一个体育赛事直播中，用 SRT 替代了传统的 SDI 光纤传输。现场网络环境极其恶劣，但 SRT 硬是扛住了 10% 的丢包率，画面只出现了轻微的马赛克，没有断流。嗯，这里要注意：SRT 的加密是内置的，不需要额外配置 TLS，这对安全敏感的场景很友好。
4.1.3 SRT 的局限性
SRT 也不是万能的。它最大的问题是延迟与可靠性的权衡。如果你把延迟设得太低（比如 120ms），遇到突发丢包就会频繁重传，反而导致卡顿。另外，SRT 是单向传输设计的，不适合双向实时通信（比如视频通话）。
避坑指南：我曾经在一个项目中把 SRT 延迟设为 200ms，结果在 4G 网络下频繁出现“画面暂停-快进”的现象。后来分析发现，是网络抖动导致重传请求堆积。建议在移动网络下至少设 500ms 起步。
4.2 QUIC 协议：HTTP/3 的底层引擎，流媒体的新宠
QUIC（Quick UDP Internet Connections）是 Google 搞出来的传输协议，现在已经是 HTTP/3 的底层协议了。它和 SRT 一样基于 UDP，但设计思路完全不同。QUIC 的目标是替代 TCP，而不是专门为流媒体优化。
4.2.1 QUIC 为什么适合流媒体？
QUIC 有几个特性，天然适合低延迟流媒体：
- 0-RTT 连接：第一次连接后，后续连接不需要握手，直接发数据。这对短连接场景（比如 HLS 的 TS 分片请求）非常友好。
- 多路复用：一个连接可以同时传输多个流，互不阻塞。不像 HTTP/2 那样，一个丢包会导致所有流都卡住。
- 前向纠错：QUIC 也支持 FEC，但实现上不如 SRT 成熟。
你想想看，传统的 HLS 用 TCP 传输，每个 TS 分片都要经历三次握手、慢启动、拥塞控制。如果网络不好，一个分片卡住，后面的分片都得排队。QUIC 的多路复用可以同时请求多个分片，互不影响。
4.2.2 QUIC 在流媒体中的实际应用
目前 QUIC 在流媒体中的落地，主要是替代 HTTPS 传输。比如：
- YouTube 已经在部分场景使用 QUIC 传输视频分片
- Facebook 的直播流也支持 QUIC
- 国内的快手、抖音也在测试 QUIC 加速
我个人建议，如果你的业务已经用了 HLS 或 DASH，可以尝试把底层传输从 TCP 换成 QUIC。不需要改上层协议，只需要服务器和客户端支持 HTTP/3 即可。
小技巧：QUIC 的 0-RTT 在流媒体场景下特别有用。比如用户切换清晰度时，QUIC 可以直接发送新的请求，不需要重新建立连接。我实测过，切换延迟从 500ms 降到了 100ms 以内。
4.2.3 QUIC 的坑
QUIC 也不是完美的。它最大的问题是中间设备兼容性。很多企业防火墙、NAT 设备对 UDP 不友好，可能会丢包或限速。另外，QUIC 的拥塞控制算法还在演进中，不如 TCP 的 BBR 成熟。
避坑指南：我曾经在一个金融客户的内网部署 QUIC，结果发现他们的防火墙把 UDP 包全部拦截了。最后只能回退到 TCP。建议在公网场景优先使用 QUIC，内网场景先做兼容性测试。
4.3 协议对比矩阵：一张表看懂怎么选
好了，四个协议都讲完了。咱们来做个横向对比。我整理了一张表，方便你快速决策。
| 维度 | WebRTC | HLS (LL-HLS) | SRT | QUIC |
|---|---|---|---|---|
| 传输层 | UDP + DTLS | TCP / QUIC | UDP | UDP |
| 延迟 | < 500ms | 2-6s | 120ms - 8s | 100ms - 2s |
| 抗丢包 | 中等（依赖 FEC） | 差（TCP 丢包即卡） | 强（ARQ + FEC） | 中等（FEC 可选） |
| 双向通信 | 原生支持 | 不支持 | 不支持 | 支持（需上层实现） |
| 加密 | DTLS-SRTP | HTTPS | 内置 AES | TLS 1.3 |
| 浏览器支持 | 原生 | 原生 | 需插件 / SDK | HTTP/3 支持 |
| 典型场景 | 视频通话、直播连麦 | 点播、直播（OTT） | 公网传输、广电回传 | 加速 HLS/DASH |
怎么选？我的经验是：
- 需要双向实时通信：直接上 WebRTC，别犹豫。
- 公网直播，网络不稳定：SRT 是首选，尤其是上行链路。
- 点播或直播，追求兼容性：LL-HLS 最稳妥。
- 想优化现有 HLS/DASH 的传输效率：把底层换成 QUIC。
4.4 协议选型决策流程图
下面这张图，是我根据多年经验总结的选型流程。你可以直接拿来用。
4.5 我的最终建议
协议选型没有标准答案。我见过太多团队，一开始就纠结“哪个协议最好”，结果项目拖了半年。我的建议是：先确定场景，再选协议。如果场景复杂，可以混合使用。比如上行用 SRT 传输，下行用 WebRTC 播放。
最后说一句：不要迷信任何协议。SRT 再强，也扛不住 50% 的丢包；QUIC 再快，也快不过局域网。选型的关键，是理解你的网络环境、用户需求和团队能力。