學過很多的協議。看過很多的文件。基本都看完就忘記。今天嘗試下新方法，看看能不能徹底理解這些訊息 資訊。
rtmp的基本結構有兩種:message 和chunk ，一系列的互動，一系列的語法，都基於這兩種訊息。下面看著兩種結構的具體語法和關係
二者之間的關係
這個關係就像我們說話都有間隔，寫文字都有標點符號意義。許多個chunk，可以表達乙個message，message堆積起來，就是一篇文章，乙個互動。
下面理解chunk的四種寫法，就像我們寫文章都有句號，逗號一樣，如果只有乙個標點符號，文字豈不很無趣麼？
chunk比較繞彎的地方就是有個header of header，名字叫做basic header .格式如下
還可以變形如下
如下
這就是所謂的basic header的長度在1-3個位元組，都是為了表示所謂的csid啦。不過我們用的最多的是第一種形式，就是只有8小位一大位的。而且我們重點關注的只是高兩位，他表示了chunk的四種格式。我們稱之為fmt
首先歡迎最複雜 最完整 長度也最長的fmt=0的格式。
基本就是複製了message head的情況。所以，這種格式也不常用，基本用在第乙個包。要是經常使用這種格式，那麼資料冗餘得多大啊，因為msg type ，msg stream id 都不是每個包都需要傳的，在某些場合，msg length也不需要傳，在某些極端場合，比如大包拆小包，time更不要傳輸。下面我我們就看看最極端的場合。
fmt=3的包格式
啥也沒有。對。這就是=3的時候，是不需要chunk head 頭的。那麼，在我們常用的音訊傳輸中，有時候採用cbr來編碼，每個包的大小一致，各種id也都一樣。只是時間戳不一樣。這種情況下怎麼傳，請出我們的下一種包格式
沒錯，只有三個位元組的時間增量。大大減少了資料量，比那rtp協議要少的多了。當然，rtp協議主要是基於udp使用的，考慮到丟包的情況，需要每個包都帶完整的資訊。rtmp是tcp的，丟包基本不用考慮。所以可以能少則少。
什麼不一樣，把什麼傳出去。7個位元組。其實我覺得那個msg type id 也完全不必要，6個位元組就可以了。
下面我們舉例子來說明各種情況
例子一，有下面資料要傳送
這個是我們發cbr音訊資料時，經常碰到的情況。大小 ｉｄ 都一樣，只有時間戳有增量。那麼傳送情況如下
第乙個包還是乙個完整資訊的包，第二包，就優化到只有乙個時間戳增量了。到第三個包，時間戳增量也不需要了。直接乙個包頭加資料。。
在看乙個拆包的例子
307個位元組，我們預設的chunk size是128個位元組，當然要拆了
那麼問個問題rtmp包是怎麼檢查丟包的呢？
答案是rtmp根本就沒考慮這些，因為這些rtmp是基於tcp的，這些工作，tcp層以及做了。所以，想rtmp over udp的同學，要自己做好丟包檢測演算法。
另外。我們會注意到每個包都有兩個id，乙個是msg的stream id,乙個是chunk的csid。這兩個id有啥區別？
這兩id沒有任何關係。streamid是伺服器隨機生成的，用於標識乙個會話的id，而csid，某種情況下是系統自用id，表示chuank型別，和msg type倒是有些關聯。
RTMP協議概述
rtmp協議概述 介紹 rtmp協議就像乙個用來裝資料報的容器,這些資料可以是amf格式的資料,也可以是flv中的視 音訊資料.乙個單一的連線可以通過不同的通道傳輸多路網路流.這些通道中的包都是按照固定大小的包傳輸的.網路連線 connection copy to clipboard code va...
RTMP協議分析
rtmp協議封包 由乙個包頭和乙個包體組成,包頭可以是4種長度的任意一種 12,8,4,1 byte s 完整的rtmp包頭應該是12bytes,包含了時間戳,amfsize,amftype,streamid資訊,8位元組的包頭只紀錄了時間戳,amfsize,amftype,其他位元組的包頭紀錄資訊...
rtmp 協議詳解
rtmp協議是乙個網際網路tcp ip五層體系結構中應用層的協議。rtmp協議中基本的資料單元稱為訊息 message 當rtmp協議在網際網路中傳輸資料的時候，訊息會被拆分成更小的單元，稱為訊息塊 chunk 1 訊息 2 訊息塊 在網路上傳輸資料時，訊息需要被拆分成較小的資料塊，才適合在相應的網...