RTMP（Real-Time Messaging Protocol）

RTMP（Real-Time Messaging Protocol）是一种用于实时音视频和数据传输的协议，常见于直播和流媒体应用。

一 RTSP 协商消息

一、消息类型（Message Types）

RTMP消息分为多种类型，通过Message Type ID标识，主要包括：

1. 控制消息（Control Messages，Type ID 1-7）：
   • Set Chunk Size (ID=1)：设置分块大小。
   • Window Acknowledgement Size (ID=5)：设置确认窗口大小。
   • Set Peer Bandwidth (ID=6)：协商带宽限制。
2. 数据消息（Data Messages）：
   • AMF0 (ID=18) 或 AMF3 (ID=19)：传输元数据或命令（如onMetaData）。
3. 音视频数据：
   • 音频数据 (ID=8)、视频数据 (ID=9)：传输原始音视频流。
4. 用户控制消息 (ID=4)：如流开始/结束事件。

二、元数据（Metadata）

元数据用于描述流的基本信息，通常以onMetaData命令形式通过AMF0/AMF3编码发送。包含字段如：

• 视频宽度、高度、帧率、编码格式。
• 音频采样率、编码类型、时长等。
• 示例AMF0命令格式："onMetaData" + { duration: 60, width: 1280, ... }。

三、消息分块（Message Chunking）

RTMP将消息拆分为多个Chunk传输，以提升实时性。分块规则如下：

1. Chunk Header：
   • Basic Header：1-3字节，包含Chunk Stream ID和Chunk Type。
   • Message Header：根据Chunk Type（0-3）决定包含字段（时间戳、消息长度、Type ID等）。
   • Extended Timestamp（可选）：当时间戳≥0xFFFFFF时启用。
2. 分块示例：
   • 若块大小设为128字节，300字节的消息会被分为3个Chunk（128+128+44）。

四、客户端与服务端协商过程

1. 握手（Handshake）

• C0/S0：交换版本号（通常为3）。
• C1/S1：交换随机数据和时间戳。
• C2/S2：确认随机数据，完成握手。

2. 参数协商（Post-Handshake）

握手后，通过控制消息协商传输参数：

1. Set Chunk Size (Type=1)：
   • 双方发送此消息确定Chunk大小（默认128字节，可设为4096等）。
2. Window Acknowledgement Size (Type=5)：
   • 设置接收方确认窗口大小（流量控制）。
3. Set Peer Bandwidth (Type=6)：
   • 协商带宽限制，接收方需确认模式（硬限/动态/软限）。

3. 连接与流创建

• Connect Command：客户端发送连接请求，包含应用名称、传输参数等。
• CreateStream Command：创建逻辑流，服务端返回Stream ID。
• 发布/播放流：传输音视频数据及元数据（onMetaData）。

五、关键流程示例

1. 客户端发送connect：

   | Chunk Stream ID=3 | AMF0 Command="connect" | Transaction ID=1 | App="live" | ... |
   

2. 服务端响应Window Ack Size和Set Chunk Size：

   | Chunk Stream ID=2 | Control Message (Type=5, Ack Size=2500000) |
   | Chunk Stream ID=2 | Control Message (Type=1, Chunk Size=4096) |
   

3. 发送元数据onMetaData：

   | Chunk Stream ID=4 | AMF0 Data (Type=18) | "onMetaData" + { width: 1280, ... } |
   

总结

• 协商内容：块大小、带宽、确认窗口等，通过控制消息动态调整。
• 元数据：通过AMF数据消息传输，描述流属性。
• 分块机制：提升传输效率，适应网络波动。
• 流程顺序：握手 → 参数协商 → 连接 → 流创建 → 数据传输。

通过上述机制，RTMP实现了低延迟、自适应的流媒体传输，适用于实时性要求高的场景。

RTMP 协议在客户端与服务器建立会话后，通过以下机制维护连接的稳定性，并在断开时进行相应处理：

二 会话维护

一、会话维护机制

1. 心跳机制（Keep-Alive）

RTMP 使用 User Control Messages (Type=4) 中的 Ping/Pong 机制作为心跳：

