RTMP 協(xié)議研究

1 協(xié)議研究概述
?? 協(xié)議設計和分析一直都是在工作遇到，正好在這里總結一下，說到協(xié)議，在這個網(wǎng)絡的時代，沒有人可以離開它了。他存在我們生活中的任何角落，只不過我們平時，并沒有注意到它的存在，可以這么說如果沒有協(xié)議，我們生活和日常的工作生產(chǎn)都不能進行。如果仔細想想你生活中用到的所有東西，協(xié)議已經(jīng)包含其中。那到底什么是協(xié)議呢？說的簡單一點就是雙方達成的共識，以便更好的交流，理論上協(xié)議是什么呢？如果學過《信號與系統(tǒng)》的人都知道有個簡單的道理，就是信息在經(jīng)過一個管道的符號集，到另一個符號集時信息不會丟失。

??? 任何復雜的事物都有個最簡單的本質(zhì)，網(wǎng)絡上的協(xié)議也是這樣，有個最基本的本質(zhì)。除去上下層的概念，協(xié)議就只剩下通信雙方實體的規(guī)則。

?? 一般的協(xié)議都包含最基本的協(xié)議頭，不管是物理層、鏈路層、還是網(wǎng)絡層，這個頭就構成了協(xié)議的本質(zhì)東西。通常協(xié)議頭要包含以下最基本的三項信息：

雙方實體的唯一標示，用來標示通信雙方的實體。
類型描述或者是凈核描述，標志凈核的內(nèi)容。
協(xié)議凈核的長度，用來在萃取凈核的內(nèi)容應用。
?? 其中，前兩項是必須要有的，沒有他們，通信雙方的交互根本得不到保證，第三項在不太靈活的通信中可以去掉，而有第二項的類型推出。

??? 協(xié)議的豐富性，有凈核的多樣性體現(xiàn)。

?? 協(xié)議頭除了以上的三項，還可以增加更多的信息（比如控制信息、時間信息等），取決于具體的應用。找到這些基本的東西，再去看協(xié)議的時候，能夠更好的抓住協(xié)議的主體進行分析和設計了。

???????????? 如圖?? 協(xié)議物理結構

2 RTMP 協(xié)議概述
?? RTMP 協(xié)議是被 Flash 用于對象、視頻、音頻的傳輸。該協(xié)議建立在 TCP 協(xié)議或者輪詢 HTTP 協(xié)議之上， RTMP 協(xié)議就像一個用來裝數(shù)據(jù)包的容器，這些數(shù)據(jù)可以是 AMF 格式的數(shù)據(jù)，也可以是 FLV 中的視 / 音頻數(shù)據(jù)。一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡流，這些通道中的包都是按照固定大小的包傳輸?shù)?.

3 RTMP 協(xié)議部分
3.1 協(xié)議頭
struct RTMP_HEAD

{

????????? char cChannelid : 6;// 第一個字節(jié)的后 6 位

????????? char cCheadsize ; // 第一個字節(jié)的頭兩位

????? char cTimer[3];? // 三個字節(jié)表示的時間信息

????? char cLength[3]; // 三個字節(jié)表示的長度

????? char cDatatype; // 數(shù)據(jù)類型

????? char sStreamid[4]; // 流標識

};

這里有三個最基本的元素（唯一標示 ）、（類型 ）和（凈核的長度 ）分別是： cChannelid 、 cDatatype 和 cLength 。

3.2 數(shù)據(jù)類型
數(shù)據(jù)類型 決定了協(xié)議上層可以做的具體的事情，和使用協(xié)議的人必須遵循的規(guī)則。

同時數(shù)據(jù)類型 說明了凈核 的基本內(nèi)容。

RTMP 數(shù)據(jù)類型：

0×01? Chunk Size? changes the chunk size for packets?
0×02? Unknown? anyone know this one??
0×03? Bytes Read? send every x bytes read by both sides?
0×04? Ping? ping is a stream control message, has subtypes?
0×05? Server BW? the servers downstream bw?
0×06? Client BW? the clients upstream bw?
0×07? Unknown? anyone know this one??
0×08? Audio Data? packet containing audio?
0×09? Video Data? packet containing video data?
0x0A - 0×11? Unknown? anyone know??
0×12? Notify? an invoke which does not expect a reply?
0×13? Shared Object? has subtypes?
0×14? Invoke? like remoting call, used for stream actions too.?

