1. RTMP协议概述

RTMP（Real-Time Messaging Protocol）是Adobe设计的基于TCP的实时流媒体传输协议，专为低延迟场景（如直播、视频通话）优化。消息结构由基本头（Basic Header）、消息头（Message Header）、扩展时间戳（Extended Timestamp，可选）和消息体（Message Payload）组成。
核心特性：

  • 默认端口1935，支持加密变种RTMPS（端口443）
  • 基于分块传输（Chunking）机制，支持消息拆解与重组
  • 使用AMF（Action Message Format）编码结构化数据
  • 支持动态带宽适应（通过Window Acknowledge Size控制）

2. RTMP消息结构分层

RTMP协议的核心是消息分块传输机制，层级关系如下：

Message (逻辑完整数据) → 拆分为多个 Chunks (传输单元)

3. Chunk（块）结构详解

每个Chunk由Header + Payload组成，Header格式根据类型（fmt）不同分为4种：
基本头（Basic Header）
本头用于标识消息的基本属性，长度为 1 - 3 字节，它的第一个字节包含两个重要信息
格式类型（FMT）：占用前 2 位，它决定了后续消息头的长度和格式。具体对应关系如下：

fmt描述适用场景
0完整Header（12字节)，表示后续使用完整的 11 字节消息头新Chunk Stream ID的首个块
1相对时间戳（8字节）后续消息头长度为 7 字节同一Stream ID的后续块
2仅消息长度（4字节）后续消息头长度是 3 字节时间戳与Stream ID不变时
3无Header（0字节）意味着没有额外的消息头扩展，仅使用基本头连续分片（如视频关键帧）

Chunk Header字段

| fmt (2 bits) | Chunk Stream ID (变长) | Timestamp (3/4字节) | 
| Message Length (3字节) | Message Type ID (1字节) | 
| Message Stream ID (4字节, 小端) |

流 ID（Chunk Stream ID）：剩下的 6 位（如果基本头是 1 字节）或者更多位（基本头为 2 或 3 字节时）用于表示流 ID。流 ID 是一个重要的标识，它唯一确定了消息所属的流。

  • 当流 ID 的值在 2 - 63 之间时，基本头只需 1 字节；
  • 当流 ID 在 64 - 319 之间，基本头为 2 字节；
  • 若流 ID 大于 319，则需要 3 字节来表示。
 +-----------------+
| FMT (2 bits) | Stream ID (6 bits) |  1 - byte basic header (Stream ID: 2 - 63)
+-----------------+
| FMT (2 bits) | Stream ID (14 bits) |  2 - byte basic header (Stream ID: 64 - 319)
+-----------------+
| FMT (2 bits) | Stream ID (22 bits) |  3 - byte basic header (Stream ID > 319)
+-----------------+

4. Message（消息）结构，消息头（Message Header）

一个完整的Message由多个Chunk重组而成，结构如下：

