嵌入式音视频开发——RTMP协议详解

RTMP（Real-Time Messaging Protocol，实时消息传输协议）是由Adobe公司开发的基于的实时流媒体传输协议，核心目标是实现音视频数据的低延迟（相对）实时传输。该协议最初广泛应用于直播推流、点播、视频会议等场景（如早期Twitch、国内直播平台），虽然当前WebRTC、HLS等协议逐渐替代其部分场景，但RTMP在"推流链路"（如OBS推流到服务器）中仍有大量应用。

叶子卍

1070人浏览 · 2025-09-15 14:18:50

叶子卍 · 2025-09-15 14:18:50 发布

嵌入式音视频开发——RTMP协议详解

1 协议概述

1.1 协议定义

RTMP（Real-Time Messaging Protocol，实时消息传输协议）是由Adobe公司开发的基于TCP的实时流媒体传输协议，核心目标是实现音视频数据的低延迟（相对）实时传输。该协议最初广泛应用于直播推流、点播、视频会议等场景（如早期Twitch、国内直播平台），虽然当前WebRTC、HLS等协议逐渐替代其部分场景，但RTMP在"推流链路"（如OBS推流到服务器）中仍有大量应用。

1.2 核心应用场景

直播推流/拉流：主播端（推流端）将音视频数据通过RTMP推送到流媒体服务器，观众端（拉流端）从服务器拉取RTMP流播放；
实时互动：如在线教育、视频会议的低延迟音视频交互；
流媒体分发：作为CDN分发环节的核心协议之一。

1.3 核心特点

基于TCP：依赖TCP的可靠传输特性，保证数据有序、无丢失；
二进制协议：相较于文本协议（如HTTP），传输效率更高；
分块传输：将大消息拆分为小数据块（Chunk），降低网络传输开销；
多路复用：单个TCP连接可承载多个流（音频、视频、控制消息等）；
低延迟：通过优化的分块和消息机制，实现毫秒级传输延迟（理想场景下）。

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）

3.2.1 Chunk结构

每个Chunk由三部分组成：

字段	长度（字节）	说明
Basic Header	1/2/3	包含Chunk Stream ID（CSID，标识Chunk所属流）、Chunk类型（决定Message Header长度）
Message Header	0/3/7/11	包含消息的时间戳、长度、类型ID、Message Stream ID（MSID，标识消息所属流）
Extended Timestamp	0/4	若时间戳超过0xFFFFFF（24位上限），补充4字节扩展时间戳
Chunk Data	可变	消息的分片数据（默认128字节）

3.2.2 Chunk复用逻辑

单个TCP连接中，不同的CSID对应不同的Chunk流，可同时传输音频（CSID=4）、视频（CSID=5）、控制消息（CSID=2）等，块层负责将这些Chunk有序发送，接收端根据CSID重组为完整消息。

3.3 消息层（Message Layer）

RTMP的业务逻辑层，所有音视频数据、控制指令都以“消息”为单位封装，核心消息类型如下：

消息类型ID	消息类型	用途
0	Set Chunk Size	协商Chunk的最大尺寸（默认128字节，可调整为更大值如4096，提升传输效率）
1	Abort Message	终止某个Chunk流的传输
2	Acknowledgement	确认接收的数据字节数（流量控制）
3	Window Acknowledgement Size	告知对方自己的流量控制窗口大小（接收缓冲区大小）
8	Audio Message	音频数据（封装AAC/MP3等编码数据）
9	Video Message	视频数据（封装H.264/FLV等编码数据）
15	AMF0 Command	基于AMF0编码的控制指令（如connect/publish/play）
17	AMF0 Data	自定义数据（如直播弹幕、元数据）

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协议，默认使用1935端口（若端口被占用，可协商其他端口）。TCP的三次握手保证连接可靠性，为RTMP的有序数据传输提供基础；同时RTMP在应用层做了额外的流量控制和重传机制，补充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的时间戳和随机数，确认服务器数据已收到）
- 握手完成后，双方进入"连接建立"阶段

握手流程图（Mermaid语法）：

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）

连接与发布流（Publish）流程

发布流是推流端（如主播端）将音视频数据推送到RTMP服务器的核心流程：

步骤1：建立TCP连接 + 完成RTMP握手（见2.2节）；

步骤2：客户端发送connect命令（AMF0 Command）

携带客户端信息（如版本、操作系统、应用名称），请求连接服务器的指定应用实例；
服务器响应_connected，返回服务器信息（如流ID、带宽限制）。

步骤3：客户端创建流（createStream）

请求服务器分配一个Message Stream ID（MSID），用于后续音视频流传输；
服务器响应_streamCreated，返回分配的MSID。

步骤4：客户端发布流（publish）

指定流名称（如live/stream1）、发布类型（live/record/append）；
服务器响应_publishStart，确认开始接收流数据。

步骤5：客户端持续发送音视频消息（Audio/Video Message）

将编码后的音视频数据拆分为Chunk，通过TCP连接发送到服务器；
服务器定期发送Acknowledgement，确认接收数据。

发布流流程图（Mermaid语法）：

播放流（Play）流程

播放流是拉流端（如观众端）从RTMP服务器获取音视频流的核心流程：

步骤1：建立TCP连接 + 完成RTMP握手；

步骤2：客户端发送connect命令，与服务器建立连接；

步骤3：客户端创建流（createStream），获取MSID；

步骤4：客户端发送play命令

指定要播放的流名称（与发布端的流名称一致）；
服务器响应_playStart，确认开始推送流数据。

步骤5：服务器持续推送音视频消息

将接收的推流端数据拆分为Chunk，推送到播放端；
客户端定期发送Acknowledgement，确认接收数据。

播放流流程图（Mermaid语法）：

5.6 断连与重连

主动断连：客户端/服务器发送closeStream + deleteStream命令，随后关闭TCP连接；
异常重连：若TCP连接断开，客户端重新发起TCP三次握手 + RTMP握手，重新执行connect/createStream/publish/play流程，服务器基于流名称恢复流传输（需服务器支持流缓存/续传）。

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。

消息体（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