3.3 協(xié)議的凈核
?? RTMP 的協(xié)議凈核是用 AMF 格式來描述， AMF 格式本身的產(chǎn)生就是為了 RTMP 協(xié)議服務的，最初的 RTMP 采用 XML 的形式傳輸數(shù)據(jù)，但 XML 只是字符形式的值對的格式傳輸數(shù)據(jù)，而隨著應用的普及這完全不能滿足要求了，比如對象、結構、數(shù)組，甚至可以是數(shù)據(jù)集，配合 DataGrid 組件可以很方便地顯示數(shù)據(jù)。
為了處理復雜數(shù)據(jù)類型，采用一種獨有的方式使 Flash 與應用服務器間可以來回傳送數(shù)據(jù)勢在必行。于是 AMF 應運而生。

AMF 是 Adobe 獨家開發(fā)出來的通信協(xié)議，它采用二進制壓縮，序列化、反序列化、傳輸數(shù)據(jù)，從而為 Flash 播放器與 Flash Remoting 網(wǎng)關通信提供了一種輕量級的、高效能的通信方式。如下圖所示。
?
AMF 最大的特色在于可直接將 Flash 內(nèi)置對象，例如 Object, Array, Date, XML ，傳回服務器端，并且在服務器端自動進行解析成適當?shù)膶ο螅@就減輕了開發(fā)人員繁復工作，同時也更省了開發(fā)時間。由于 AMF 采用二進制編碼，這種方式可以高度壓縮數(shù)據(jù)，因此非常適合用 來傳遞大量的資料。數(shù)據(jù)量越大， Flash Remoting 的傳輸效能就越高，遠遠超過 Web Service 。至于 XML, LoadVars 和 loadVariables() ，它們使用純文本的傳輸方式，效能就更不能與 Flash Remoting 相提并論了。
注意： Flash Remoting 需要瀏覽器支持 Binary POST ， Flash 播放器在 Netscape 6.x. 環(huán)境下運行 Flash Remoting 會不起作用（ Flash Remoting 調(diào)用沒有效果也不返回錯誤）， Netscape 7 已經(jīng)糾正了這個 bug 。對于早期 Safari 和 Chimera 版的蘋果機也有這個問題。
同樣是輕量級數(shù)據(jù)交換協(xié)議，同樣是通過調(diào)用遠程服務，同樣是基于標準的 HTTP 和 HTTPS 協(xié)議， Flash Remoting 為什么選擇了使用 AMF 而放棄了 SOAP 與 Flash 播放器通信呢? 有如下原因：
?
SOAP 將數(shù)據(jù)處理成 XML 格式，相對于二進制的 AFM 太冗長了；?
AMF 能更有效序列化數(shù)據(jù)；因為 AMF 的初衷只是為了支持 Flash ActionScript 的數(shù)據(jù)類型，而 SOAP 卻致力于提供更廣泛的用途；?
AMF 支持 Flash 播放器 6 只需要瀏覽器增加 4 KB 左右（壓縮后）的大小，而 SOAP 就大多了；?
SOAP 的一些頭部文件請求在 Flash 播放器 6 不支持。那 Flash 播放器 6 為什么能訪問基于 SOAP 的 Web 服務呢？原來 Flash Remoting 網(wǎng)關將 SOAP 請求在服務器端與轉換成 AFM 格式，然后利用 AFM 與 Flash 播放器通信。另外， AMF 包中包含 onResult 事件（比如說 response 事件）和 onStatus 事件（比如說 error 事件），這些事件對象在 Flash 中可以直接使用。?
AMF 從 Flash MX 時代的 AMF0 發(fā)展到現(xiàn)在的 AMF3 。 AMF3 用作 Flash Playe 9 的 ActionScript 3.0 的默認序列化格式，而 AMF0 則用作舊版的 ActionScript 1.0 和 2.0 的序列化格式。 在網(wǎng)絡傳輸數(shù)據(jù)方面， AMF3 比 AMF0 更有效率。 AMF3 能將 int 和 uint 對象作為整數(shù)（ integer ）傳輸，并且能序列化 ActionScript 3.0 才支持的數(shù)據(jù)類型 , 比如 ByteArray ， XML 和 Iexternalizable 。

