[TOC] [TOC] ## RTMP 握手流程  握手后走開始從 CONNECT 請求開始  上面的c0、c1和s0、s1、s2都是有固定長度。簡單握手中c1和s1從第9個字節開始都是**隨機數**。**s2是c1的復制，c2是s1的復制** ## Message(消息) 與 Chunking(Message分塊) ### Message(消息) 這?的Message(flv的tag需要封裝成Message)是指滿?該協議格式的、可以切分成Chunk發送的消息，消息包含的字段如下： 1. Timestamp（時間戳）：消息的時間戳（但不?定是當前時間，后?會介紹），4個字節表示。 2. Length(?度)：是指Message Payload（消息負載）即?視頻等信息的數據的?度，3個字節表示。 3. TypeId(類型Id)：消息的類型Id，1個字節。 4. Message Stream ID（消息的流ID）：每個消息的**唯?標識**，劃分成Chunk和還原Chunk為Message的時候都是根據這個ID來辨識是否是同?個消息的Chunk的，4個字節，并且以?端格式存儲。 ### Chunking(Message分塊) RTMP在收發數據的時候并不是以Message為單位的，?是把Message**拆分成Chunk**發送，?且必須在**?個Chunk發送完成之后**才能**開始發送下?個Chunk(一般不會交替發送)**。每個Chunk中帶有**Message ID**代表屬于哪個Message，接收端也會按照**這個id來**將chunk**組裝成Message** 為什么要對Message 進行拆分 1. 分包能夠減小延時和阻塞，更能適應復雜網絡環境變化。 2. 通過拆分，數據量較?的Message可以被拆分成較?的“Message”，這樣就可以避免優先級低(數據量大)的消息持續發送阻塞優先級?(數據量低)的數據 **分塊設置** 1. Chunk的默認??是128字節,在傳輸過程中，通過?個叫做Set Chunk Size的控制信息 2. 可以設置Chunk數據量的最?值，在發送端和接受端會各?維護?個Chunk Size（srs流媒體服務器默認是60000）可分別控制 #### Chunk Format（塊格式）  - ?個流當中可以交錯傳輸多種消息類型的Chunk,通過Chunk Stream ID區分的，同?個Chunk Stream ID必然屬于同?個Message - 不同的Message的**chunk Stream ID是不一樣**,RTMP流中視頻和?頻擁有單獨的Chunk Stream ID，?如?頻的cs id=20，視頻的cs id=21。接收端接收到Chunk之后，根據cs id分別將?頻和視頻“拼成成Message消息” > 每?種消息類型的起始chunk 的類型必須是 Type_0 類型的，表明我是?個新的消息的起始 **Basic Header(基本的頭信息)** - chunk stream ID（流通道Id）和chunk type（chunk的類型） - RTMP協議最多?持65597個?戶?定義chunk stream ID，范圍為[3，65599] ，ID 0, 1, 2被協議規范直接使?，其中ID值為0, 1分表表示了Basic Header占?2個字節和3個字節 1. 當Basic Header為1個**字節**時,CSID占**6位**,其中?戶可?定義的范圍為 [3，63] ，實際是可以?2開始?  chunk type 表示為 fmt 2. ID值0：代表Basic Header占?2個字節，CSID在 [64，319] 之間  第?個字節除chunk type占?的bit都置為0. 第?個字節?來表示CSID-64，8位可以表示 [0, 255] 共256個數 3. ID值1：代表Basic Header占?3個字節  ### Message Header（消息的頭信息) Message Header的格式和?度取決于Basic Header的**chunk type**，共有4種不同的格式 **Type＝0: 占?11個字節**  1. timestamp（時間戳）：占?3個字節，因此它最多能表示到16777215=0xFFFFFF=2^24-1, 當它的值超過這個最?值時，這三個字節都置為1，這樣實際的timestamp會轉存到Extended Timestamp字段中，接收端在判斷timestamp字段24個位都為1時就會去Extended timestamp中解析實際的時間戳 2. message length和message length(cont)（消息數據的?度），占?3個字節，表示實際發送的消息的數據如?頻幀、視頻幀等數據的?度，單位是字節。注意這?是Message的?度，也就是chunk屬于的Message的總數據?度，?不是chunk本身Data的數據的?度 3. message type id(消息的類型id)：占?1個字節，表示實際發送的數據的類型，如8代表?頻數據、9代表視頻數據 4. msg stream id（消息的流id）：占?4個字節，表示該chunk所在的流的ID，和Basic Header的CSID?樣，它采??端存儲的?式 **Type = 1:占?7個字節**  1. timestamp delta：占?3個字節，注意這?和type＝0時不同，存儲的是和上?個chunk的時間差 **Type = 2:占?3個字節**  **Type = 3:占?0字節** 它表示這個chunk的Message Header和上?個是完全相同的,就不需要傳輸了 ### Extended Timestamp（擴展時間戳） chunk中會有時間戳timestamp和時間戳差timestamp delta，并且它們不會同時存在，只有這兩者之??于3個字節能表示的最?數值0xFFFFFF,會?這個字段來表示真正的時間戳