原文地址：http://blog.csdn.net/vinowan/article/details/45934627

1      協議介紹

Real-Time Media Flow Protocol（簡稱RTMFP）是Flash和Flash之間基於UDP的點對點傳輸協議，由Adobe公司在2008年在Flash 10.0中釋出，隨後在Flash10.1中加入了Groups功能。

2      常見用法

rtmfp在Flash 10中的典型使用場景如下圖：

它有如下特點：

l  使用Cirrus或者開源的Cumulus來提供Rendezvous服務

l  Cirrus或者Cumulus並不提供Peer ID的交換服務，需要提供其它的方式來交換客戶端之間的Peer ID

l  Flash客戶端之間使用NetStream來做點對點傳輸，Publisher需要給每一個Subscriber單獨傳輸一份資料，這也限制叢集的規模。

為了解決這個問題，Adobe在Flash 10.1中提出了Groups的概念，典型的架構如下：

它有如下特點：

l  Cirrus或者開源的Cumulus提供Rendezvous服務並提供所有連線client列表

l  client從Cirrus或者開源的Cumulus獲取鄰居節點之後，就可以組成一個完整的P2P架構，所有的audio、video和data資料都在peer之間互動。

3      協議解析

3.1 基本概念

l  session：session是兩個UDP地址之間的雙向管道。

l  flow：flow是從一個實體到另一個實體之間的邏輯路徑。一個session可以包括多個flow。

l  packet：網路中實際傳輸的資料，一個packet可以包含多個message。資料傳輸時都經過了128 bit的AES加密

l  message：audio、video和data資料。

3.2 Scrambled Session ID

rtmfp協議中每個包的格式如下：

packet := scrambled-session-id | encrypted-part

其中scrambled-session-id是4位元組，其後是經過AES加密的資料體。

scramble-session-id的生成規則如下：

scrambled-session-id = a ^ b ^ c

這裡^代表XOR操作，a是session-id，b和c是encrypted-part的頭8個bytes。

當目標收到這個包後，unscramble的操作如下：

session-id = x ^ b ^ c

其中x是scrambled-session-id，b和c同上。

使用scramble-session-id的目的為了減少資料包流經的NAT裝置和layer-4 packet inspector對資料的干擾。

session-id用於標識通訊雙方建立的連線，並確定通訊時使用的加密和解密的key，這些key是通過DH key exchange演算法獲得。但在session建立之前，雙方使用一個公有加密key，即128 bit的字串”Adobe System 02”。

3.3 raw part

encrypted-part經過解密之後就得到了raw-part，它的格式如下：

raw-part := checksum | network-layer-data | padding

其中checksum有16位元組，network-layer-data是變長資料，padding都是0xFF，並把network-layer-data補齊為16位元組的倍數，這是因為rtmfp使用的是16位元組的加解密key。

checksum基於network-layer-data和padding計算。

3.4 network layer data

network-layer-data的格式如下：

network-layer-data = flags | timestamp | timestamp-echo | chunks

其中flags為1個位元組，其格式如下：

7 6  5       4     3  2  1 0

TC TCR reserved reserved TS TSE mode

l  mode：11代表握手包，01代表initiator傳送包，10代表responder傳送包，00不是合法值

l  TSE：包中是否包含timestamp-echo域

l  TS：包中是否包含timestamp域

l  TCR：time critical reverse notification表明傳送方正在從其它地方收到timecritical包

l  TC：time critical forward notification表明傳送方傳送的是timecritical包

timestamp域有2位元組，精度是4ms，他的計算方式如下：

timestamp = int(time * 1000 / 4) & 0xFFFF

timestamp-echo域是server收到包的時間戳，當傳送放收到這個值之後，傳送方就可以計算RTT值了。

chunk型別的格式如下：

chunk = type | size | payload

type欄位為1個位元組，其中0xFF不可用，這個是用來區分chunk資料和padding資料的標記。type的定義如下：

size是2位元組payload長度。

payload根據type的不同有不同的資料體。

3.5 message flow

session中包括3類訊息：

l  handshake：握手包，包括initiator hello, responder hello, initiator initial keying,responder initial keying, responder hello cookie change和responderredirect

l  control：控制包，包括ping, ping reply, rekeying initiate, rekeying response, close, closeacknowledge, forwarded initiator hello.

l  flow：流訊息，包括user data, next user data, buffer probe, user data ack, user dataack, flow exception report.

session的建立是通過握手（handshake）來完成的，正常的messageflow如下：

如果是在NAT打洞是，cumulus server就作為一個forwarder，他會把initiatro hello包轉發到其它的client：

另外，cumulus server還可以讓client重定向到其它server：

這裡所說的client是Flash Player，而server是cumulus server或者Flash media server。當然server也可以給client傳送initiator hello請求，這個在cumulus中被稱為man in the middle，不過這個特性還不穩定。

session的建立包括4次握手：