????? AMF 很好的解決了內(nèi)容的豐富性。（具體 AMF 格式參考附件格式文檔）

3.3.1 AMF中的數(shù)據(jù)類型Data Types
AMF0 supports the following data types (with their type field values):

NUMBER = 0x00
BOOLEAN = 0x01
STRING = 0x02
OBJECT = 0x03
MOVIECLIP = 0x04
NULL_VALUE = 0x05
UNDEFINED = 0x06
REFERENCE = 0x07
ECMA_ARRAY = 0x08
OBJECT_END = 0x09
STRICT_ARRAY = 0x0a
DATE = 0x0b
LONG_STRING = 0x0c
UNSUPPORTED = 0x0d
RECORD_SET = 0x0e
XML_OBJECT = 0x0f
TYPED_OBJECT = 0x10
Binary Format
AMF format for a value/object consists of a type byte (see above) followed by zero or more bytes. This section describes the bytes following the type byte for various types.

NUMBER (type byte: 0x00)
Numbers are stored as 8 byte (big endian) float double. On x86 you can just byteswap a double to encode it correctly.

BOOLEAN (type byte: 0x01)
A boolean is encoded in one byte. FIXME: is true sent as 0xff? 0x01?

STRING (type byte: 0x02)
A string is encoded as a 2 byte (big endian) count (number of bytes) followed by that many bytes of text. Note: there is no null terminator.

I think the text is assumed to be UTF-8. Can someone double check me on this?

NULL_VALUE (type byte: 0x05)
A null has zero bytes following the type byte

UNDEFINED (type byte: 0x06)
A undefined has zero bytes following the type byte

OBJECT (type byte: 0x08)
An object is encoded as a series of key/value pairs. The key is encoded as a STRING (above) WITH NO TYPE BYTE, and the value is any AMF value.

