—— 2017-2-12 更新
rtmp 協議整理了一下，包括rtmp 訊息型別，rtmp 如何分塊，rtmp分塊例子。 用腦圖整理了一下，使用xmind 開啟，url：
rtmp 訊息型別
rtmp 訊息分塊
rtmp 握手分為簡單握手和複雜握手，現在adobe公司使用rtmp協議的產品應該用的都是複雜握手，這裡不介紹，只說簡單握手。 按照網上的說法rtmp握手的過程如下
握手開始於客戶端傳送c0、c1塊。伺服器收到c0或c1後傳送s0和s1。在實際工程應用中，一般是客戶端先將當客戶端收齊s0和s1後，開始傳送c2。當伺服器收齊c0和c1後，開始傳送s2。
當客戶端和伺服器分別收到s2和c2後，握手完成。
c0,c1塊同時發出，伺服器在收到c1之後同時將s0,s1,s2發給客戶端。s2的內容就是收到的c1塊的內容。之後客戶端收到s1塊，並原樣返回給伺服器，簡單握手完成。按照rtmp協議個要求，客戶端需要校驗c1塊的內容和s2塊的內容是否相同，相同的話才徹底完成握手過程，實際編寫程式用一般都不去做校驗。
rtmp握手的這個過程就是完成了兩件事：1. 校驗客戶端和伺服器端rtmp協議版本號，2. 是發了一堆資料，猜想應該是測試一下網路狀況，看看有沒有傳錯或者不能傳的情況。rtmp握手是整個rtmp協議中最容易實現的一步，接下來才是大頭。
建立rtmp連線算是比較難的地方，開始涉及訊息分塊（chunking）和 afm（也是adobe家的東西）格式資料的一些東西，在上面提到的文章中也有介紹為什要進行rtmp分塊。
chunk size
chunk type
rtmp 分成的chunk有4中型別，可以通過 chunk basic header的 高兩位指定，一般在拆包的時候會把乙個rtmp訊息拆成以 type_0 型別開始的chunk，之後的包拆成 type_3 型別的chunk，我檢視了有不少**也是這樣實現的，這樣也是最簡單的實現。
rtmp 中關於message 分chunk只舉了兩個例子，這兩個例子不是很具有代表性。假如第二個message和第乙個message的message stream id 相同，並且第二個message的長度也大於了chunk size，那麼該如何拆包？當時查了很多資料，都沒有介紹。後來看了一些原始碼，發現第二個message可以拆成type_1型別乙個chunk, message剩餘的部分拆成type_3型別的chunk。ffmpeg中好像就是這麼做的。
connect訊息
握手之後先傳送乙個connect 命令訊息，命令裡面包含什麼東西，協議中沒有說，真實通訊中要指定一些編譯碼的資訊，這些資訊是以amf格式傳送的, 下面是用swift 寫的connect命令包含的引數資訊：
transactionid += 1 // 0x01
建立完rtmp連線之後就可以建立rtmp流，客戶端要想伺服器傳送乙個releasestream命令訊息，之後是fcpublish命令訊息，在之後是createstream命令訊息。當傳送完createstream訊息之後，解析伺服器返回的訊息會得到乙個stream id, 這個id也就是以後和伺服器通訊的message stream id, 一般返回的是1，不固定。
publish stream另外這篇文章有些地方還是說的模糊，以後有時間慢慢豐富吧。
from：
直播 android端推流實現一
h264編碼是得到連續的流，流中有很多幀 i幀稱為關鍵幀，p幀，b幀 要想傳遞給伺服器的資料是不丟幀的，需要對流進行重新打亂，比如第一段先傳i幀資料報，再傳b幀資料報等。這個傳遞給伺服器的工具就是rtmpdump，它是真正實現擺放資料的，會將h264資料轉成packet，推到伺服器。它是遵循rtmp...
實現直接輸出h264直播流的rtmp伺服器
有很多知名的rtmp server，其中既有商業程式也有開源程式，簡單列舉如下 開源專案 商業程式 當然，還有一些其他的開源 商業rtmp伺服器 如ffserver 我就不一一枚舉了。我並沒有一一嘗試，不過，從它們的宣告來看，一般來說，商業rtmp程式要比開源程式支援更多的協議以及更多的平台，至於哪...
直播平台搭建中關於直播推流的三種常見協議
直播行業經過爆發式增長後 荷爾蒙經濟 逐漸減退，如今的直播行業商業模式已經趨於成熟，並開始進入發展的新階段。直播平台搭建專案也早已成為熱門開發專案，但是在進行專案開發之前，關於直播的推拉流也是需要進行了解的。而推流是直播的第一步，所以今天給大家簡單分享一下推流中都有哪些推送協議和他們的現狀及優缺點。...