+----------------+-------------------+------------------+
| Timestamp      | Message Length    | Type ID          |
+----------------+-------------------+------------------+
| Payload (数据)                                     ... |
+-------------------------------------------------------+

  1. 时间戳（Timestamp）

    • 支持扩展为4字节
    • 长度：在不同格式下有所差异。当 FMT 为 0、1、2 时，时间戳占用 3 字节。不过，如果时间戳的值超过了 0xFFFFFF（即 16777215），则这 3 字节会被设置为 0xFFFFFF，同时需要额外的 4 字节扩展时间戳字段来表示准确的时间。
    • 作用：时间戳用于标记消息的相对时间，对于音视频数据的同步播放至关重要。它可以帮助播放器确定每个音视频帧的播放顺序和时间点。

  2. 消息长度（Message Length）

    • 长度：固定为 3 字节。
    • 作用：指示消息体的字节数，接收方可以根据这个长度信息准确地读取消息体的数据。

  3. 消息类型 ID（Message Type ID）

    • 长度：1 字节。
    • 用：唯一标识一个流，与基本头中的流 ID 相互配合，确保消息能够正确地被分发到对应的流中。

  4. 扩展时间戳（Extended Timestamp）

    • 长度：4 字节。
    • 使用条件：当消息头中的 3 字节时间戳字段被设置为 0xFFFFFF 时，需要使用扩展时间戳字段来存储准确的时间戳信息。这个字段可以表示更大范围的时间值，以满足长时间或高精度的时间标记需求。

  5. 消息体（Payload）：AMF编码的命令或二进制数据（如H.264/AAC）

    • 长度：由消息头中的消息长度字段指定。
    • 内容：包含具体的数据内容，根据消息类型的不同而不同：
      • 协议控制消息：用于管理 RTMP 连接和流，如设置消息块大小、确认接收字节数等。例如，“Set Chunk Size” 消息体中会包含新的消息块大小值。
      • 用户控制消息：用于通知对等端一些事件，如流开始、流结束、流干缓冲区等。消息体中会包含事件类型和相关的参数。
      • 命令消息：如 “Connect”、“Play”、“Publish” 等命令，消息体中包含命令名称和相关的参数。例如，“Connect” 命令的消息体可能包含应用名称、连接参数等信息。
      • 音频消息：包含编码后的音频数据，常见的音频编码格式有 AAC、MP3 等。消息体中的数据就是音频帧的编码内容。
      • 视频消息：包含编码后的视频数据，常用的视频编码格式有 H.264、H.265 等。消息体中的数据是视频帧的编码数据，可能包含关键帧（I 帧）、预测帧（P 帧）和双向预测帧（B 帧）等不同类型的帧数据。
      • 数据消息：用于传输元数据，如视频的分辨率、帧率，音频的采样率、声道数等信息。消息体中包含这些元数据的键值对。

  6. 消息块（Chunk）
    为了提高传输效率，RTMP 协议将消息分割成多个消息块进行传输。每个消息块都有自己的基本头，而消息头和扩展时间戳只有在消息的第一个消息块中出现。后续的消息块只包含基本头和部分消息体内容，直到整个消息传输完成。消息块的大小可以通过 “Set Chunk Size” 协议控制消息进行动态调整，以适应不同的网络状况。

Message 1:
+---+-----------------+-----------------+-----------------+-----------------+
| BH | MH | ET (if needed) | Payload Part 1 |
+---+-----------------+-----------------+-----------------+
| BH | Payload Part 2 |
+---+-----------------+
| BH | Payload Part 3 |
+---+-----------------+

Message 2:
+---+-----------------+-----------------+-----------------+-----------------+
| BH | MH | ET (if needed) | Payload Part 1 |
+---+-----------------+-----------------+-----------------+
| BH | Payload Part 2 |
+---+-----------------+

常见Message Type ID

类型ID描述示例
1Set Chunk Size控制块大小（默认128字节）
4User Control Message流控制事件（如Stream Begin）
8Audio DataAAC音频帧
9Video DataH.264视频帧
18AMF0 Commandconnect(), play(), publish()

命令集
1. NetConnection 命令

  • Connect：用于客户端与服务器建立连接，携带连接所需的参数，如应用名称、认证信息等。
  • Disconnect：用于断开客户端与服务器的连接。
  • Call：用于在客户端和服务器之间调用远程方法，实现功能交互，如获取服务器的状态信息、执行服务器端的特定操作等。

2. NetStream 命令

  • Play：客户端发送该命令请求播放指定的媒体流，可指定流名称、开始时间、播放时长等参数。
  • Publish：客户端使用该命令将本地的媒体流发布到服务器，可指定发布模式（如实时发布、录制发布等）。
  • Seek：用于客户端请求跳转到媒体流中的指定时间点进行播放，实现快进、快退等功能。
  • Pause：暂停媒体流的播放。

5. 协议控制消息（关键操作）

5.1 Set Chunk Size (Type ID=1)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (fmt=0)    | Chunk Stream ID=2 | Timestamp=0              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length=4            | Type ID=1                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Size (4字节, 如0x00008000=32768字节)                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • 作用：动态调整块大小（默认128字节，最大65535字节）

5.2 Window Acknowledge Size (Type ID=5)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledge Window Size (4字节) | Limit Type (可选)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  • 作用：流量控制（客户端/服务端声明可接收的未确认数据量）

6. RTMP握手协议（3次握手）

握手过程建立TCP连接后立即执行：

Client               Server
  | ---- C0+C1 ------> | 
  | <---- S0+S1+S2 --- | 
  | ---- C2 ---------> |
  • C0/S0：1字节，版本号（如0x03）
  • C1/S1：1536字节，包含时间戳和随机数据
  • C2/S2：1536字节，回显对端的随机数据

7. 消息分片示例

