传输协议选型（上）：RTMP协议原理、延迟瓶颈分析、适用场景与局限性

聊流媒体选型，RTMP 是个绕不开的老伙计。我最早接触它是在 2012 年做直播项目的时候，那时候 HLS 延迟高得离谱，WebRTC 还没成熟，RTMP 几乎是唯一的选择。十几年过去了，它还在用，但坑也踩了不少。今天咱们就把它扒开看看。

RTMP 协议原理：它到底怎么工作的？

RTMP 全称 Real-Time Messaging Protocol，是 Adobe 搞出来的。它基于 TCP，默认端口 1935。说白了，它就是在客户端和服务器之间维护一条长连接，然后在这条连接上跑音视频数据。

它的核心机制是 分块（Chunking）。音视频流被切成小块，每个块有头部和负载。这样做的好处是：

• 支持多路复用（一条连接传多路流）
• 支持优先级（音频块可以插队）
• 支持可变大小（小包降低延迟，大包提高效率）

我习惯把 RTMP 的握手过程记成三步：

1. C0/C1/S0/S1：版本协商 + 随机数据交换
2. C2/S2：回显对方随机数据，确认连接
3. 建立连接：发送 connect 命令，创建 NetConnection

握手完成后，客户端会创建 NetStream，然后就可以 publish（推流）或 play（拉流）了。嗯，这里要注意，RTMP 默认是推流协议，拉流虽然支持，但体验一般。

延迟瓶颈分析：为什么 RTMP 做不到超低延迟？

很多人问我：「RTMP 不是号称实时协议吗？为什么我推流出去还有两三秒延迟？」

原因其实不复杂。RTMP 的延迟瓶颈主要在以下几个地方：

瓶颈点	原因	典型延迟贡献
TCP 拥塞控制	TCP 的慢启动和拥塞避免机制，在网络抖动时会主动降低发送速率	200ms - 1s
GOP 大小	RTMP 必须等一个完整的 GOP 才能开始播放（除非开启即时解码刷新）	1 - 3s（取决于 GOP 设置）
缓冲区设置	播放器为了抗抖动，会缓存几百毫秒到几秒的数据	500ms - 2s
协议开销	RTMP 头部 + AMF 编码 + 控制消息，每帧都有额外开销	50ms - 200ms

我曾经在一个户外直播项目中遇到过极端情况：推流端用 4G 网络，TCP 因为丢包频繁重传，延迟直接飙到 8 秒。后来我们不得不把 GOP 从 2 秒缩到 0.5 秒，才勉强压到 3 秒以内。

适用场景：RTMP 还能打吗？

说实话，RTMP 在 2024 年的今天，已经不是最优解了。但它仍然有自己的一亩三分地：

• 推流到 CDN：国内主流 CDN 仍然支持 RTMP 推流，生态成熟
• OBS 等编码器：几乎所有直播软件默认推流协议都是 RTMP
• 企业内部监控：对延迟要求不高（3-5 秒可接受）的场景
• 老旧系统兼容：很多 2015 年前建设的系统只支持 RTMP

你想想看，如果只是做个普通的秀场直播，RTMP 完全够用。但如果你要做在线教育、远程医疗、或者互动游戏，那 RTMP 的延迟就有点捉襟见肘了。

局限性：RTMP 的硬伤

RTMP 的局限性，说白了就是「老」和「封闭」：

1. 基于 TCP：TCP 的队头阻塞（HOL Blocking）在弱网下是硬伤
2. 不支持 Web：浏览器原生不支持 RTMP，必须靠 Flash（已死）或插件
3. 加密复杂：RTMPE/RTMPS 虽然支持加密，但配置麻烦，兼容性差
4. 扩展性差：协议设计年代久远，不支持 FEC、SVC 等现代特性
5. 延迟天花板：再怎么优化，也很难低于 1 秒

RTMP 协议架构与延迟链路

下面这张图是我自己画的，把 RTMP 从推流到播放的完整链路和延迟瓶颈标了出来。你看一眼就明白了。

从图上你能看到，延迟主要卡在三个地方：编码时的 GOP 等待、TCP 传输时的网络抖动、以及播放端的缓冲区。这三个点只要有一个没调好，延迟就下不来。

RTMP 的替代方案：什么时候该换？

我个人的经验是，如果你遇到以下情况，就该考虑换协议了：

• 延迟要求低于 1 秒 → 换 WebRTC
• 弱网环境（丢包率 > 5%）→ 换 SRT 或 QUIC
• 需要浏览器直接播放 → 换 HLS 或 WebRTC
• 需要支持 4K/8K 高码率 → 换 SRT（FEC 抗丢包更好）

但话说回来，RTMP 在推流到 CDN 这个场景上，短期内还死不了。毕竟 CDN 厂商的 RTMP 接入点遍布全球，生态太成熟了。你只需要记住：RTMP 适合做「传输中间件」，不适合做「终端播放协议」。