嵌入式音视频开发——RTMP协议详解
嵌入式音视频开发——RTMP协议详解
1 协议概述
RTMP（Real-Time Messaging Protocol，实时消息传输协议）是由Adobe公司开发的基于TCP的实时流媒体传输协议，核心目标是实现音视频数据的低延迟（相对）实时传输。该协议最初广泛应用于直播推流、点播、视频会议等场景（如早期Twitch、国内直播平台），虽然当前WebRTC、HLS等协议逐渐替代其部分场景，但RTMP在"推流链路"（如OBS推流到服务器）中仍有大量应用。
协议特点：
- 基于TCP：默认使用端口1935，利用TCP的可靠性（重传、有序）确保音视频数据不丢失，但也因此引入一定延迟（通常100ms~1s，高于UDP协议的RTP）
- 支持内容全面：不仅支持音视频流（如H.264视频、AAC音频），还支持文本数据（如直播弹幕、控制指令）
- 分块传输：通过"Chunking（分块）"机制减少传输开销，支持实时推流（Publish）与拉流（Play）
- 安全变种：可通过加密（RTMPS/RTMPE）保障传输安全
2 RTMP协议变种
为适配不同网络环境（如防火墙、加密需求），RTMP衍生出多个变种，核心差异在于传输层封装方式：
| 协议变种 | 核心特点 | 适用场景 |
|---|---|---|
| RTMP（基础版） | 直接基于TCP传输，默认端口1935 | 无防火墙限制的内网/公网环境（如服务器间流分发） |
| RTMPT（RTMP over HTTP） | 用HTTP请求封装RTMP数据，默认端口80/443 | 需穿透防火墙（防火墙通常允许HTTP端口） |
| RTMPS（RTMP over SSL/TLS） | 在RTMP基础上添加SSL/TLS加密，默认端口443 | 对安全性要求高的场景（如金融直播、隐私内容传输） |
| RTMPE（Encrypted RTMP） | Adobe私有加密算法，无需SSL/TLS | 轻量级加密场景（已逐渐被RTMPS替代） |
| RTMPTE（RTMPT over SSL） | 结合RTMPT的HTTP封装与SSL加密 | 需穿透防火墙且需加密的场景 |
3 协议架构与分层模型
RTMP采用分层设计，从下到上依次为"传输层→协议层→消息层→应用层"，各层职责明确：
3.1 分层架构
| 层级 | 核心职责 | 关键机制/组件 |
|---|---|---|
| 传输层（Transport Layer） | 基于TCP协议传输Chunk，利用TCP的可靠性确保Chunk有序、不丢失 | TCP连接（需先完成TCP三次握手），端口约定：默认1935（RTMP）、80/443（变种协议） |
| 协议层（Protocol Layer） | 将"大消息"拆分为"小分块（Chunk）"，适配TCP MTU（避免IP分片），减少头部开销 | Chunking机制：按配置的Chunk Size（默认128字节）拆分Message，相同流的Chunk可复用头部；Chunk结构：Chunk Header（分块格式、ID、时间戳增量）+ Chunk Payload（拆分后的消息片段） |
| 消息层（Message Layer） | 将应用层数据封装为"RTMP消息（Message）"，定义数据类型与元信息 | 消息类型：命令消息（控制逻辑）、数据消息（元数据/文本）、音视频消息；消息结构：Message Header（类型、长度、时间戳、流ID）+ Payload（实际数据） |
| 应用层（Application Layer） | 处理业务逻辑，定义"流如何被使用" | 业务场景：推流（Publish）、拉流（Play）、点播；核心概念：Stream（音视频流载体，唯一Stream ID标识）、NetConnection（客户端与服务器的连接）、NetStream（具体的流传输通道） |
3.2 关键概念：Chunking（分块）机制
Chunking是RTMP的核心优化点，解决了"大消息传输效率低"的问题：
- 问题背景：TCP传输有MTU限制（通常1500字节），若直接传输大尺寸Message（如1帧H.264视频可能几KB），会触发IP分片，增加丢包风险；且每个Message的头部（如Stream ID、时间戳）重复，浪费带宽
- 解决方案：
- 拆分：将1个Message按Chunk Size（可通过Set Chunk Size命令调整，默认128字节）拆分为多个Chunk
- 头部复用：同一Message的后续Chunk，仅需携带"增量信息"（如时间戳增量Timestamp Delta），无需重复携带完整头部（如Stream ID），大幅减少头部开销
示例：1个1024字节的Video Message，按128字节Chunk Size拆分，会生成8个Chunk：
- 第1个Chunk：携带完整头部（Chunk Format 0，包含Stream ID、完整时间戳、Payload Length）
- 第2~8个Chunk：携带简化头部（Chunk Format 3，仅包含Chunk ID，其他信息复用第1个Chunk）
4 RTMP核心组件与消息类型
4.1 核心组件
RTMP通过以下组件定义"客户端与服务器的交互关系"：
- Client：发起连接的一端，可分为"推流端"（如OBS、手机直播APP）和"拉流端"（如早期Flash Player、直播客户端）
- Server：接收连接并处理流的一端，如Adobe Media Server（AMS）、NGINX-RTMP（开源常用）、SRS（Simple RTMP Server）
- NetConnection：客户端与服务器的"逻辑连接"，负责传递控制命令（如connect、close），一个NetConnection可对应多个NetStream
- NetStream：具体的"流传输通道"，每个NetStream对应一个唯一的Stream ID，负责传输音视频数据或文本数据（如弹幕）
- Stream：音视频流的抽象，包含"元数据"（如视频分辨率、音频采样率）和"媒体帧"（音视频数据）
4.2 关键消息类型
RTMP Message按功能分为4大类，不同类型通过Message Type ID区分：
| 消息类别 | 常见Type ID | 核心作用 | 示例 |
|---|---|---|---|
| 命令消息（Command Message） | 20（AMF0）、17（AMF3） | 控制会话逻辑，如建立连接、创建流、推流/拉流 | connect：客户端请求与服务器建立NetConnection；createStream：创建NetStream（申请Stream ID）；publish：推流端将流发布到服务器（如OBS推流）；play：拉流端请求从服务器拉取流（如客户端播放） |
| 数据消息（Data Message） | 18（AMF0）、15（AMF3） | 传递元数据或文本数据 | onMetaData：推流端发送流的元数据（如视频编码H.264、帧率25、音频采样率44.1kHz）；文本消息：直播弹幕、实时通知（如"主播上线"） |
| 音视频消息（Media Message） | 8（Audio）、9（Video） | 传输编码后的音视频帧 | Audio Message：封装AAC/MP3等音频帧（需携带音频格式信息）；Video Message：封装H.264/H.265等视频帧（需携带视频关键帧/非关键帧标识） |
| 控制消息（Control Message） | 1（Set Chunk Size）、2（Abort）、3（Acknowledgement） | 管理协议层传输，确保Chunk正常传输 | Set Chunk Size：调整Chunk的最大尺寸（默认128字节，可改为4096字节提升效率）；Acknowledgement：确认收到的字节数（配合TCP确认，确保数据未丢失） |
5 RTMP工作流程（以"推流+拉流"为例）
RTMP的完整流程可分为"连接建立→流创建→数据传输→连接断开"四步，以下以"OBS推流到NGINX-RTMP服务器，客户端拉流播放"为例拆解：
5.1 TCP三次握手（底层连接）
RTMP基于TCP，因此首先需完成TCP三次握手：
- Client（OBS/拉流端）向Server（NGINX-RTMP）发送SYN报文
- Server返回SYN+ACK报文
- Client返回ACK报文，TCP连接建立（默认端口1935）
5.2 RTMP握手（协议层同步）
TCP连接建立后，需完成RTMP三步握手（Handshake），确保客户端与服务器版本兼容、时间同步。要建立一个有效的 RTMP Connection 链接，首先要进行 RTMP 握手：客户端要向服务器发送 C0,C1,C2（按顺序）三个 chunk，服务器向客户端发送 S0,S1,S2（按顺序）三个 chunk；然后才能进行有效的信息传输。
RTMP 协议本身并没有规定这 6 个 Message 的具体传输顺序，但 RTMP 协议的实现者需要保证这几点：
- 客户端要等收到 S1 之后才能发送 C2
- 客户端要等收到 S2 之后才能发送其他信息（控制信息和真实音视频等数据）
- 服务端要等到收到 C0 之后发送 S1
- 服务端必须等到收到 C1 之后才能发送 S2
- 服务端必须等到收到 C2 之后才能发送其他信息（控制信息和真实音视频等数据）
理论上来讲只要满足以上条件，如何安排 6 个 Message 的顺序都是可以的，但实际实现中为了在保证握手的身份验证功能的基础上尽量减少通信的次数，一般的发送顺序是这样的：
- Client发送C0+C1：
- C0（1字节）：RTMP版本号（如版本3）
- C1（1536字节）：客户端时间戳（4字节）、随机数（1528字节，用于标识会话）
- Server返回S0+S1+S2：
- S0（1字节）：服务器支持的RTMP版本（需与C0一致，否则握手失败）
- S1（1536字节）：服务器时间戳、随机数
- S2（1536字节）：对C1的响应（包含C1的时间戳和随机数，确认客户端数据已收到）
- Client返回C2：
- C2（1536字节）：对S1的响应（包含S1的时间戳和随机数，确认服务器数据已收到）
- 握手完成后，双方进入"连接建立"阶段
5.3 建立NetConnection（逻辑连接）
- Client发送connect命令消息（Command Message），携带"应用名"（如服务器配置的直播应用名live）
- Server验证通过后，返回_result响应，确认NetConnection建立
- （可选）Server发送onBWDone消息，告知Client"带宽探测完成"，可开始传输数据
5.4 创建NetStream（流通道）
- Client（推流端/拉流端）发送createStream命令消息，请求创建流
- Server返回_result响应，分配唯一的Stream ID（如1），NetStream创建完成
5.5 推流（Publish）与拉流（Play）
推流端（OBS）Publish流程：
- 推流端发送publish命令消息，指定"流名"（如stream1），告知服务器"开始推送流"
- 服务器返回_result响应，确认接收推流
- 推流端发送onMetaData数据消息，传递流的元信息（如视频分辨率1920x1080、音频采样率44.1kHz）
- 推流端将编码后的音视频帧封装为"Audio/Video Message"，再拆分为Chunk，通过TCP传输到服务器
- 服务器接收Chunk后，重组为Message，再转发给所有请求拉取该流（stream1）的拉流端
拉流端（客户端）Play流程：
- 拉流端发送play命令消息，指定"流名"（如stream1），请求拉取流
- 服务器返回_result响应，确认开始推送流
- 服务器将推流端的onMetaData消息转发给拉流端，拉流端根据元信息初始化解码器（如H.264解码器）
- 服务器将推流端的音视频Chunk转发给拉流端
- 拉流端接收Chunk，重组为Message，提取音视频帧，根据时间戳同步播放（避免音画不同步）
5.6 连接断开（Close）
- Client发送closeStream命令消息，关闭NetStream
- Client发送deleteStream命令消息，释放Stream ID
- Client发送close命令消息，关闭NetConnection
- TCP四次挥手，断开底层连接
6. RTMP的数据传输
RTMP的数据传输建立在握手成功建立的连接之上，其核心思想是：将大的消息（Message）分割成小的块（Chunk）进行传输，并通过一系列控制消息来管理传输过程。
6.1. 数据传输的基础单元：消息（Message）
在应用层，数据是以消息（Message） 为逻辑单位组织的。一个Message包含一个完整的指令或一帧媒体数据（如一个视频帧或几个音频帧）。
一个RTMP Message由两部分组成：
- 消息头（Header）： 包含了描述该消息的元信息。Message Header是由四部分组成，Message Type Id(消息类型ID)、Payload Length(消息长度)、TimeStamp(标识符时间戳)，Stream Id(消息流ID)。
- Message Type ID（1字节）： 标识消息的类型（详见下文）。
在Messgae中，不同类型的Messgae含有不同的Message Type ID。
Message Type ID为1-6，则代表此消息协议是控制协议。
Message Type ID为8，则代表此消息传输音频数据。
Message Type ID为9，则代表此消息传输视频数据。
Message Type ID为15-20，则用于发送AMF编码指令(AMF指的是Flash和服务端常见的编码方式)，比如播放、暂停、Client和Server端进行交互等。
- Payload Length（3字节）： 消息负载（Payload）的字节数。
- Timestamp（4字节）： 消息的时间戳，用于音视频同步。
- Message Stream ID（4字节）： 标识消息所属的流（Stream），同一个音视频流的所有消息具有相同的Stream ID。
- Message Type ID（1字节）： 标识消息的类型（详见下文）。
- 消息体（Payload）： 实际的数据内容，例如H.264视频帧、AAC音频帧或AMF编码的命令数据。
6.2. 数据传输的核心机制：分块（Chunking）
直接传输整个Message可能会遇到问题：一个大尺寸的Video Message可能会在TCP层被拆分成多个IP包，如果其中一个包丢失，整个Message都需要重传，会增加延迟。同时，每个Message都携带完整的Header会产生较大的开销。
RTMP的解决方案是分块（Chunking）：
- 发送端会将一个大的Message分割成多个小的Chunk。
- 接收端收到这些Chunk后，会根据其中的标识符将它们重新组装成完整的Message。
- 默认的Chunk Size是128字节，但可以通过
Set Chunk Size控制消息动态调整，以适应不同的网络环境和性能需求（例如，设置为4096或更大可以提高传输效率）。
Chunk的格式
每个Chunk由Chunk Header和Chunk Data组成。
Chunk Header由三部分组成：Chunk Basic Header(块基本头)、Chunk Message Header(块消息头)、Extended TimeStamp(扩展时间戳)，具体的如下图：
1. 基本头（Basic Header，1-3字节）
- fmt（2位）： 决定了后面消息头（Message Header） 的格式。有4种类型（0, 1, 2, 3），用于压缩和复用信息，减少冗余数据传输。
- Chunk Stream ID（CSID，变长）： 标识Chunk所属的块流。CSID 2保留给协议控制消息。CSID 3-65599可用于用户数据。通过变长编码（1-3字节）来节省空间。
2. 消息头（Message Header，0, 3, 7, 或11字节）
其长度和内容由fmt决定：
| fmt 类型 | 消息头长度 | 含义与用途 | 包含字段 |
|---|---|---|---|
| 0 | 11字节 | 完整头。用于一个Chunk Stream的起始Chunk，或时间戳倒退时 | Timestamp, Message Length, Message type id, Message stream id |
| 1 | 7字节 | 省去Message Stream id。与上一个Chunk的Message Stream ID相同 | Timestamp, Message Length, Message type id |
| 2 | 3字节 | 省去Message Stream id和`Message Length。与上一个Chunk的Message Stream id、Message Length和Message Type都相同 | Timestamp |
| 3 | 0字节 | 无消息头。与上一个Chunk的所有信息完全相同。用于一个Message被分成的后续所有Chunk | (无) |
- Timestamp / timestamp delta： 时间戳或时间戳增量，占用三个字节，它代表的是解析时候的实时时间戳。如果值 >= 0xFFFFFF，则该字段置为0xFFFFFF，并在Chunk Header后附加一个扩展时间戳（Extended Timestamp, 4字节） 来存储真实值。
- Message Length： 原始Message的总长度，占用3个字节，它代表的是实际发送的数据信息，比方说：音频数据长度、视频数据长度。要注意的是，Message Length是整个Chunk的总长度，并不是Chunk Data的长度
- Message type id： 消息类型id，占用1个字节，它代表的是实际发送数据的类型id，比方说: 8代表的是音频数据、9代表的是视频数据。
- Message Stream id： 消息流id，占用4个字节，它代表的是chunk所在的流id。
3. 扩展时间戳（Extended Timestamp, 0或4字节）
当基本时间戳字段无法容纳时使用。这个值默认为0，当启动这个值的时候，timestamp和timestamp delta全部设置为1。
4. 块数据（Chunk Data）
实际传输的数据片段，长度不超过当前设置的Chunk Size。
分块机制的优势
- 低延迟： 小块的Chunk可以更快地发送出去，减少了在大消息后排队的小消息（如音频帧或控制消息）的等待时间，有助于实现低延迟。
- 减少开销： 通过使用fmt 1, 2, 3类型的Chunk Header，可以极大地复用之前Chunk的头部信息，减少了传输冗余数据带来的带宽开销。
- 多路复用（Multiplexing）： 不同Chunk Stream（CSID不同）的Chunk可以在同一个TCP连接上交错传输。这意味着音视频流和控制消息可以共享一个连接而不会相互阻塞。
6.3. 协议控制消息（Protocol Control Messages）
这些是RTMP用于管理传输过程的特殊消息，它们的Message Stream ID总是0，CSID总是2。
| 消息类型 | Type ID | 功能描述 |
|---|---|---|
| Set Chunk Size | 1 | 动态调整Chunk的最大尺寸。影响此后发送的所有Chunk。 |
| Abort Message | 2 | 中断一个Chunk Stream的消息组装。用于通知对端丢弃正在组装的某个Message（如 seek 操作时）。 |
| Acknowledgement | 3 | 确认。当接收端收到窗口大小（Window Size）字节的数据后，会发送此ACK告知发送端。 |
| Window Acknowledgement Size | 5 | 设置窗口大小。发送端告知接收端：“在收到下一个ACK之前，你最多可以发送这么多字节”。用于流量控制。 |
| Set Peer Bandwidth | 6 | 设置对端带宽。限制对端的发送带宽。包含一个Limit Type（0: Hard, 1: Soft, 2: Dynamic）来指定限制强度。 |
6.4. 音视频消息的封装
媒体数据通过特定的Message Type进行封装：
- 音频消息（Audio Message, Type ID=8）： 负载通常由一个1字节的音频标签（Audio Tag） 和音频数据组成。音频标签指明了编解码器（如AAC）、采样率、位深、声道数等信息。
- 视频消息（Video Message, Type ID=9）： 负载通常由一个1字节的视频标签（Video Tag） 和视频数据组成。视频标签指明了编解码器（如H.264）、帧类型（关键帧/非关键帧）等信息。
- 数据消息（Data Message, Type ID=15/18/19）： 用于传输元数据（如
onMetaData，包含视频宽度、高度、帧率等）或文本信息（如弹幕）。通常使用AMF（Action Message Format）编码。
6.5. 数据传输流程（推流视角）
假设我们已经完成了握手、建立连接（connect）和创建流（createStream），并发布了流（publish）：
- 发送元数据： 推流端首先发送一个
onMetaData数据消息，描述流的属性（编码、分辨率、帧率等）。 - 媒体数据循环：
- 编码器产生一帧视频数据（例如，一个H.264 NALU）。
- 将该帧数据封装成一个Video Message（Type=9）。计算时间戳，设置Message Length等。
- 分块： RTMP协议栈根据当前Chunk Size，将这个大Message切割成多个Chunk。
- 第一个Chunk使用fmt=0，携带完整的Message Header信息。
- 后续的Chunk使用fmt=3，只包含最基本的CSID和fmt信息，极大减少了头部开销。
- 这些Chunk被放入TCP发送缓冲区进行传输。
- 交织发送： 音频消息（如果同时有音频）也会被类似地处理和分块。音视频Chunk会依据时间戳交错在同一个TCP连接上发送，以确保接收端能够及时解码和渲染，实现音画同步。
- 流量控制： 在整个过程中，服务器和客户端会通过
Window Acknowledgement Size和Set Peer Bandwidth等控制消息来协商和调整发送速率，防止接收端缓冲区溢出或网络拥塞。 - 接收端处理：
- 拉流端从TCP流中读取Chunk。
- 根据CSID和fmt类型，将Chunk重组为原始的Audio/Video Message。
- 将Message payload（视频帧/音频帧）送入解码器。
- 根据时间戳进行同步播放。
6.6. RTMP数据传输的特点
| 特性 | 描述 | 优点 |
|---|---|---|
| 分块（Chunking） | 将大消息切割成小Chunk传输 | 降低延迟，减少头部开销，避免大消息阻塞 |
| 多路复用（Multiplexing） | 音视频和控制消息在同一连接交错传输 | 高效利用连接，简化网络架构 |
| 基于TCP | 在TCP协议之上工作 | 传输可靠，数据有序，不丢失 |
| 协议控制消息 | 专门用于管理连接、带宽和流量 | 保证传输的稳定性和公平性 |
希望这份详细的讲解能帮助你更好地理解RTMP的数据传输机制。
7 RTMP的优缺点与应用场景
7.1 核心优点
- 传输可靠：基于TCP，确保音视频数据不丢失、有序，适合对"完整性"要求高于"极致低延迟"的场景（如点播、普通直播）
- 效率较高：Chunking机制减少头部开销，比直接传输大Message更节省带宽
- 功能全面：支持推流、拉流、点播、文本数据传输（弹幕），且可通过变种协议适配防火墙、加密需求
- 生态成熟：开源服务器（NGINX-RTMP、SRS）、推流工具（OBS）支持完善，部署成本低
7.2 主要缺点
- 延迟较高：TCP的重传机制会导致延迟（通常100ms~1s），无法满足"实时互动"场景（如在线教育、游戏直播）
- 客户端依赖：早期依赖Flash Player，而Flash已被主流浏览器（Chrome、Safari）淘汰，当前需通过专用客户端（如直播APP）或RTMP转HLS/WebRTC播放
- 不支持多播：仅支持"点对点"传输，服务器需为每个拉流端单独转发流，并发量高时服务器压力大（不如HLS/DASH的多播效率）
- 协议较复杂：Chunking、握手、消息类型的设计较繁琐，实现难度高于RTP/RTCP
7.3 典型应用场景
- 直播推流链路：当前主流直播平台仍用RTMP作为"推流协议"（如OBS→CDN节点），CDN再将RTMP转为HLS/WebRTC供客户端播放
- 传统点播服务：早期视频网站（如YouTube早期）用RTMP传输点播视频，确保播放流畅
- 内部直播系统：企业/学校的内网直播（如会议直播、培训直播），对延迟要求不高，且可部署专用客户端