传输协议选型：WebRTC vs RTMP vs HLS vs SRT

做低延迟流媒体，第一个绕不开的坎就是协议选型。我见过太多团队，架构画得漂漂亮亮，结果协议选错，延迟直接崩到十几秒。今天咱们把这四个主流协议掰开揉碎，看看它们到底适合什么场景。

先给个直观数据。我习惯把延迟分成三个档位：

注意，这是理想网络下的数据。实际项目中，HLS 跑到 40 秒我都见过。为什么会这样？后面细说。

WebRTC 的设计目标就是「人跟人说话不能有延迟感」。200ms 以内，这是它的底线。

核心原理：它基于 UDP，走的是 P2P 直连。没有分片、没有缓冲队列，数据到了就渲染。我参与过一个在线教育项目，老师板书和学生端必须同步在 300ms 以内，当时选 WebRTC 几乎是唯一解。

适用场景：视频会议、远程医疗、在线教育、云游戏、直播连麦。

避坑指南：我曾经在一个跨国会议项目里踩过坑——WebRTC 的 ICE 穿透在对称 NAT 环境下成功率只有 70% 左右。后来加了 TURN 中继，延迟虽然涨到 400ms，但至少能连上了。嗯，这里要注意，TURN 服务器带宽成本很高，一台 10Gbps 的机器一天能烧掉几千块。

SRT 是 Haivision 开源的协议，本质是在 UDP 上做 ARQ（自动重传）和 FEC（前向纠错）。说白了，它既要 UDP 的低延迟，又要 TCP 的可靠性。

我为什么推荐 SRT：在弱网环境下，SRT 的表现比 RTMP 好太多。我记得有一次给某省级电视台做直播推流，上行带宽只有 2Mbps，丢包率 5%。RTMP 直接卡死，SRT 靠着 FEC 硬扛下来了，延迟控制在 1.5 秒以内。

个人习惯：做直播推流时，如果网络条件差，我优先选 SRT。如果网络好且需要低延迟，才考虑 RTMP。

RTMP 是 Adobe 在 2000 年代初推出的协议，基于 TCP 长连接。它曾经是直播行业的标配，现在嘛……有点老了。

优点：生态成熟，几乎所有编码器和 CDN 都支持。延迟能做到 2-5 秒，对于非互动场景够用。

致命伤：TCP 的队头阻塞。你想想看，如果网络丢了一个包，TCP 要等重传，后面的数据都得排队。我做过测试，在 2% 丢包率下，RTMP 延迟直接飙到 15 秒以上。

注意：RTMP 默认只支持 Flash，现在浏览器已经全面禁用 Flash。如果要走 Web 播放，必须转封装成 HLS 或 WebRTC。多一层转封装，就多一层延迟。

HLS 是 Apple 推出的，基于 HTTP 的流媒体协议。它的核心思路是「切分 + 索引」：把视频切成 2-10 秒的小片段，客户端通过 m3u8 索引文件拉取。

延迟为什么高？因为至少要等一个分片下载完才能播放。如果分片是 6 秒，那延迟至少 6 秒。再加上索引文件的更新周期，10 秒以上很常见。

不过，Apple 后来推出了 Low-Latency HLS（LL-HLS），把分片切到 1 秒以内，延迟能降到 3-5 秒。但部署起来比较麻烦，需要 CDN 支持。

版本	分片大小	典型延迟	部署难度
标准 HLS	6-10s	10-30s	低
LL-HLS	0.5-1s	3-5s	高

适用场景：标准 HLS 适合点播和延迟不敏感的大规模直播（如体育赛事、电视直播）。LL-HLS 适合需要兼容 iOS 生态的低延迟场景。

我一般按这个逻辑选协议：

你想想看，实际项目中很少只用一种协议。我做过一个直播平台，主播端用 SRT 推流，服务端转封装，观众端根据网络情况自动切换 WebRTC（低延迟模式）和 HLS（高兼容模式）。

下面这张图是我自己整理的协议选型框架，涵盖了传输层、延迟、抗丢包和适用场景四个维度：

协议选型没有银弹。我见过有人非要用 WebRTC 做点播，结果服务器成本翻了 10 倍。也见过有人死守 RTMP，结果用户投诉延迟高到没法用。

我的建议是：先定延迟目标，再选协议，最后做混合架构。延迟目标定在 500ms 以内，就老老实实上 WebRTC。定在 2-3 秒，SRT 加 LL-HLS 的组合很香。如果只是做电视直播，标准 HLS 完全够用，别折腾。