2. 流媒体基础
做流媒体的人，迟早要面对一个问题：选哪个传输协议？
我见过不少团队，上来就拍脑袋选 RTMP，结果直播延迟 5 秒，用户骂娘。也见过有人硬上 WebRTC，结果弱网环境下卡成幻灯片。说白了，没有万能的协议，只有最合适的场景。
这一章，我把四个主流协议掰开揉碎讲清楚。咱们不聊虚的，直接看延迟、看架构、看坑。
2.1 四协议核心参数速览
先给个总表，方便你快速对比。我习惯把这四个协议按延迟分成两档：秒级和毫秒级。
| 协议 | 典型延迟 | 传输层 | 推流/拉流 | 浏览器支持 |
|---|---|---|---|---|
| RTMP | 1-3 秒 | TCP | 推流为主 | 需 Flash/插件 |
| HLS | 6-30 秒 | HTTP/TCP | 拉流为主 | 原生支持 |
| WebRTC | 200-500 毫秒 | UDP | 双向 | 原生支持 |
| SRT | 0.5-2 秒 | UDP | 推拉均可 | 需 SDK |
关键结论：延迟越低，对网络的要求越高。WebRTC 能做到毫秒级，但丢包率超过 5% 就开始难受。HLS 延迟高，但抗抖动能力最强。
2.2 RTMP：老将不死，但已退居幕后
RTMP 是 Adobe 在 2009 年推出的协议。我入行那会儿，几乎所有直播平台都用它推流。为什么？因为它稳定，而且延迟能做到 1-3 秒，在当时已经算很好了。
但 RTMP 有个硬伤：它依赖 Flash。现在浏览器早就抛弃 Flash 了，所以 RTMP 基本只用于推流端——也就是主播往服务器发数据那一段。
我的经验：如果你做的是传统直播（非互动类），推流用 RTMP，拉流转成 HLS 或 HTTP-FLV，这是目前最成熟的方案。我在 2018 年帮一个教育平台做改造，就是这套架构，稳定跑了三年没出过大问题。
RTMP 的延迟瓶颈在哪？
- TCP 的拥塞控制：网络抖动时会自动降速，导致延迟增加
- 缓冲区设置：默认缓冲区偏大，为了抗抖动牺牲了延迟
- 不支持 FEC（前向纠错）：丢包只能重传，进一步增加延迟
2.3 HLS：苹果的「慢」哲学
HLS 是苹果推出的协议，核心思路是把视频切成一个个小片段（通常是 2-10 秒），然后通过 HTTP 传输。浏览器原生支持，不需要任何插件。
但代价就是延迟高。为什么？
- 切片等待：必须等一个完整的切片生成才能传输
- 播放器缓冲：播放器通常会缓存 2-3 个切片才播放
- 索引文件更新：m3u8 文件需要定期刷新
举个例子：如果你用 6 秒的切片，播放器缓存 2 个切片，那延迟至少 12 秒。再加上网络传输和服务器处理，20 秒很常见。
注意：HLS 有低延迟模式（LL-HLS），可以把延迟降到 2-5 秒。但需要服务器和播放器都支持，而且配置起来比较麻烦。我曾经在一个项目中尝试过，最后因为 CDN 兼容性问题放弃了。
HLS 适合什么场景？
- 点播：延迟无所谓，兼容性第一
- 大型直播：用户量巨大，CDN 分发成本低
- 弱网环境：自动切换码率，体验比 RTMP 好
2.4 WebRTC：毫秒级延迟的代价
WebRTC 是谷歌主导的开源项目，目标是实现浏览器之间的实时通信。延迟能做到 200-500 毫秒，这是其他协议望尘莫及的。
但 WebRTC 不是银弹。我见过太多人一听说「毫秒级延迟」就往上冲，结果被坑得头破血流。
WebRTC 的痛点：
- 信令服务器：需要自己搭建，协议复杂
- STUN/TURN：内网穿透不是 100% 成功，TURN 服务器带宽成本高
- 弱网表现：丢包率超过 10% 基本不可用
- 大规模分发：WebRTC 是点对点架构，做万人直播需要转码成 HLS
避坑指南：我曾经给一个在线教育客户做方案，他们要求延迟低于 1 秒。我推荐了 WebRTC，结果上线后发现，有 20% 的用户因为防火墙问题连不上。最后加了 TURN 服务器，带宽成本直接翻了三倍。所以，用 WebRTC 之前，一定要评估你的用户网络环境。
WebRTC 适合什么场景？
- 视频会议：延迟敏感，用户量小
- 互动直播：连麦、弹幕、实时互动
- 远程医疗/教育：需要低延迟和高可靠性
2.5 SRT：专为「烂网」设计的协议
SRT 是 Haivision 在 2017 年开源的协议，基于 UDP，但加入了 TCP 的可靠性机制。说白了，它想同时拥有 UDP 的低延迟和 TCP 的可靠性。
SRT 的核心技术是：
- ARQ（自动重传请求）：丢包时只重传丢失的数据包，而不是整个数据块
- FEC（前向纠错）：发送冗余数据，接收端可以直接恢复丢包
- 动态缓冲区：根据网络状况自动调整缓冲区大小
我为什么喜欢 SRT？因为它对网络的要求比 WebRTC 低得多。在 20% 丢包率下，SRT 还能保持流畅播放，而 WebRTC 早就卡死了。
我的建议：如果你做的是广电级别的直播，或者用户网络环境很差（比如跨国传输、卫星链路），SRT 是最好的选择。我在一个体育直播项目中用过 SRT，从欧洲传回国内，延迟控制在 1.5 秒以内，效果非常稳定。
SRT 的缺点：
- 浏览器不支持：需要客户端 SDK 或转码
- 配置复杂：缓冲区、延迟、FEC 参数需要调优
- 生态不如 RTMP/HLS 成熟
2.6 协议选择决策树
说了这么多，到底怎么选？我画了一张图，帮你快速决策。
2.7 实战建议：混合架构才是王道
在实际项目中，我很少只用一种协议。更常见的做法是混合架构：
- 推流端：用 RTMP 或 SRT（取决于网络环境）
- 服务端：转码成多种格式，适配不同终端
- 拉流端：HLS 给普通用户，WebRTC 给互动用户
举个例子：一个在线教育平台，老师端用 RTMP 推流，服务器转成 HLS 给大部分学生看，同时保留一路 WebRTC 给需要连麦互动的学生。这样既保证了大规模分发的成本，又满足了互动场景的低延迟需求。
最后说一句：协议只是工具，别被工具绑架。理解每个协议的优缺点，根据你的场景做选择，这才是工程师该干的事。