RTMP協(xié)議是一個(gè)互聯(lián)網(wǎng)TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層的協(xié)議。RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息（Message）。當(dāng)RTMP協(xié)議在互聯(lián)網(wǎng)中傳輸數(shù)據(jù)的時(shí)候，消息會(huì)被拆分成更小的單元，稱為消息塊（Chunk）。
1 消息
消息是RTMP協(xié)議中基本的數(shù)據(jù)單元。不同種類(lèi)的消息包含不同的Message Type ID，代表不同的功能。RTMP協(xié)議中一共規(guī)定了十多種消息類(lèi)型，分別發(fā)揮著不同的作用。例如，Message Type ID在1-7的消息用于協(xié)議控制，這些消息一般是RTMP協(xié)議自身管理要使用的消息，用戶一般情況下無(wú)需操作其中的數(shù)據(jù)。Message Type ID為8，9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼的命令，負(fù)責(zé)用戶與服務(wù)器之間的交互，比如播放，暫停等等。消息首部（Message Header）有四部分組成：標(biāo)志消息類(lèi)型的Message Type ID，標(biāo)志消息長(zhǎng)度的Payload Length，標(biāo)識(shí)時(shí)間戳的Timestamp，標(biāo)識(shí)消息所屬媒體流的Stream ID。消息的報(bào)文結(jié)構(gòu)如下圖所示。
2 消息塊
在網(wǎng)絡(luò)上傳輸數(shù)據(jù)時(shí)，消息需要被拆分成較小的數(shù)據(jù)塊，才適合在相應(yīng)的網(wǎng)絡(luò)環(huán)境上傳輸。RTMP協(xié)議中規(guī)定，消息在網(wǎng)絡(luò)上傳輸時(shí)被拆分成消息塊（Chunk）。消息塊首部（Chunk Header）有三部分組成：用于標(biāo)識(shí)本塊的Chunk Basic Header，用于標(biāo)識(shí)本塊負(fù)載所屬消息的Chunk Message Header，以及當(dāng)時(shí)間戳溢出時(shí)才出現(xiàn)的Extended Timestamp。消息塊的報(bào)文結(jié)構(gòu)如下圖所示。
3 消息分塊
在消息被分割成幾個(gè)消息塊的過(guò)程中，消息負(fù)載部分（Message Body）被分割成大小固定的數(shù)據(jù)塊（默認(rèn)是128字節(jié)，最后一個(gè)數(shù)據(jù)塊可以小于該固定長(zhǎng)度），并在其首部加上消息塊首部（Chunk Header），就組成了相應(yīng)的消息塊。消息分塊過(guò)程如下圖所示，一個(gè)大小為307字節(jié)的消息被分割成128字節(jié)的消息塊（除了最后一個(gè)）。
RTMP傳輸媒體數(shù)據(jù)的過(guò)程中，發(fā)送端首先把媒體數(shù)據(jù)封裝成消息，然后把消息分割成消息塊，最后將分割后的消息塊通過(guò)TCP協(xié)議發(fā)送出去。接收端在通過(guò)TCP協(xié)議收到數(shù)據(jù)后，首先把消息塊重新組合成消息，然后通過(guò)對(duì)消息進(jìn)行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。
2.1 Chunk Basic Header [1-3字節(jié)]
HeaderType+ChannelID組成，其中ChannelID的大小決定了整個(gè)Chunk Basic Header的大小
2.1.1
ID
和消息塊的類(lèi)型，消息塊類(lèi)型決定了消息包頭的編碼格式，長(zhǎng)度完全
HeaderType(fmt):決定了Chunk Message Header的編碼方式和大小,在第一個(gè)字節(jié)的高兩位
Bits Chunk Message Header Length
00 12 bytes
01 8 bytes
10 4 bytes
11 1 byte
2.1.2 ChannelID：
ChannelID 用途
02 Ping 和ByteRead通道
03 Invoke通道 我們的connect() publish()和自字寫(xiě)的NetConnection.Call() 數(shù)據(jù)都是在這個(gè)通道的
04 Audio和Vidio通道
05 06 07 服務(wù)器保留,經(jīng)觀察FMS2用這些Channel也用來(lái)發(fā)送音頻或視頻數(shù)據(jù)
2.2 Chunk Message Header
以最大fmt =00 length(Chunk Message Header) == 12 為例
Chunk Message Header的結(jié)構(gòu)是:timestamp,message_length,message_type,msg_stream_id
其中message_type是一個(gè)枚舉變量：
type為1,2,3,5,6的時(shí)候是協(xié)議控制消息
type為4的時(shí)候表示 User Control Messages [Event_type + Event_Data] Event_type有Stream Begin，Stream End...
type為8，音頻數(shù)據(jù)
type為9，視頻數(shù)據(jù)
type為18 元數(shù)據(jù)消息[AMF0]
type為20 命令消息 Command Message(RPC Message)
These messages are sent to perform some operations like connect, createStream, publish, play, pause on the peer.
命令消息主要分成兩種NetConnection和NetStream。
connect，call，close，createStream命令可以在NetConnection中發(fā)送。
coonect(name，TranscationID,Command Object<name-value> pair)
play，publish,seek,pause等命令可以在NetStream中發(fā)送。
2.3 Ext Time Stamp
2.4數(shù)據(jù)
3 RTMP流媒體播放過(guò)程
RTMP協(xié)議規(guī)定，播放一個(gè)流媒體有兩個(gè)前提步驟：第一步，建立一個(gè)網(wǎng)絡(luò)連接（NetConnection）；第二步，建立一個(gè)網(wǎng)絡(luò)流（NetStream）。其中，網(wǎng)絡(luò)連接代表服務(wù)器端應(yīng)用程序和客戶端之間基礎(chǔ)的連通關(guān)系。網(wǎng)絡(luò)流代表了發(fā)送多媒體數(shù)據(jù)的通道。服務(wù)器和客戶端之間只能建立一個(gè)網(wǎng)絡(luò)連接，但是基于該連接可以創(chuàng)建很多網(wǎng)絡(luò)流。
播放一個(gè)RTMP協(xié)議的流媒體需要經(jīng)過(guò)以下幾個(gè)步驟：握手，建立連接，建立流，播放。RTMP連接都是以握手作為開(kāi)始的。建立連接階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)連接”；建立流階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)流”；播放階段用于傳輸視音頻數(shù)據(jù)。
參考:http://blog.csdn.net/leixiaohua1020/article/category/1362941
RTMP協(xié)議中文版
http://wenku.baidu.com/link?url=Lc4gR-FLeCkHCMM1NL-FcAUtKFTRaFn0tcdoqcid6Dtvu_Q2wlSQ-GMY711Ptc_TdeG2KU0E9e-aHddFVZJSMwt2CujY2p7AdHg8Vr15HuG
RTMP協(xié)議英文版
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
開(kāi)源項(xiàng)目 RTMP Dump
http://rtmpdump.mplayerhq.hu/