作者：Elias Zhang 聲網資深工程師，擁有從Iaas層的基礎資訊儲存服務到paas層的雲服務的職業經歷，喜歡python語言，習慣使用C#，熟悉基於和結合CDN的業務產品架構，點播、直播、雲導播等。喜歡探索問題和研究創新，擁有5項國家發明專利。
在直播是最常見的實時音視訊場景，而 RTMP 是該場景下最重要的協議之一，是很多初步接觸實時音視訊的開發者需要了解的。本文會一邊利用 winshark工具進行抓包，一邊從中分析 RTMP 協議的基本原理，幫助大家更容易地理解它。
先給出RTMP協議的原檔案 www.adobe.com/devnet/rtmp… 需要用到的時候可以參考一下~。
做推流直播接觸最多的並且最主要是RTMP協議
- RTMP協議是應用層協議，是要靠底層可靠的傳輸層（TCP）
- 協議（通常是TCP）來保證資訊傳輸的可靠性的。在基於傳輸層協議的連結建立完成後，RTMP協議也要客戶端和伺服器通過“握手”來建立基於傳輸層連結之上的RTMP Connection連結. 播放一個RTMP協議的流媒體需要經過以下幾個步驟：握手，建立網路連線，建立網路流，播放。伺服器和客戶端之間只能建立一個網路連線，但是基於該連線可以建立很多網路流。他們的關係如圖所示：
- RTMP協議傳輸時會對資料做自己的格式化，這種格式的訊息我們稱之為RTMP Message，而實際傳輸的時候為了更好地實現多路複用、分包和資訊的公平性，傳送端會把Message劃分為帶有Message ID的Chunk，每個Chunk可能是一個單獨的Message，也可能是Message的一部分，在接受端會根據chunk中包含的data的長度，message id和message的長度把chunk還原成完整的Message，從而實現資訊的收發。 協議本身的詳細欄位和流程就不在這裡詳細解釋了，主要結合看包直觀的瞭解下這個協議的流程，更詳細的內容可以查閱前面給出的官方文件。
RTMP步驟：
1. 握手
要建立一個有效的RTMP Connection連結，首先要“握手”:客戶端要向伺服器傳送C0,C1,C2（按序）三個chunk，伺服器向客戶端傳送S0,S1,S2（按序）三個chunk，然後才能進行有效的資訊傳輸。RTMP協議本身並沒有規定這6個Message的具體傳輸順序，但RTMP協議的實現者需要保證這幾點：
- 客戶端要等收到S1之後才能傳送C2
- 客戶端要等收到S2之後才能傳送其他資訊（控制資訊和真實音視訊等資料）
- 服務端要等到收到C0之後傳送S1
- 服務端必須等到收到C1之後才能傳送S2
- 服務端必須等到收到C2之後才能傳送其他資訊（控制資訊和真實音視訊等資料） 握手開始於客戶端傳送C0、C1塊。伺服器收到C0或C1後傳送S0和S1。 當客戶端收齊S0和S1後，開始傳送C2。當伺服器收齊C0和C1後，開始傳送S2。 當客戶端和伺服器分別收到S2和C2後，握手完成。
實際上真實發包如下：
我們可以看見TCP的三次握手，RTMP基於TCP的可靠傳輸。
接下去過濾rtmpt協議，rtmp的握手過程如下，我們發現真實發包是C0+C1一起發；S0,S1,S2一起發。
2. 建立網路連線（NetConnection）
a) 客戶端傳送命令訊息中的“連線”(connect)到伺服器，請求與一個服務應用例項建立連線。
開啟connect這個包，一個OSI5層協議模型，最後一個是RTMP協議傳送了connect連結訊息，檢視內容包含推流地址名，但是可以觀察到還沒有發流名，地址是有app名。
觀察一下RTMP的包頭
StreamID是每個訊息的唯一標識，劃分成Chunk和還原Chunk為Message的時候都是根據這個ID來辨識是否是同一個訊息的Chunk的，這裡面為0說明這個訊息是初始的0訊息。
Chunk stream ID:message會拆分成多個chunk，同一個Chunk Stream ID必然屬於同一個Message。
message type id(訊息的型別id)：表示實際傳送的資料的型別，如8代表音訊資料、9代表視訊資料。
Format：指的是chunk type。共有4種不同的格式，其中第一種格式欄位為0，可以表示其他三種表示的所有資料，但由於其他三種格式是基於對之前chunk的差量化的表示，因此可以更簡潔地表示相同的資料，實際使用的時候還是應該採用儘量少的位元組表示相同意義的資料。因為type0是表示不同資料，其他是差量，所以可以想象如果搜不到type0的包說明這個流肯定有問題。可以通過“rtmpt.header.format == 0”過濾。
b) 伺服器接收到連線命令訊息後，傳送確認視窗大小(Window Acknowledgement Size)協議訊息到客戶端，同時連線到連線命令中提到的應用程式。
c) 伺服器傳送設定頻寬協議訊息到客戶端。
d) 客戶端處理設定頻寬協議訊息後，傳送確認視窗大小(Window Acknowledgement Size)協議訊息到伺服器端。
e) 伺服器傳送使用者控制訊息中的“流開始”(Stream Begin)訊息到客戶端。
f) 伺服器傳送命令訊息中的“結果”(_result)，通知客戶端連線的狀態。 b~f如圖：在_result我們可以看到連結已經建立成功
接下去的包我們看到發了releaseStream命令，裡面的agora就是流名，所以一個推流地址我們可以抓包connect和releaseStream裡面拼接得出。
- 建立一個網路流（NetStream）
提示：網路流代表了傳送多媒體資料的通道。伺服器和客戶端之間只能建立一個網路連線，且多個網路流可以複用這一個網路連線。
a. 客戶端向伺服器傳送請求建立流（createStream）。
b. 伺服器收到請求後向客戶端傳送_result()，對建立流的訊息進行響應。此時NetStream建立完成。
4. PLAY 播放
a) 客戶端傳送命令訊息中的“播放”（play）命令到伺服器。
b) 接收到播放命令後，伺服器傳送設定塊大小（ChunkSize）協議訊息。
c) 伺服器傳送使用者控制訊息中的“streambegin”，告知客戶端流ID。
d) 播放命令成功的話，伺服器傳送命令訊息中的“響應狀態” NetStream.Play.Start & NetStream.Play.reset，告知客戶端“播放”命令執行成功。
e) 在此之後伺服器傳送客戶端要播放的音訊和視訊資料。
可以注意到裡面音訊type是8，視訊是9。
5. PUBLISH 推流
和第四步play區別在於netstream的命令改為publish
關於本文，如果你在跟隨步驟操作或閱讀時有任何疑問，請點選這裡跳轉至原文與作者直接交流。