RTMP（Real-TimeMessagingProtocol）

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

一 RTSP 协商消息 一、消息类型（Message Types）

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

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

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

视频宽度、高度、帧率、编码格式。音频采样率、编码类型、时长等。示例AMF0命令格式："onMetaData" + { duration: 60, width: 1280, ... }。 三、消息分块（Message Chunking）

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

Chunk Header： Basic Header：1-3字节，包含Chunk Stream ID和Chunk Type。Message Header：根据Chunk Type（0-3）决定包含字段（时间戳、消息长度、Type ID等）。Extended Timestamp（可选）：当时间戳≥0xFFFFFF时启用。 分块示例： 若块大小设为128字节，300字节的消息会被分为3个Chunk（128+128+44）。 四、客户端与服务端协商过程 1. 握手（Handshake） C0/S0：交换版本号（通常为3）。C1/S1：交换随机数据和时间戳。C2/S2：确认随机数据，完成握手。 2. 参数协商（Post-Handshake）

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

Set Chunk Size (Type=1)： 双方发送此消息确定Chunk大小（默认128字节，可设为4096等）。 Window Acknowledgement Size (Type=5)： 设置接收方确认窗口大小（流量控制）。 Set Peer Bandwidth (Type=6)： 协商带宽限制，接收方需确认模式（硬限/动态/软限）。 3. 连接与流创建 Connect Command：客户端发送连接请求，包含应用名称、传输参数等。CreateStream Command：创建逻辑流，服务端返回Stream ID。发布/播放流：传输音视频数据及元数据（onMetaData）。 五、关键流程示例 客户端发送connect：| Chunk Stream ID=3 | AMF0 Command="connect" | Transaction ID=1 | App="live" | ... | 服务端响应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) | 发送元数据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. 客户端处理 自动重连： 关闭旧连接，重新发起握手（C0-C2/S0-S2）。重新协商参数（Chunk Size、带宽等）。重新创建流（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. 重新发布/播放流并发送元数据。

---

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

---

总结

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