The object encoding is terminated by 0x000009 (that is a zero length string key, followed by the OBJECT_END type byte described below.

OBJECT_END (type byte: 0x09)
This is not really a value, but a marker for the end of an OBJECT. See above.

STRICT_ARRAY (type byte: 0x0a)
This is the encoding for arrays such as ["foo", "bar", 1, 2, 3]. For a hash (a set of key/value pairs) you'll need to use OBJECT above.

An array is encoded as 4 byte (big endian) integer which is the number of elements in the array, followed by that many AMF values.

That's it. There's no terminator of any kind.

Use in shared object files
While most AMF objects are just a value, there is a special variation used by shared object files for properties. Rather than start with the type field, followed by the length, it starts with a byte count, then the name, and then the regular AMF type field, the length, and then the data.

3.4 客戶端和服務器的連接過程
3.4.1客戶和服務器的握手
?

?? Flash Player 以系統(tǒng)時間作為種子通過某種算法生成的數(shù)字簽名，大小是 1537 字節(jié)向服務器發(fā)起第一次握手，服務器根據(jù)客戶端的數(shù)字簽名產(chǎn)生一個 3073 字節(jié)的驗證包，給客戶端，客戶端在接受到服務器的回應以后會發(fā)送一個 1536 字節(jié)的回復。

具體的流程：

發(fā)送第一次握手包 handshark1
接收第二次握手包 handshark2
發(fā)送的三次握手包 handshark3
第一個握手包 handshark1 和服務器的回復握手包 handshark2 都是以 0X03 開頭。這三次握手不是 RTMP 協(xié)議本身的內(nèi)容，所以在這并沒有包含 RTMP? 的協(xié)議頭。是服務器的廠家自己產(chǎn)品做驗證用的，嚴格的說就是你必須用? Adobe 的客戶端和服務器才能使用我的協(xié)議。

3.4.2客戶和服務器通信
?? 具體連接和請求視頻的過程

發(fā)送 rtmp_connect 命令
. 發(fā)送本地帶寬消息 . 默認是 125000
服務器返回服務器帶寬信息
服務器返回本地帶寬信息
服務器返回連接成功消息 "NetConnection.Connect.Success"
客戶端發(fā)送創(chuàng)建流請求 encodeCreateStreamPacket
服務器返回創(chuàng)建流成功消息
客戶端發(fā)送播放文件消息 Rtmp_Play
服務器返回 TYPE_CHUNK_SIZE 消息
服務器返回開始播放消息 "NetStream.Play.Start"
服務器返回視頻信息 (TYPE_STREAM_METADATA) ，包括大小，寬高，速率等等信息－－文件長度可以在這里推算出來
RTMP 的凈核決定了內(nèi)容服務， adobe 的服務器采用的 AMF 格式的字串命令來控制視頻的傳輸和播放，具體的字串命令信息如下：（注：字串的定義有廠家（ adobe ）自己定義，只要滿足 AMF 的格式就可以）

?
?
NetConnection.Call.Failed
NetConnection.Call.BadVersion?
NetConnection.Connect.AppShutdown
NetConnection.Connect.Closed
NetConnection.Connect.Rejected
NetConnection.Connect.Success
NetStream.Clear.Success
NetStream.Clear.Failed
NetStream.Publish.Start
NetStream.Publish.BadName
NetStream.Failed
NetStream.Unpublish.Success
NetStream.Record.Start
NetStream.Record.NoAccess
NetStream.Record.Stop
NetStream.Record.Failed
NetStream.Play.InsufficientBW
NetStream.Play.Start
NetStream.Play.StreamNotFound
NetStream.Play.Stop
NetStream.Play.Failed
NetStream.Play.Reset
NetStream.Play.PublishNotify
NetStream.Play.UnpublishNotify
NetStream.Data.Start
Application.Script.Error
Application.Script.Warning
Application.Resource.LowMemory
Application.Shutdown
Application.GC
Play
Pause
demoService.getListOfAvailableFLVs
getStreamLength
connect
app
flashVer
swfUrl
tcUrl
fpad
capabilities
audioCodecs
audioCodecs
videoCodecs
videoFunction
pageUrl
createStream
deleteStream
duration
framerate
audiocodecid
audiodatarate
videocodecid
videodatarate
height
width
3.4.2數(shù)據(jù)的萃取
????? 在服務器返回開始播放消息 "NetStream.Play.Start" 之后，服務器就會開始給客戶端傳輸數(shù)據(jù)了，一般數(shù)據(jù)的萃取都是先解析協(xié)議的頭，然后根據(jù)協(xié)議頭中數(shù)據(jù)類型和凈核長度就可以把數(shù)據(jù)部分取出， RTMP 協(xié)議也是這樣。

struct RTMP_HEAD

{

????????? char cChannelid : 6;// 第一個字節(jié)的后 6 位

????????? char cCheadsize ; // 第一個字節(jié)的頭兩位

????? char cTimer[3];? // 三個字節(jié)表示的時間信息

????? char cLength[3]; // 三個字節(jié)表示的長度

????? char cDatatype; // 數(shù)據(jù)類型

????? char sStreamid[4]; // 流標識

}

????? 首先判斷 cDatatype 是那種類型，然后根據(jù)不同的類型進行萃取數(shù)據(jù)部分，進行不同的處理，獲取視頻的數(shù)據(jù)的方式先看是否是一下的類型：

0×08? Audio Data? packet containing audio?
0×09? Video Data? packet containing video data?

?
根據(jù)凈核的長度讀取出內(nèi)存中的音視頻數(shù)據(jù)，這里的音視頻數(shù)據(jù)是有一定編碼格式的數(shù)據(jù)，這個取決于應用的具體配置， Flash play 使用的是 FLV 的格式。要對這部分數(shù)據(jù)進行存取，還有做一部分工作，對 FLV 的視頻數(shù)據(jù)進行去殼，取出數(shù)據(jù)保存文件就可以了。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/chenyanxu/archive/2009/09/02/4511087.aspx