扫一扫
问题一：RTMP、HTTP-FLV、HLS 的主要区别是什么？
我们可以从 协议基础、传输方式、延迟、兼容性 四个核心维度来对比。
| 特性维度 | RTMP | HTTP-FLV | HLS |
|---|---|---|---|
| 协议基础 | Adobe 私有协议，基于 TCP，使用默认端口 1935。是一个长连接的实时流协议。 | 本质上就是 FLV 格式的视频流，通过 HTTP 协议 进行传输。使用标准 HTTP 端口（80/443），也是一个长连接。 | Apple 推出的开放标准。基于 HTTP 协议，但其核心是一系列短小的 TS 文件切片 和一个不断更新的 m3u8 索引文件。 |
| 传输方式 | 建立 TCP 长连接后，数据以 FLV Tag 的形式流式地、持续地从服务器推送到客户端。 | 建立 TCP（HTTP）长连接后，服务器将 FLV 文件头 和下行的 FLV Tag 流式地、持续地发送给客户端。 | 分片下载。客户端先下载 .m3u8 索引文件，然后按顺序下载一个个完整的 .ts 视频切片文件。播完一个，再下载下一个。 |
| 延迟 | 较低，通常为 1-3 秒。数据是流式的，几乎没有等待间隔。 | 很低，通常为 1-3 秒（可优化至1秒内）。原理同 RTMP，且更高效。 | 很高，通常为 10-30 秒。延迟由切片时长（通常2-10秒）和缓冲切片数量（通常3个以上）共同决定。 |
| 兼容性 | PC 端极好（Flash Player），移动端极差（iOS/Android 已不再支持 Flash）。 | Web 端依赖 flv.js（一个用 JavaScript 写的 FLV 播放器），移动端原生支持差，需要集成特定 SDK。 | 原生支持极好。所有 iOS、Android 设备和现代浏览器都原生支持 HLS，是移动端和 HTML5 的通用标准。 |
| 核心特点 | 实时性强，是直播领域的元老协议。但受 Flash 消亡影响，目前主要用于推流（OBS 推流到服务器）。 | 延迟低，穿透性好（防火墙/代理不拦截 HTTP 流量），是当前PC浏览器低延迟直播的主流方案。 | 兼容性无敌，穿透性极好。非常适合移动端和高并发分发（CDN 缓存 .ts 文件非常高效）。 |
一句话总结：
- RTMP： 曾经的王者，现在主要用于推流。
- HTTP-FLV： 低延迟直播在 PC 浏览器上的最佳选择。
- HLS： 高兼容性、高可靠性的通用方案，是移动端和 CDN 分发的标准，但延迟高。
问题二：为什么说 HTTP-FLV 比 RTMP 延迟更低？
这是一个非常有趣的问题，因为它反直觉——两者传输的都是 FLV 格式的流数据，理论上延迟应该一样。但在实际部署中，HTTP-FLV 通常表现出比 RTMP 更稳定、更低的延迟。核心原因不在于协议本身，而在于协议栈的实现和网络环境。
以下是详细解释：
1. 握手过程的开销不同（主要因素）
-
RTMP 握手： 建立连接时需要完成一个复杂的 “三次握手” 过程。
- C0+S0：客户端和服务器发送版本号。
- C1+S1：交换时间戳和随机数据块。
- C2+S2：验证对方发来的数据。
- 这个过程会产生 3 个来回的网络延迟，在网络状况不佳时，会显著增加连接建立时间。
-
HTTP-FLV 握手： 本质上是 HTTP 请求。
- 客户端发起一个普通的 HTTP GET 请求。
- 服务器返回 HTTP 响应头，然后直接开始流式传输 FLV 数据。
- 这个过程通常只需要 1 个来回的网络延迟。
结论： 在需要频繁重连的场景下，HTTP-FLV 建立连接的速度更快，初始延迟更小。
2. 协议栈的处理效率不同
-
RTMP 是一个独立的、复杂的应用层协议。操作系统和中间网络设备（路由器、防火墙）对其优化有限。服务器和播放器需要专门实现一套 RTMP 协议栈。
-
HTTP-FLV 基于 HTTP/1.1，这是互联网的基石协议。
- 操作系统级优化： 操作系统对 TCP/IP 和 HTTP 协议栈有极致的优化。
- 网络设备友好： 所有的网络设备（防火墙、代理、负载均衡器）都对 HTTP 流量有最好的支持和最少的干扰。它不会被误认为是非常用协议而受到限制。
- 服务器处理高效： Web 服务器（如 Nginx）处理 HTTP 请求的性能已经过千锤百炼，极其高效。
3. 流式传输 vs 分块传输
-
RTMP 严格按消息和块大小来传输，设计精密但也略显繁琐。
-
HTTP-FLV 在 HTTP/1.1 下，可以使用
Transfer-Encoding: chunked（分块传输编码）或直接流式传输。这种“简单粗暴”的方式，在实现得当时，效率非常高，减少了协议解析带来的开销。
一个生动的比喻：
-
RTMP 就像两个国家元首进行正式会谈。需要先进行一套完整的、正式的礼节和流程（三次握手），然后才能开始谈正事。虽然严谨，但开场较慢。
-
HTTP-FLV 就像两个老朋友打电话。拨通后（TCP连接），直接说“喂，是我，开始说正事”（HTTP请求），然后就开始聊了。开场非常迅速自然。
总结
“从协议设计的理论层面讲，RTMP 和 HTTP-FLV 的流式传输模式决定了它们的延迟应该在同一个量级（1-3秒）。但在实际应用中，HTTP-FLV 通常能做到比 RTMP 更低、更稳定的延迟，主要原因有三点：”
- 连接建立效率：HTTP-FLV 基于 HTTP，一次简单的握手即可开始传输数据；而 RTMP 需要三次握手，在网络差时重连慢，增加了初始延迟。
- 网络环境友好性：HTTP 是标准协议，穿透防火墙和代理的能力极强，不会被错误拦截或限制，保证了传输的稳定性。
- 协议栈优化：整个互联网的基础设施（操作系统、网络设备、服务器）都对 HTTP 有极致优化，处理效率更高，开销更小。
“因此，在追求低延迟的 PC 浏览器直播场景下，HTTP-FLV 是比 RTMP 拉流更优的选择。”
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
