RTMP 协议精讲 / 01 - RTMP 协议概述
RTMP 协议概述
1.1 什么是 RTMP
RTMP(Real-Time Messaging Protocol,实时消息传输协议)是一种基于 TCP 的应用层协议,专为在 Flash Player 与流媒体服务器之间高效传输音视频数据和控制消息而设计。
核心特征
| 特性 | 说明 |
|---|---|
| 传输层 | TCP,端口 1935(默认) |
| 通信模型 | 长连接、双向通信 |
| 数据单元 | 消息(Message)→ 块(Chunk) |
| 编码格式 | AMF(Action Message Format) |
| 延迟 | 1-3 秒(典型) |
| 加密 | RTMPE / RTMPS(TLS) |
┌──────────┐ TCP:1935 ┌──────────────┐
│ 编码器 │◄─────────────►│ RTMP 服务器 │
│ (OBS等) │ RTMP 协议 │ (SRS/Nginx) │
└──────────┘ └──────────────┘
推流端 服务端
1.2 Adobe 历史沿革
发展时间线
2002 ─── Macromedia 开发 RTMP,用于 Flash Communication Server
│
2003 ─── Flash Player 开始支持 RTMP
│
2005 ─── Adobe 收购 Macromedia
│
2009 ─── Adobe 公开 RTMP 规范 (June 2009)
│
2012 ─── RTMP 规范最终版 (Adobe's Video Technology)
│
2014 ─── Chrome 开始默认禁用 Flash
│
2017 ─── Adobe 宣布 2020 年底停止 Flash Player
│
2020 ─── Flash Player 正式退役,RTMP 在推流端继续活跃
│
2026 ─── RTMP 仍是推流端事实标准,被所有主流编码器支持
关键里程碑
- 2002 年:Macromedia 在 Flash Communication Server MX 中首次引入 RTMP
- 2009 年:Adobe 首次公开 RTMP 规范,此前协议一直是私有的
- 2012 年:发布最终版规范,定义了协议的完整细节
- 2020 年:Flash 退役后,RTMP 协议由开源社区继续维护
注意:RTMP 规范虽已公开,但 Adobe 从未将其提交为正式的 IETF 标准。这意味着不同实现之间可能存在细微差异。
1.3 RTMP 协议族
RTMP 不是单一协议,而是一个协议族:
| 协议 | 全称 | 用途 | 传输层 |
|---|---|---|---|
| RTMP | Real-Time Messaging Protocol | 基础协议,明文传输 | TCP/1935 |
| RTMPS | RTMP over TLS | 加密传输(HTTPS 风格) | TLS/443 |
| RTMPE | RTMP Encrypted | Adobe 私有加密(不含证书) | TCP/1935 |
| RTMPT | RTMP Tunneled | HTTP 隧道穿越防火墙 | HTTP/80 |
| RTMFP | Real-Time Media Flow Protocol | UDP P2P 传输(已弃用) | UDP |
协议栈层次:
┌─────────────────────────────────────────────┐
│ 应用层 (Application) │
│ ┌─────────────────────────────────────────┐│
│ │ AMF 编码 / 命令消息 / 音视频数据 ││
│ └─────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────┐│
│ │ RTMP 消息层 (Message) ││
│ └─────────────────────────────────────────┘│
│ ┌─────────────────────────────────────────┐│
│ │ RTMP 块流层 (Chunk Stream) ││
│ └─────────────────────────────────────────┘│
├─────────────────────────────────────────────┤
│ 传输层 (Transport) │
│ ┌─────────┐ ┌─────────┐ ┌────────────────┐│
│ │ TCP │ │ TLS │ │ HTTP Tunnel ││
│ │ (RTMP) │ │ (RTMPS) │ │ (RTMPT) ││
│ └─────────┘ └─────────┘ └────────────────┘│
└─────────────────────────────────────────────┘
1.4 与 HLS/DASH 的对比
核心对比表
| 维度 | RTMP | HLS | DASH |
|---|---|---|---|
| 开发者 | Adobe | Apple | MPEG 联盟 |
| 传输方式 | TCP 长连接 | HTTP 短连接 | HTTP 短连接 |
| 分片格式 | 块(Chunk) | TS/fMP4 分片 | fMP4/WebM 分片 |
| 典型延迟 | 1-3s | 6-30s | 6-30s |
| 低延迟方案 | 原生 | LL-HLS (2-4s) | LL-DASH (2-4s) |
| 协议开销 | 低 | 高(HTTP 头部) | 高(HTTP 头部) |
| CDN 友好 | 差 | 极好 | 极好 |
| 浏览器支持 | 需 Flash/转封装 | 原生 <video> | 原生 <video> |
| 自适应码率 | 不支持 | 支持 | 支持 |
| 推流支持 | ✅ 主流 | ❌ 不用于推流 | ❌ 不用于推流 |
| 播放场景 | ✅ 但逐渐被替代 | ✅ 最广泛 | ✅ 增长中 |
| 加密/DRM | RTMPE/RTMPS | SAMPLE-AES | Widevine/PlayReady |
延迟对比图
延迟 (秒) 0 5 10 15 20 25 30
├───────┼───────┼───────┼───────┼───────┼───────┤
RTMP ██ 1-3s
│
LL-HLS ████████ 2-4s
│
LL-DASH ████████ 2-4s
│
HLS ██████████████████████████████████████████████████████ 6-30s
│
DASH ██████████████████████████████████████████████████████ 6-30s
架构差异
RTMP 推流架构:
┌────────┐ RTMP ┌────────┐ RTMP/FLV ┌────────┐
│ 编码器 │───────→│ 源站 │───────────→│ 边缘 │
└────────┘ └────────┘ └────────┘
│ 转封装
┌─────┴──────┐
│ HLS/DASH │
│ 输出给观众 │
└────────────┘
HLS 分发架构:
┌────────┐ RTMP ┌────────┐ HLS/HTTP ┌─────────┐
│ 编码器 │───────→│ 源站 │─────────→│ CDN │
└────────┘ └────────┘ └─────────┘
│ HTTP
┌─────┴──────┐
│ 观众浏览器 │
└────────────┘
1.5 RTMP vs WebRTC
除了 HLS/DASH,WebRTC 也是重要的实时传输方案:
| 维度 | RTMP | WebRTC |
|---|---|---|
| 延迟 | 1-3s | < 1s |
| 传输层 | TCP | UDP (SRTP) |
| 浏览器原生 | ❌ | ✅ |
| 大规模分发 | 通过服务器集群 | 需要 SFU/MCU |
| 推流场景 | ✅ 主流 | 需要 WHIP 协议 |
| NAT 穿越 | 不需要 | 需要 STUN/TURN |
| 适用场景 | 直播推流、录制 | 视频通话、超低延迟互动 |
1.6 适用场景
✅ 推荐使用 RTMP 的场景
1. 直播推流(最核心场景)
主播/OBS ──── RTMP ────→ SRS 服务器 ──── HLS ────→ 观众
(1935端口) (80端口)
- 所有主流编码器(OBS、XSplit、FFmpeg)都首选 RTMP 推流
- 端口 1935 在企业网络中通常未被封禁
2. 低延迟监控
- 安防监控系统内部网络传输
- 工业场景实时视频回传
3. 录制服务
- 服务器端接收 RTMP 流后录制为 FLV/MP4
- 点播内容生产
4. 流媒体中转
- 源站(Origin)到边缘(Edge)的内部中转
- CDN 回源传输
❌ 不推荐使用 RTMP 的场景
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 浏览器播放 | Flash 已退役 | HLS/DASH |
| 超大规模分发 | CDN 不原生支持 RTMP | HLS |
| P2P 传输 | TCP 不适合 | WebRTC |
| 移动端播放 | iOS 不原生支持 | HLS |
| 自适应码率 | RTMP 不支持 | HLS/DASH |
1.7 现代流媒体架构中的 RTMP
在现代直播架构中,RTMP 通常作为 第一公里(First Mile)协议:
生产端 服务端 消费端
┌─────────────┐ ┌──────────────────┐ ┌─────────────┐
│ OBS │ │ │ │ 浏览器 │
│ FFmpeg │ RTMP │ SRS/Nginx-RTMP │ HLS │ 手机 APP │
│ 摄像头 │─────────→│ │─────→│ 播放器 │
│ 手机 APP │ :1935 │ 转封装/转码 │ DASH │ 电视 │
└─────────────┘ │ 录制/截图 │ └─────────────┘
└──────────────────┘
↑ ↑
RTMP 中转 HTTP 分发
(集群) (CDN)
关键洞察:RTMP 的价值在于其 推流端的生态优势。只要编码器继续支持,RTMP 就不会消亡。实际上,随着 SRT 等新协议的出现,RTMP 推流端的地位正在被挑战,但目前仍然是最稳定、兼容性最好的选择。
1.8 协议规范参考
RTMP 规范的主要来源:
| 文档 | 来源 | 内容 |
|---|---|---|
| RTMP Specification | Adobe (2012) | 完整协议规范 |
| FLV Specification | Adobe | FLV 文件格式 |
| AMF0 Specification | Adobe | AMF0 编码格式 |
| AMF3 Specification | Adobe | AMF3 编码格式 |
| Enhanced RTMP | 社区 | 扩展 RTMP(支持 H.265 等) |
注意事项
- RTMP ≠ RTMPS:默认 RTMP 是明文传输,在公网环境下务必使用 RTMPS(TLS 加密)
- 防火墙穿越:RTMPT 可通过 HTTP 端口 80 穿越防火墙,但会增加延迟
- 版本差异:不同 RTMP 实现可能在握手阶段存在差异,遇到兼容性问题优先检查版本号
- Enhanced RTMP:社区在 2023 年后扩展了 RTMP 规范以支持 H.265/HEVC、AV1 等新编码,但并非所有服务器都支持
扩展阅读
- Adobe RTMP Specification (2012)
- SRS RTMP 文档
- RTMPdump - Open Source RTMP Client
- Enhanced RTMP Specification
下一章:02 - 握手过程 — 了解 RTMP 连接建立的第一步