流媒体协议（四）：RTMP、HLS、WebRTC，直播推拉流到底是怎么回事？

前几篇我们把视频和音频分别压缩好了。现在问题来了：这些数据怎么从主播的摄像头，传到几万观众的手机上？一根网线扛不住几万人同时拉流——流媒体协议就是解决"一对多实时分发"的。

大家好，我是黒漂技术佬。

我做智慧农业的大棚监控那会儿，需要把 RTSP 摄像头画面推到 Web 端和小程序端实时观看。这中间涉及 RTSP 拉流 → FFmpeg 转 RTMP 推流 → 流媒体服务器 → HLS/WebRTC 分发 一整条链路。这一篇，我把这条链路上的每一个协议掰开揉碎讲清楚。

---

一、流媒体的核心矛盾：延迟 vs 兼容性

所有流媒体协议都在两个指标之间做取舍：

低延迟 ←——————————————————→ 高兼容性 / 稳定性
 (WebRTC)      (RTMP)    (HLS)

• 要极致低延迟（视频会议、云游戏）：选 WebRTC，端到端 < 1 秒。
• 要普适兼容（手机浏览器看直播）：选 HLS，几乎所有设备原生支持，但延迟 5~30 秒。
• 中间方案（PC 直播、传统 CDN）：RTMP/HTTP-FLV，延迟 2~5 秒。

没有银弹，选型永远看场景。

---

二、RTMP：直播行业的"上古神器"

RTMP（Real-Time Messaging Protocol） 是 Adobe 在 2002 年为 Flash 播放器设计的协议，基于 TCP 长连接。虽然 Flash 在 2020 年正式入土，但 RTMP 依然活跃在推流端。

2.1 RTMP 的工作模式

推流端（OBS / FFmpeg）         流媒体服务器（nginx / SRS）       观众端（浏览器 / App）
     │                               │                               │
     ├──── RTMP 推流 ────────────────►│                               │
     │   rtmp://server/live/room1     │                               │
     │                               ├──── HTTP-FLV / HLS 分发 ──────►│
     │                               │   http://server/live/room1.flv │

推流用 RTMP，但拉流（观众看）在现代浏览器里不能直接用 RTMP——浏览器不支持 Flash 了。所以服务器收到 RTMP 流后，会转成 HTTP-FLV 或 HLS 再分发给观众。这就是典型的"RTMP 进，多协议出"。

2.2 RTMP 的优缺点

优点	缺点
延迟低（2~5 秒）	浏览器原生不支持拉流
OBS/FFmpeg/几乎所有直播软件都支持推流	基于 TCP，弱网容易卡
生态极成熟，CDN 普遍支持	Adobe 已停更，技术不再演进

RTMP 还在用的原因单纯是：推流端没有更好的替代者。 WebRTC 推流复杂，SRT 推流设备支持少，RTMP 虽然老，但够用。

---

三、HLS：苹果的"万能胶协议"

HLS（HTTP Live Streaming） 是苹果在 2009 年推出的流媒体协议。它的核心思路出奇简单：把直播流切成一个个小文件（.ts），用 HTTP 分发给观众。

3.1 HLS 工作流程

推流端 ──RTMP──► 流媒体服务器
                      │
             ┌────────┴────────┐
             │  切片器（m3u8）  │
             └────────┬────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
  live001.ts    live002.ts    live003.ts  ...（每个 2~10 秒）
        │             │             │
        └─────────────┴─────────────┘
                      │
            live.m3u8（播放列表）
            ┌───────────────────────────────────┐
            │ #EXTM3U                            │
            │ #EXT-X-TARGETDURATION:5            │
            │ #EXTINF:5.0,                       │
            │ live001.ts                         │
            │ #EXTINF:5.0,                       │
            │ live002.ts                         │
            │ #EXTINF:5.0,                       │
            │ live003.ts                         │
            └───────────────────────────────────┘
                      │
                      ▼
            观众浏览器：读取 m3u8 → 按列表顺序下载 ts → 播放

3.2 为什么 HLS 的延迟那么高？

因为播放器必须缓存至少 2~3 个 ts 分片才敢开始播放（防止网络抖动导致中断）。一般每个分片 5~10 秒，加上编码和传输，延迟自然就上去了。

