视频核心技术 05：流媒体传输协议 —— RTMP、HLS、WebRTC 怎么选？延迟、卡顿、原理全解

摘要：把 RTMP、HLS、WebRTC 这三个最常见的流媒体协议彻底讲透。用生活化比喻解释它们的工作原理，重点拆解 HLS 切片机制、WebRTC 的超低延迟秘密、RTMP 的优缺点以及自适应码率 ABR 是怎么保障流畅播的。附带选型对比表，看完就能判断你的业务该用哪个协议。

1. 先分清"直播"和"点播"对协议的要求

点播：视频已经完整在服务器上，你想什么时候看就什么时候看，还能拖进度条。
直播：画面实时产生，观众要"同时"看到，不能等太久。

协议的本质就是搬运视频数据的那根管道。点播和直播对这根管道的要求完全不同：

点播：管道可以粗一点、稳一点，观众先缓冲几秒无所谓
直播：管道要细、要快，等 10 秒进球还没出来，体验就崩了

下面要聊的 RTMP、HLS、WebRTC，正是在"延迟"和"可靠性"之间做出了不同取舍的三种管道。

2. RTMP：Adobe 留下的直播老将

2.1 它是什么？

RTMP，全称 Real-Time Messaging Protocol，是 Adobe 为 Flash Player 打造的私有协议，专门用来在客户端和服务器之间低延迟地传输音视频数据。

Flash 在 2020 年已经正式退役，但 RTMP 在中国直播领域依然是**推流（主播端 → 服务器）**的实际行业标准。

2.2 工作方式：一根长水管

RTMP 基于 TCP 长连接。你可以把它想象成一根从主播推流端直连到服务器的不间断水管。

主播开播时，水管接好
音视频数据被打包成一个个小"水包"，持续不断地流过去
直到直播结束，水管才拆掉

因为 TCP 本身保证数据不丢、不乱序，所以 RTMP 传输的可靠性很高。只要网络不断，画面基本不会花屏或跳帧。

2.3 延迟表现：1～3 秒

RTMP 不用等文件切片，边采边发，端到端延迟通常能控制在 1～3 秒。对大多数直播场景，这个延迟完全可以接受。

2.4 致命弱点：不灵活

必须 Flash 才能播：浏览器端早已不能原生播放 RTMP 流，需要转成其他协议（比如转成 HTTP-FLV 或 HLS）才能让观众看到
穿墙能力弱：RTMP 用 1935 端口，很多企业防火墙会拦截这个端口
不支持自适应码率：一根水管一种规格，不能根据网络状况自动切换清晰度

2.5 现在的定位

只做推流，不做分发。 典型架构：主播端 → RTMP 推流到 CDN → CDN 转成 HLS/HTTP-FLV 分发给千万观众。

3. HLS：点播时代的切片之王

3.1 它是什么？

HLS（HTTP Live Streaming）由 Apple 在 2009 年推出，是基于 HTTP 的流媒体协议。它把一整条视频流切成无数个细碎的"小文件"，然后让播放器按顺序下载这些小文件来播放。

3.2 切片原理：把火腿切成薄片

想象你要吃一整根火腿肠，不可能一口吞下去。聪明的做法是切成很多薄片，一次吃一片。

HLS 就是这么干的：

切片：直播流被不停地切成一个个 .ts 小文件，每个片子大约 2～10 秒长（通常 6 秒）
索引文件 ：同时生成一个 .m3u8 的播放列表，里面按顺序记录所有 .ts 文件的网址
播放：播放器先下载 .m3u8，然后按列表逐个下载 .ts 文件，一个接一个连续播放

text

复制代码

m3u8 列表内容示意：

#EXTINF:6.0,
video_segment_001.ts
#EXTINF:6.0,
video_segment_002.ts
#EXTINF:6.0,
video_segment_003.ts
...

3.3 为什么延迟高？切片要时间

HLS 的延迟天然就比 RTMP 高，至少有一个切片周期的等待。

直播流进来，得先攒满一个 6 秒的 .ts 文件，才能发给播放器
播放器为保证不卡顿，通常还会再预加载 2～3 个切片（12～18 秒的缓冲）

所以常见延迟是 10～30 秒。切得越短延迟越低，但切片太短文件太多，HTTP 请求会爆炸，反而卡。

生活比喻 ：

RTMP 是用吸管给你一口气灌水（1～3 秒）。

HLS 是服务员把水倒进杯子，一杯一杯端给你，每端一杯都得等杯子满了才送。所以 HLS 不可能做到超低延迟，但它稳定、易分发。

3.4 最大优势：自适应码率（ABR）

HLS 有一个"多码率自适应"的超能力，让你的视频在波动网络下不卡顿、不糊成马赛克。

ABR 是怎么工作的？

服务器会同时切出多份不同画质的切片，比如：

高画质：1080P，码率 8 Mbps
中画质：720P，码率 3 Mbps
低画质：360P，码率 1 Mbps