• Ping (Event=6)：服务器或客户端主动发送，携带时间戳（4字节）。
• Pong (Event=7)：接收方需立即响应，返回相同的 Ping 时间戳。
• 作用：
  • 检测连接活性：若未及时收到 Pong，则认为连接已断开。
  • 默认间隔：通常为 5-10 秒（具体由实现决定）。

2. 流量控制与确认机制

• Window Acknowledgement Size (Type=5)：
  • 接收方告知发送方可发送的最大未确认字节数（例如 2500000 字节）。
  • 发送方需在达到该阈值后暂停发送，直到收到确认（Ack）。
• Acknowledgment (Type=3)：
  • 接收方定期发送已接收字节数的确认，帮助发送方调整传输速率。
• 作用：
  • 避免网络拥塞，同时间接检测连接状态（若无 Ack 返回，可能连接异常）。

3. TCP 层保活（Keep-Alive）

• 依赖 TCP 协议的 Keep-Alive 机制（默认间隔通常较长，如 2 小时）。
• RTMP 更多依赖应用层（Ping/Pong）而非 TCP 保活，因后者响应不够实时。

4. 超时检测

• 服务器/客户端设定 空闲超时时间（如 30 秒）：
  • 若在超时时间内未收到任何数据包或心跳响应，则主动断开连接。

---

二、断开后的处理逻辑

1. 检测断开

• 主动检测：通过心跳超时（未收到 Pong）或 TCP 连接异常事件（如 ECONNRESET）。
• 被动检测：发送数据时发现写入失败（如 Broken Pipe 错误）。

2. 客户端处理

• 自动重连：
  1. 关闭旧连接，重新发起握手（C0-C2/S0-S2）。
  2. 重新协商参数（Chunk Size、带宽等）。
  3. 重新创建流（createStream）并发布/播放。
• 重试策略：
  • 指数退避：首次立即重试，失败后等待 1s、2s、4s… 避免频繁请求。
  • 最大重试次数：例如 3 次后放弃，通知用户。

3. 服务端处理

• 清理资源：
  • 释放与连接关联的流（Stream）和会话（Session）资源。
  • 通知其他订阅者该流已终止（如发送 onStatus 事件）。
• 日志与告警：
  • 记录断开原因（超时、主动关闭、网络错误等）。
  • 触发监控告警（如大量异常断开）。

4. 应用层容错

• 会话恢复：
  • 若支持，客户端重连后可尝试恢复之前的流（需服务端支持会话续传）。
  • 例如，通过唯一 Session ID 关联旧流（非 RTMP 标准，需自定义实现）。
• 状态同步：
  • 重连后重新发送关键元数据（如 onMetaData），确保播放端状态一致。

三、示例流程

1. 正常心跳交互

Server -> Client: User Control Message (Ping, Time=1000)
Client -> Server: User Control Message (Pong, Time=1000)

2. 心跳超时导致断开

Server -> Client: Ping (Time=2000)
[Client未响应]
Server检测超时（30秒）-> 关闭连接，释放资源。

3. 客户端重连

1. 客户端检测断开 -> 触发重连逻辑。
2. 重新握手（C0-C1-C2/S0-S1-S2）。
3. 发送 Set Chunk Size、Window Ack Size 等参数。
4. 发送 createStream 创建新流。
5. 重新发布/播放流并发送元数据。

---

四、优化实践

1. 合理配置超时时间：
   • 心跳间隔：5-10 秒，超时时间：3 倍间隔（如 15-30 秒）。
2. 冗余设计：
   • 客户端实现断线重连队列，缓存未发送的数据（如直播推流的最后几秒数据）。
3. 快速失败与降级：
   • 若多次重连失败，切换备用服务器或通知用户检查网络。
4. 服务端负载均衡：
   • 使用集群避免单点故障，客户端支持故障转移（Failover）。

---

总结

RTMP 通过 应用层心跳（Ping/Pong）、流量控制确认 和 超时检测 维护会话活性。断开后，客户端和服务端需协作清理资源并尝试恢复，通常需应用层逻辑支持完整重连流程。实际开发中需结合业务场景优化重试策略和容错机制，以提升用户体验。