降低 HLS 延迟的方法：缩小分片时长到 2 秒，播放器缓存降到 2 片。但代价是 HTTP 请求频率变高，服务器压力增大，网络差的观众更容易卡。

3.3 HLS 的核心优势

• 所有浏览器原生支持：iOS Safari、Android Chrome、PC 浏览器，全都不用装插件。
• 天然穿透防火墙和 CDN：走标准 HTTP/HTTPS，跟普通网页请求一样，不会被企业防火墙拦截。
• 自适应码率（ABR）：一个 master.m3u8 里可以列出 480P / 720P / 1080P 三路流，播放器根据网速自动切换——网络差自动降画质，不中断。

---

四、HTTP-FLV：RTMP 的"轻量替身"

HTTP-FLV 本质就是把 RTMP 的 FLV 数据包通过 HTTP 长连接持续传输。延迟接近 RTMP（2~5 秒），但浏览器通过 HTML5 的 MSE（Media Source Extensions）就能播。

B 站直播网页端用的就是 HTTP-FLV（配 flv.js）。不过 flv.js 只支持 H.264 + AAC，H.265 需要 hls.js 或 WebRTC。

协议	延迟	浏览器支持	代表场景
RTMP	2~5s	❌ 需插件	推流端
HTTP-FLV	2~5s	✅ flv.js	B 站网页直播
HLS	5~30s	✅ 原生支持	手机直播、点播
WebRTC	< 1s	✅ 原生 API	视频会议、低延迟直播

---

五、WebRTC：实时通信的"瑞士军刀"

WebRTC（Web Real-Time Communication） 是 Google 在 2011 年开源的实时通信框架，浏览器内置，不需要任何插件。

5.1 WebRTC 做了什么？

它把一整套实时通信技术打包进了浏览器：

• 音视频编解码：内置 Opus 音频、VP8/VP9/H.264 视频编码。
• NAT 穿透：STUN / TURN 协议，自动解决内网穿透问题。
• 点对点传输：默认 P2P，数据不经过服务器中转（除非 TURN）。
• 安全加密：强制 DTLS + SRTP 加密，中间人无法窃听。

5.2 WebRTC 不等于"不用服务器"

这是个常见误解。WebRTC 的 P2P 需要在两端建立连接，中间需要：

• 信令服务器（Signaling Server）：交换 SDP（会话描述）和 ICE 候选地址。WebRTC 标准故意没规定信令协议——你可以用 WebSocket、MQTT，甚至两只鸽子传纸条。
• STUN/TURN 服务器：解决 NAT 穿透。两个都在内网的设备，大概率需要 TURN 服务器中转——这时候就不是真正的 P2P 了。

5.3 一对多直播用 WebRTC？

P2P 天生是一对一。要做一对多，需要 SFU（Selective Forwarding Unit，选择性转发单元）：

主播 ──► SFU 服务器 ──► 观众 1
                   ──► 观众 2
                   ──► 观众 3
                   ──► ...

SFU 收到主播的一路流，转发给每个观众。观众端仍然只是"一对一"连接 SFU，不需要直连主播。主流 SFU 开源方案：mediasoup、Janus、LiveKit。

---

六、实战选型速查表

你的场景	推荐方案
传统直播（游戏、秀场），延迟 2~5 秒可接受	RTMP 推流 + HTTP-FLV + HLS 分发
手机 App 直播，观众全在移动端	RTMP 推流 + HLS 分发
视频会议 / 在线教育 / 低延迟交互	WebRTC + SFU
监控摄像头画面拉到 Web 端	RTSP → FFmpeg 转 RTMP → nginx-rtmp → HTTP-FLV
无人机图传 / 远程遥控	WebRTC（超低延迟） 或 SRT（弱网优化）
海外分发	HLS + CDN（CloudFront / Cloudflare）

---

本篇核心回顾

协议	诞生	延迟	传输基础	现状
RTMP	2002 Adobe	2~5s	TCP	推流标配，拉流不用了
HLS	2009 Apple	5~30s	HTTP	移动端直播王者
HTTP-FLV	国产衍生	2~5s	HTTP 长连接	B 站等 PC 端在用
WebRTC	2011 Google	<1s	UDP + P2P	实时通信首选

知道这些协议是什么、延迟多少、谁在用，你已经超过 90% 的同行了。

我是黒漂技术佬，下篇见。