[TOC] ## RTMP消息格式  抓包  <br/> **协议头信息** * byte #1 (0x03) = Chunk Header Type. * byte #2-4 (0x000b68) = Timestamp delta. * byte #5-7 (0x000019) = Packet Length - in this case it is 0x000019 = 25 bytes. * byte #8 (0x14) = Message Type ID - 0x14 (20) defines an AMF0 encoded*command*message. * byte #9-12 (0x00000000) = Message Stream ID. This is in little-endian order. ## **Message Type ID byte** ``` 0x01 = Set Packet Size Message. 0x02 = Abort. 0x03 = Acknowledge. 0x04 = Control Message. 0x05 = Server Bandwidth 0x06 = Client Bandwidth. 0x07 = Virtual Control. 0x08 = Audio Packet. 0x09 = Video Packet. 0x0F = Data Extended. 0x10 = Container Extended. 0x11 = Command Extended (An AMF3 type command). 0x12 = Data (Invoke (onMetaData info is sent as such)). 0x13 = Container. 0x14 = Command (An AMF0 type command). 0x15 = UDP 0x16 = Aggregate 0x17 = Present ``` **Invoke Message Structure (0x14, 0x11)** 使用 0x14, 或0x11 的 AMF 使用以下结构 ``` (String) <Command Name> (Number) <Transaction Id> (Mixed) <Argument> ex. Null, String, Object: {key1:value1, key2:value2 ... } ``` 对0x14 抓包  **Control Message Structure (0x04)** ### 消息头  抓包 - **Timestamp**（时间戳）：对于一个类型 1 或者类型 2 的块，前一块的 timestamp 和当前块的 timestamp 的区别在这里发送。如果 delta 大于或者等于 16777215 (十六进制 0xFFFFFF)，那么这一字段必须是为 16777215，表示具有扩展 timestamp 字段来对整个 32 位 delta 进行编码。否则的话，这一字段应该是为具体 delta。 - **Length**(长度)：对于一个类型 0 或者类型 1 的块，消息长度在这里进行发送。注意这通常不同于块的有效载荷的长度。块的有效载荷代表所有的除了最后一块的最大块大小，以及剩余的 (也可能是小消息的整个长度) 最后一块。 - **Message Type Id** (消息类型)：对于类型 0 或者类型 1 的块，消息的类型在这里发送。类型 ID 1 - 6 被保留用于协议控制消息。这些传播信息的消息由 RTMP 块流协议和上层协议共同处理。其他的所有类型 ID 可用于上层协议，它们被 RTMP 块流处理为不透明值。事实上，RTMP 块流中没有任何地方要把这些值当做类型使用；所有消息必须是同一类型，或者应用使用这一字段来区分同步跟踪，而不是类型。 - **Message Stream Id** (消息流 ID)：对于一个类型为 0 的块，保存消息流 ID。消息流 ID 以小端格式保存。所有同一个块流下的消息都来自同一个消息流。当可以将不同的消息流组合进同一个块流时，这种方法比头压缩的做法要好。但是，当一个消息流被关闭而其他的随后另一个是打开着的，就没有理由将现有块流以发送一个新的类型 0 的块进行复用了。message stream (消息流) ID 可以使任意值。合并到同一个块流的不同的消息流是根据各自的消息流 ID 进行分解。除此之外，对 RTMP 块流而言，这是一个不透明的值。 ### 有效载荷 消息的另一个部分就是有效负载，这是这个消息所包含的实际内容。例如，它可以是一些音频样本或者压缩的视频数据。