[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 塊流而言，這是一個不透明的值。 ### 有效載荷 消息的另一個部分就是有效負載，這是這個消息所包含的實際內容。例如，它可以是一些音頻樣本或者壓縮的視頻數據。