这三份切片的.ts文件地址都写在同一份 .m3u8 的主播放列表里。播放器实时监测当前网速：

网速快 → 自动下载高清的 .ts
网速变慢 → 下一个切片马上降级下载标清的 .ts

切换发生在切片边界，平滑无缝，用户根本感觉不到。

这就是为什么你在地铁上看视频，画面一会儿清晰一会儿模糊，但从头到尾都没有转圈缓冲------ABR 在背后不停动态调整。

3.5 可靠性与分发

HLS 走普通的 HTTP 协议（端口 80/443），防火墙绝不会拦截，CDN 支持极好，能像普通网页一样被无限分发。理论上可以支撑任意规模并发，是大规模直播分发的首选。

4. WebRTC：音视频实时互动的终极方案

4.1 它是什么？

WebRTC（Web Real-Time Communication）是 Google 开源的浏览器实时通信技术。它的目标是让浏览器之间可以不依赖任何插件，直接进行音视频通话和数据传输。

如果说 RTMP 和 HLS 是"广播电视"模式，WebRTC 就是"打电话"------点对点，极低延迟。

4.2 超低延迟的四个秘密

秘密一：UDP 替代 TCP

TCP 是"稳但慢"的快递，丢一个包必须等重传成功，后面所有包都堵着不动。视频通话如果等 TCP 重传，对方早就满脸问号了。WebRTC 用 UDP，丢包就丢包，绝不回头等，画面最多花一下，但声音画面持续跑，延迟极低。

秘密二：不经过服务器中转（理想情况）

WebRTC 原生支持点对点直连。两个浏览器直接传数据，不用经过中央服务器。数据跑的路最短，延迟自然最低，可以做到 100ms 以内。

秘密三：NAT 穿透

大部分设备都在路由器后面，没有公网 IP，两个内网设备很难直接找到对方。WebRTC 内置 ICE/STUN/TURN 机制，帮它们"穿墙打洞"，建立直连。

秘密四：强制的音视频纠错

WebRTC 对音频使用 Opus 编码，内置超强丢包隐藏；视频用 H.264/VP8/VP9/AV1，有 FEC（前向纠错）和 NACK（重传请求），即使丢包 20% 也能保持通话基本清晰。

4.3 代价

架构复杂 ：大规模并发时很难完全点对点，必须引入媒体服务器（如 Janus、Mediasoup）做转发，增加成本
端到端加密是强制的，安全但增加计算开销
浏览器兼容性：主流浏览器都支持，但细节差异大，移动端表现不一

4.4 适用场景

视频会议、在线问诊、互动直播（主播与观众连麦）
云游戏、远程桌面（延迟要求 <50ms）
任何需要"面对面"实时交流的 Web 场景

5. 三大协议终极对比

维度	RTMP	HLS	WebRTC
传输协议	TCP	HTTP/TCP	UDP/TCP
延迟	1～3 秒	10～30 秒（可低至 3～5 秒）	< 500ms，通常 100ms 左右
分发能力	弱，需转协议	极强，标准 CDN 分发	中，需 SFU/Mixer 媒体服务器
自适应码率	不支持	原生支持	可配合 Simulcast 实现
浏览器支持	不能直接播	完全原生支持	完全原生支持
可靠性	高（TCP 不丢）	高（HTTP 重传）	中（允许丢包优先低延迟）
防火墙穿透	差（1935 端口）	优（80/443 端口）	优（但需 ICE 打通）
主要用途	推流	大规模直播分发、点播	视频通话、低延迟互动

6. 工程选型速查

你的需求	推荐协议	原因
主播推流到服务器	RTMP	简单成熟，编码器兼容好
大规模直播（观看端）	HLS	CDN 友好，ABR 防卡顿，并发无上限
低延迟直播（体育、电商）	HTTP-FLV 或 LHLS	延迟约 3～5 秒，比标准 HLS 快
视频会议、在线教育 1v1/小班	WebRTC	100ms 延迟，双向互动
直播连麦（主播与观众互动）	WebRTC + HLS 混合	连麦用 WebRTC，普通观众拉 HLS 流
海外直播或弱网环境	HLS + 多码率 ABR	自适应保流畅，穿墙能力强

7. 小结

RTMP：老牌推流协议，稳定可靠，但浏览器不能直接播，只适合做"第一棒"。
HLS：切片 + 自适应码率，延迟稍高但极其稳定，是大规模分发和点播的绝对主力。
WebRTC：延迟低到人耳无法察觉，打通了浏览器实时互动的最后一公里，适合一切需要"面对面"的场景。

它们不是替代关系，而是配合关系。一个标准的直播平台架构通常是这样：

text

复制代码

主播端 ──RTMP──→ CDN转码 ──HLS/HTTP-FLV──→ 千万观众
                            └──WebRTC──→ 连麦互动

把每根管道用在它最擅长的环节，你的流媒体架构就稳了。