假设发送一条300字节的音频消息（Chunk Size=128字节）：

Message: [300 bytes]
Chunk 1: Header(fmt=0) + 128 bytes
Chunk 2: Header(fmt=3) + 128 bytes
Chunk 3: Header(fmt=3) + 44 bytes

8. AMF命令示例（connect()）

+---------------------+-----------------------+
| "connect"           | Transaction ID=1      |
+---------------------+-----------------------+
| { "app": "live",    | "flashVer": "FMLE/3.0"|
|   "tcUrl": "..." }  |                       |
+---------------------+-----------------------+

编码：AMF0格式，包含命令名、事务ID、键值对参数

9. 与其他协议的对比

1. 与 HTTP 的对比

  • 传输特性：HTTP 是无状态的请求 - 响应协议，主要用于静态资源的传输，如网页、图片等。而 RTMP 是基于 TCP 的实时消息传输协议，强调实时性和双向通信，适用于音视频的实时传输。
  • 延迟：HTTP 在每次请求时需要建立新的连接，会引入一定的延迟，不适合实时性要求高的应用。RTMP 通过建立持久的 TCP 连接，减少了连接建立的开销，延迟较低。
  • 应用场景：HTTP 广泛应用于 Web 浏览、文件下载等场景，RTMP 主要用于网络直播、视频会议等实时音视频应用。

2. 与 HLS 的对比

  • 协议基础：HLS（HTTP Live Streaming）基于 HTTP 协议，将音视频流分割成多个小的 TS（MPEG - 2 Transport Stream）文件进行传输。RTMP 基于 TCP 协议，直接传输音视频数据。
  • 延迟：HLS 的延迟相对较高，因为需要将音视频数据分割、封装成文件，并且客户端需要等待一定数量的文件下载后才能开始播放。RTMP 的延迟较低，能够实现更实时的音视频传输。
  • 兼容性：HLS 具有良好的跨平台兼容性，尤其在移动设备上得到广泛支持。RTMP 需要特定的播放器或插件支持，在一些浏览器中可能存在兼容性问题。

应用现状
虽然随着技术的发展，如 HTML5 视频标准的普及和 WebRTC 技术的兴起，RTMP 的应用在某些场景下受到了一定的挑战，但它仍然在网络直播、视频会议等领域广泛使用。许多直播平台的推流端仍然采用 RTMP 协议将音视频数据推送到服务器，服务器在处理后可以将数据转换为其他协议（如 HLS）进行分发，以满足不同客户端的需求。

10. 总结

  • RTMP优势：低延迟、支持动态交互（暂停、跳转）
  • 缺陷：基于TCP可能受拥塞控制影响，需结合CDN优化
  • 替代协议：WebRTC（更低延迟）、HLS（适应性更强）

附：rtmp消息结构

请添加图片描述
请添加图片描述
请添加图片描述
请添加图片描述
请添加图片描述
请添加图片描述
请添加图片描述

# 网络 # 网络协议
Logo
乐奇 Rokid 开放社区

更多推荐

cover

高德开放平台开发者大会圆满收官，空间智能连接 AI 与真实世界

avatar 乐奇 Rokid 开放社区

极刻觅镜 | AI眼镜日报｜XREAL AURA公布售价与上市计划

XREAL公布AURA售价与上市计划，起售价1279美元；挪威拟暂时禁止在特定公共场所使用人工智能眼镜；Hans Anders暂停销售Ray-Ban Meta；Cellid与Megane Top合作推进AR眼镜商业化；比特幻境完成天使轮融资；Sesame官宣2027年推出日本制造智能眼镜；苏宁易购国庆期间AI眼镜等数码产品销量上涨。

avatar 乐奇 Rokid 开放社区

破局工业运维：AR智能眼镜辅助巡检系统的进化之路与价值重构

AR巡检系统可联动AI热成像、温度传感技术，实时监测设备过热、线路老化、油气泄漏等隐性隐患，提前预判风险，规避火灾、爆炸、停电等安全事故，保障能源生产、电力输送大动脉的稳定运行，筑牢高危行业安全生产底线。立足当下工业智能化发展趋势，AR智能眼镜巡检系统仍在持续迭代升级，不再局限于可视化巡检、远程协同基础功能，正依托AI大模型、空间计算、边缘计算、数字孪生等前沿技术，向自主化、全域化、安全化的高阶智

avatar 乐奇 Rokid 开放社区