23、HLS与RTMP对比：HLS协议原理、HLS与RTMP延迟对比、HLS与RTMP适用场景
聊到直播和点播，RTMP 和 HLS 这两个协议是绕不开的。很多刚入行的朋友会问我：“到底该用哪个？” 我的回答通常是：“看场景，没有银弹。”
今天我们就来掰开揉碎，把 HLS 的原理讲清楚，再跟 RTMP 做个全方位的对比。我做了这么多年音视频，在这两个协议上踩过的坑，今天一并分享给你。
HLS 协议原理：苹果的切片大法
HLS，全称 HTTP Live Streaming，是苹果搞出来的。它的核心思想很简单：把一整段视频流，切成一个个小文件。
你想想看，传统的流媒体协议（比如 RTMP）是长连接，服务器一直推数据给你。HLS 不一样，它走的是 HTTP 协议。服务器先把视频切成一个个 2-10 秒的 TS 切片，然后生成一个索引文件（m3u8）。播放器先下载这个 m3u8 文件，知道有哪些切片，然后按顺序一个个去下载播放。
这个过程，说白了就是“边下边播”。
- 切片器：将原始视频流切割成多个 TS 文件（每个 2-10 秒）。
- 索引文件：生成一个 .m3u8 文件，记录所有切片的 URL 和时长。
- 客户端：下载 m3u8，解析后按顺序下载 TS 切片并播放。
这里有个关键点：切片时长。我见过很多新手把切片设成 1 秒，觉得延迟低。结果呢？服务器压力巨大，客户端频繁请求，反而卡顿。我个人习惯，直播场景用 2-3 秒切片，点播场景用 6-10 秒。
为什么会这样？因为切片越短，m3u8 文件更新越频繁，客户端请求次数就越多。你想想看，如果 1 秒一个切片，那 1 分钟就要请求 60 次。而 6 秒一个切片，1 分钟只请求 10 次。网络波动时，后者明显更稳定。
HLS 与 RTMP 延迟对比
这是大家最关心的问题。直接说结论：RTMP 延迟低，HLS 延迟高。
| 协议 | 典型延迟 | 延迟原因 |
|---|---|---|
| RTMP | 1-3 秒 | 长连接，实时推送，无切片等待 |
| HLS | 6-30 秒 | 切片生成 + 索引更新 + 客户端缓冲 |
RTMP 为什么快？因为它是一条 TCP 长连接，数据到了就推。服务器收到一帧，立刻转发给客户端。延迟主要在网络传输上。
HLS 为什么慢？我们来算一笔账。假设切片时长是 6 秒，服务器需要等够 6 秒才能生成一个切片。然后更新 m3u8 文件，客户端再下载。这还没完，客户端为了流畅播放，通常会缓冲 2-3 个切片。所以延迟至少是：切片时长 × (1 + 缓冲个数)。6 秒 × 3 = 18 秒，很正常。
嗯，这里要注意：HLS 的延迟是“硬伤”，这是协议设计决定的。苹果当初设计 HLS 时，优先考虑的是兼容性和稳定性，而不是低延迟。所以，如果你做的是连麦、互动游戏这类场景，RTMP 是唯一选择。
HLS 与 RTMP 适用场景
搞清楚了延迟差异，场景选择就清晰了。
RTMP 适合的场景
- 互动直播：连麦、弹幕、礼物，延迟必须控制在 3 秒以内。
- 推流端：RTMP 是推流的事实标准，几乎所有编码器都支持。
- 低延迟监控：比如安防监控，需要实时看到画面。
我记得有一次做教育直播，老师需要看到学生的实时反馈。用 RTMP 推流，延迟 2 秒左右，师生互动很流畅。如果换成 HLS，老师问完问题，学生 20 秒后才看到，那课就没法上了。
HLS 适合的场景
- 点播：视频网站、课程回放，延迟无所谓，兼容性第一。
- 大规模直播：HLS 走 HTTP，CDN 支持极好，可以轻松支持百万级并发。
- 跨平台播放：iOS、Android、Web 都原生支持 HLS，不需要额外插件。
你想想看，为什么抖音、快手用 HLS？因为它们面对的是海量用户，CDN 分发是核心。延迟高几秒无所谓，用户刷视频时，那几秒的延迟根本感知不到。但如果你做的是在线教育、视频会议，那 RTMP 就是刚需。
一张图看懂 HLS vs RTMP
下面这张图，是我自己总结的对比框架。你可以把它当作选型参考。
我的选择建议
如果你现在要做一个直播系统，我的建议是：
- 推流端用 RTMP：这是行业标准，编码器、OBS 都支持，没得选。
- 播放端看场景：
- 互动场景（连麦、教育）：用 RTMP 或 WebRTC。
- 点播或大规模直播：用 HLS。
- 混合方案：很多大厂的做法是，推流用 RTMP，服务端转码成 HLS 和 RTMP 两路。RTMP 给互动用户，HLS 给普通观众。这样既保证了互动体验，又兼顾了大规模分发。
嗯，最后说一句：没有最好的协议，只有最合适的场景。理解了 HLS 和 RTMP 的原理和差异，你就能根据业务需求做出正确的选择。