WebRTC / HLS / HTTP-FLV 的本质区别与选型指南
在做系统级直播（而不是自己本地播放）时，很多人都会遇到一个经典问题：
WebRTC、HLS、HTTP-FLV 到底有什么区别？
项目中到底该选哪个？
传输协议不同 → 延迟不同 → 兼容性 / 稳定性 / 成本不同
在系统里选哪个，核心看两点：
你要多低的延迟？你要多强的兼容和稳定？
一、简介
- WebRTC：超低延迟（0.2 ~ 1s），适合实时监控、无人机、实时指挥
- HLS（hls.js）：最稳、最通用（5 ~ 15s），适合活动直播、课程、公开大并发
- HTTP-FLV（flv.js）：中低延迟（1 ~ 3s），适合想比 HLS 低延迟，但不想用 WebRTC 的场景（内网大屏很常见）
二、核心对比表
| 方案 | 典型延迟 | 浏览器支持 | 稳定性 | 并发 / CDN | 成本与复杂度 | 典型用途 |
|---|---|---|---|---|---|---|
| WebRTC | 0.2 ~ 1s | 现代浏览器普遍支持 | 中-高（需调优） | 一般不走传统 CDN | 最高（信令 / ICE / NAT） | 无人机、监控、实时指挥、连麦 |
| HLS + hls.js | 5 ~ 15s | 最好（Safari 原生，其它用 hls.js） | 最高 | 最适合 CDN | 最低 | 课程、活动直播、回放、公开直播 |
| HTTP-FLV + flv.js | 1 ~ 3s | 支持 MSE 的浏览器（Safari 较弱） | 高（长时间可能延迟漂移） | 不如 HLS | 中 | 低延迟直播、内网直播、监控大屏 |
注：延迟是常见经验值，实际会受服务器性能、播放器缓冲策略、网络状况影响。
三、为什么三者差别会这么大？（底层原因）
1. WebRTC：为什么能做到超低延迟？
- 设计目标就是 实时音视频通信
- 使用 SRTP 等实时媒体通道
- 播放缓冲极小，边到边播
代价：
- 需要处理 NAT 穿透
- ICE / STUN / TURN 配置复杂
- 运维和排障成本高
👉 结论：只有“不用不行”的场景，企业才会用 WebRTC
2. HLS：为什么这么稳，但延迟高？
- 把直播切成一个个小分片（TS / fMP4）
- 播放器通常会缓存多个分片再播放
- 天生适合 CDN 和弱网环境
优点：
- 稳定性极高
- 兼容性最好
- 运维成本最低
缺点：
- 不适合低延迟（除非上 LL-HLS，复杂度上升）
👉 结论：“宁可慢点，也不能出问题”的首选
3. HTTP-FLV：为什么介于中间？
- 基于 HTTP 长连接持续推流
- 不需要等待分片生成
- 缓冲可以控制得比较小
特点：
- 延迟明显低于 HLS
- 实现简单
- 浏览器兼容性略弱（尤其 Safari）
- 长时间播放需处理延迟累积问题
👉 结论：企业内网、大屏、低延迟直播的“性价比之选”
四、最实用的选型建议
场景 1：像实时监控一样看画面（< 1 秒）
✅ WebRTC
场景 2：对外直播 / 课程 / 活动，稳定第一
✅ HLS（hls.js）
场景 3：比 HLS 低延迟，但不想折腾 WebRTC
✅ HTTP-FLV（flv.js）
尤其适合：内网 / 局域网 / 指挥大屏
五、结合项目：无人机 + 轨迹 + 地图
如果视频要和轨迹、地图、告警强同步：
- 首选 WebRTC
- 备选方案：
- 内网大屏：HTTP-FLV
- 公网/大并发：HLS
很多企业的实际架构是：
同一条源流，多协议输出，不同终端用不同协议
六、总结
HLS 是“稳”，FLV 是“快”，WebRTC 是“极致实时”
选型不是看技术多新，而是看业务“能不能等”
对外直播：HLS
内网大屏：FLV
实时指挥：WebRTC
关键系统：双协议兜底
这也是 ZLMediaKit / SRS 这类流媒体服务器一定要支持多协议输出的根本原因。