1          initiator -> target:initiator hello

2          target  -> initiator: responder hello

3          initiator -> target:initiator initial keying

4          target  -> initiator: responder initial keying

這個4次握手過程可以阻止Dos攻擊和syn-flooding攻擊。

每個session都有一個session-id來唯一標識這個session，並且session中的每個packet都會包含這個session-id，但是在session建立的4個握手包中，initiator-hello, responder hello和initiator initialkeying的session-id欄位都是0，在傳送最後一個包responder initial keying時，session建立成功並且session-id確定，所以responderinitial keying包含合法的session-id。

我們接下來詳細介紹一下這4個握手包

3.5.1 initiator hello

initiator hello包的格式如上所述，這裡只說明payload部分的格式：

initiator-hello payload = first | epd type | epd value| tag

其中：

l  first：1 byte magic number

l  epd type：1 byte，只有兩個合法值：

n  0x0a：client-server模式，epd value是想要連線的server的rtmfp url

n  0x0f：peer-to-peer模式，epd value是想要連線的client的peer id，一般是固定的32位元組

l  epd value：varlen + body

l  tag：16 bytes隨機數

3.5.2 responder hello

responder hello包的payload格式如下：

responder hello payload = tag-echo | cookie | responder-certificate

其中：

l  tag-echo：和initiator hello中的tag一致，但和initiator hello中不同的是，這裡在前面有一個varlen來表明tag的長度

l  cookie：responder產出的64 bytes隨機數，用來防止syn-flooding攻擊

l  responder certificate：diffie-hellman key exchange演算法交換的資訊，它的格式如下：

certificate= \0x01\0x0A\0x41\0x0E | dh-public-num | \0x02\0x15\0x02\0x02\0x15\0x05\0x02\0x15\0x0E

dh-public-num是一個64 byte（128 byte）隨機數。

dh-public-num的生成規則為

y2 = g ^ x2 % p

其中g和p是公開的兩個數，其中g等於2，p是一個1024 bits的數，x2是responder隨機生成的數，y2就是在網路中傳輸的dh-public-num。

3.5.3 initiator initial keying

initiator initial keying包的payload格式如下：

payload = initiator-session-id | cookie-echo | initiator-certificate| initiator-component | ‘X’

其中：

l  initiator-session-id：initiator選擇的session-id，responder用它來發送資料給initiator（生成scrambled session id）

l  cookie-echo：和上一個包中的cookie一致

l  initiator-certificate：格式和上面的responder certificate一致

和上述的一樣，這裡的dh-public-num的生成規則如下：

y1 = g ^ x1 % p

其中g和p的定義和上述一致，x1是initiator隨機生成的數，y1就是傳輸的dh-public-num。這時initiator知道了y2和x1，就可以生成sharedsecret：

shared secret = y2 ^ x1 % p

這時就可以生成這個session對應的加解密key了：

decode key = HMAC-SHA256(shared-secret, HMAC-SHA256(responder nonce,initiator nonce))

encode key = HMAC-SHA256(shared-secret, HMAC-SHA256(initiator nonce,responder nonce))

這些加解密key都只使用低位的128bit

l  initiator-component：在DH演算法中使用的initiator nonce。

3.5.4 responder initial keying

responder initial keying的payload的格式如下：

payload = responder session id | responder’s nonce | ‘X’

其中：

l  responder session id：responder生成的session id，initiator用它來生成scrambled session id，這個值和initiator session id不一樣。

l  responder’s nonce：

這時responder知道了y1和x2，就可以生成sharedsecret：

shared secret = y2 ^ x1 % p

DH演算法保證這個responder的sharedsecret和initiator的shared secret是一樣的。

這時就可以生成這個session對應的加解密key了：

encode key = HMAC-SHA256(shared-secret, HMAC-SHA256(responder nonce,initiator nonce))

decode key = HMAC-SHA256(shared-secret, HMAC-SHA256(initiator nonce,responder nonce))

這些加解密key都只使用低位的128bit。

可以看到responder的encode key和initiator的decode key是一樣的，同樣，responder的decode key和initiator的encode key是一樣的。

注意responder initial keying依然使用”Adobe System 02”作為對稱key來加解密，而不是使用新生成的非對稱的key來加解密，非對稱的key僅在session建立之後使用。

3.5.5 user data

至此session就建立好了，後續傳輸的就是資料訊息，主要包括兩類：

l  normal user data：正常的flow中資料訊息

l  next user data：和normal user data在一個packet中傳輸，不能單獨使用。

normal user data包的payload格式如下：

payload = flags | flow-id | seq | forward-seq-offset | options |data

其中：

l  flags：1 byte，各bit的意義如下：

l  flow-id：flow標識，varlen型別

l  forward-seq-offset：用於滑窗的標識，varlen型別

l  options：一些選項

l  data：audio、video和data資料

next user data包的payload格式如下：

payload = flags | data

欄位定義同上