flashP2P協(xié)議rtmfp解析
1 協(xié)議介紹
Real-Time Media Flow Protocol(簡(jiǎn)稱RTMFP)是Flash和Flash之間基于UDP的點(diǎn)對(duì)點(diǎn)傳輸協(xié)議，由Adobe公司在2008年在Flash 10.0中發(fā)布，隨后在Flash10.1中加入了Groups功能。
2 常見用法
rtmfp在Flash 10中的典型使用場(chǎng)景如下圖：
它有如下特點(diǎn)：
l 使用Cirrus或者開源的Cumulus來提供Rendezvous服務(wù)
l Cirrus或者Cumulus并不提供Peer ID的交換服務(wù)，需要提供其它的方式來交換客戶端之間的Peer ID
l Flash客戶端之間使用NetStream來做點(diǎn)對(duì)點(diǎn)傳輸，Publisher需要給每一個(gè)Subscriber單獨(dú)傳輸一份數(shù)據(jù)，這也限制集群的規(guī)模。
為了解決這個(gè)問題，Adobe在Flash 10.1中提出了Groups的概念，典型的架構(gòu)如下：
它有如下特點(diǎn)：
l Cirrus或者開源的Cumulus提供Rendezvous服務(wù)并提供所有連接client列表
l client從Cirrus或者開源的Cumulus獲取鄰居節(jié)點(diǎn)之后，就可以組成一個(gè)完整的P2P架構(gòu)，所有的audio、video和data數(shù)據(jù)都在peer之間交互。
3 協(xié)議解析
3.1 基本概念
l session：session是兩個(gè)UDP地址之間的雙向管道。
l flow：flow是從一個(gè)實(shí)體到另一個(gè)實(shí)體之間的邏輯路徑。一個(gè)session可以包括多個(gè)flow。
l packet：網(wǎng)絡(luò)中實(shí)際傳輸?shù)臄?shù)據(jù)，一個(gè)packet可以包含多個(gè)message。數(shù)據(jù)傳輸時(shí)都經(jīng)過了128 bit的AES加密
l message：audio、video和data數(shù)據(jù)。
3.2 Scrambled Session ID
rtmfp協(xié)議中每個(gè)包的格式如下：
packet := scrambled-session-id | encrypted-part
其中scrambled-session-id是4字節(jié)，其后是經(jīng)過AES加密的數(shù)據(jù)體。
scramble-session-id的生成規(guī)則如下：
scrambled-session-id = a ^ b ^ c
這里^代表XOR操作，a是session-id，b和c是encrypted-part的頭8個(gè)bytes。
當(dāng)目標(biāo)收到這個(gè)包后，unscramble的操作如下：
session-id = x ^ b ^ c
其中x是scrambled-session-id，b和c同上。
使用scramble-session-id的目的為了減少數(shù)據(jù)包流經(jīng)的NAT設(shè)備和layer-4 packet inspector對(duì)數(shù)據(jù)的干擾。
session-id用于標(biāo)識(shí)通信雙方建立的連接，并確定通信時(shí)使用的加密和解密的key，這些key是通過DH key exchange算法獲得。但在session建立之前，雙方使用一個(gè)公有加密key，即128 bit的字符串”Adobe System 02”。
3.3 raw part
encrypted-part經(jīng)過解密之后就得到了raw-part，它的格式如下：
raw-part := checksum | network-layer-data | padding
其中checksum有16字節(jié)，network-layer-data是變長(zhǎng)數(shù)據(jù)，padding都是0xFF，并把network-layer-data補(bǔ)齊為16字節(jié)的倍數(shù)，這是因?yàn)閞tmfp使用的是16字節(jié)的加解密key。
checksum基于network-layer-data和padding計(jì)算。
3.4 network layer data
network-layer-data的格式如下：
network-layer-data = flags | timestamp | timestamp-echo | chunks
其中flags為1個(gè)字節(jié)，其格式如下：
7 6 5 4 3 2 1 0
TC TCR reserved reserved TS TSE mode
l mode：11代表握手包，01代表initiator發(fā)送包，10代表responder發(fā)送包，00不是合法值
l TSE：包中是否包含timestamp-echo域
l TS：包中是否包含timestamp域
l TCR：time critical reverse notification表明發(fā)送方正在從其它地方收到timecritical包
l TC：time critical forward notification表明發(fā)送方發(fā)送的是timecritical包
timestamp域有2字節(jié)，精度是4ms，他的計(jì)算方式如下：
timestamp = int(time * 1000 / 4) & 0xFFFF
timestamp-echo域是server收到包的時(shí)間戳，當(dāng)發(fā)送放收到這個(gè)值之后，發(fā)送方就可以計(jì)算RTT值了。
chunk類型的格式如下：
chunk = type | size | payload
type字段為1個(gè)字節(jié)，其中0xFF不可用，這個(gè)是用來區(qū)分chunk數(shù)據(jù)和padding數(shù)據(jù)的標(biāo)記。type的定義如下：
typemeaning
0x30initiator hello
0x70responder hello
0x38initiator initial keying
0x78responder initial keying
0x0fforwarded initiator hello
0x71forwarded hello response
0x10normal user data
0x11next user data
0x0csession failed on client side
0x4csession died
0x01reset keepalive request
0x41reset keepalive response
0x5enegative ack
0x51some ack
size是2字節(jié)payload長(zhǎng)度。
payload根據(jù)type的不同有不同的數(shù)據(jù)體。
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就作為一個(gè)forwarder，他會(huì)把initiatro hello包轉(zhuǎn)發(fā)到其它的client：
另外，cumulus server還可以讓client重定向到其它server：
這里所說的client是Flash Player，而server是cumulus server或者Flash media server。當(dāng)然server也可以給client發(fā)送initiator hello請(qǐng)求，這個(gè)在cumulus中被稱為man in the middle，不過這個(gè)特性還不穩(wěn)定。
session的建立包括4次握手：
1 initiator -> target:initiator hello
2 target -> initiator: responder hello
3 initiator -> target:initiator initial keying
4 target -> initiator: responder initial keying
這個(gè)4次握手過程可以阻止Dos攻擊和syn-flooding攻擊。
每個(gè)session都有一個(gè)session-id來唯一標(biāo)識(shí)這個(gè)session，并且session中的每個(gè)packet都會(huì)包含這個(gè)session-id，但是在session建立的4個(gè)握手包中，initiator-hello, responder hello和initiator initialkeying的session-id字段都是0，在發(fā)送最后一個(gè)包responder initial keying時(shí)，session建立成功并且session-id確定，所以responderinitial keying包含合法的session-id。
我們接下來詳細(xì)介紹一下這4個(gè)握手包
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，只有兩個(gè)合法值：
n 0x0a：client-server模式，epd value是想要連接的server的rtmfp url
n 0x0f：peer-to-peer模式，epd value是想要連接的client的peer id，一般是固定的32字節(jié)
l epd value：varlen + body
l tag：16 bytes隨機(jī)數(shù)
3.5.2 responder hello
responder hello包的payload格式如下：
responder hello payload = tag-echo | cookie | responder-certificate
其中：
l tag-echo：和initiator hello中的`tag一致，但和initiator hello中不同的是，這里在前面有一個(gè)varlen來表明tag的長(zhǎng)度
l cookie：responder產(chǎn)出的64 bytes隨機(jī)數(shù)，用來防止syn-flooding攻擊
l responder certificate：diffie-hellman key exchange算法交換的信息，它的格式如下：
certificate= x01x0Ax41x0E | dh-public-num | x02x15x02x02x15x05x02x15x0E
dh-public-num是一個(gè)64 byte(128 byte)隨機(jī)數(shù)。
dh-public-num的生成規(guī)則為
y2 = g ^ x2 % p
其中g(shù)和p是公開的兩個(gè)數(shù)，其中g(shù)等于2，p是一個(gè)1024 bits的數(shù)，x2是responder隨機(jī)生成的數(shù)，y2就是在網(wǎng)絡(luò)中傳輸?shù)膁h-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用它來發(fā)送數(shù)據(jù)給initiator(生成scrambled session id)
l cookie-echo：和上一個(gè)包中的cookie一致
l initiator-certificate：格式和上面的responder certificate一致
和上述的一樣，這里的dh-public-num的生成規(guī)則如下：
y1 = g ^ x1 % p
其中g(shù)和p的定義和上述一致，x1是initiator隨機(jī)生成的數(shù)，y1就是傳輸?shù)膁h-public-num。這時(shí)initiator知道了y2和x1，就可以生成sharedsecret：
shared secret = y2 ^ x1 % p
這時(shí)就可以生成這個(gè)session對(duì)應(yīng)的加解密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，這個(gè)值和initiator session id不一樣。
l responder’s nonce：
這時(shí)responder知道了y1和x2，就可以生成sharedsecret：
shared secret = y2 ^ x1 % p
DH算法保證這個(gè)responder的sharedsecret和initiator的shared secret是一樣的。
這時(shí)就可以生成這個(gè)session對(duì)應(yīng)的加解密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”作為對(duì)稱key來加解密，而不是使用新生成的非對(duì)稱的key來加解密，非對(duì)稱的key僅在session建立之后使用。
3.5.5 user data
至此session就建立好了，后續(xù)傳輸?shù)木褪菙?shù)據(jù)消息，主要包括兩類：
l normal user data：正常的flow中數(shù)據(jù)消息
l next user data：和normal user data在一個(gè)packet中傳輸，不能單獨(dú)使用。
normal user data包的payload格式如下：
payload = flags | flow-id | seq | forward-seq-offset | options |data
其中：
l flags：1 byte，各bit的意義如下：
bitmeaning
0x80options域是否存在
0x40
0x20這個(gè)包前面還有包
0x10這個(gè)包后面還有包
0x08
0x04
0x02丟棄包
0x01結(jié)束包
l flow-id：flow標(biāo)識(shí)，varlen類型
l forward-seq-offset：用于滑窗的標(biāo)識(shí)，varlen類型
l options：一些選項(xiàng)
l data：audio、video和data數(shù)據(jù)
next user data包的payload格式如下：
payload = flags | data
【flashP2P協(xié)議rtmfp解析】相關(guān)文章：
地址解析協(xié)議的相關(guān)知識(shí)10-19
成王敗寇成語(yǔ)解析04-02
兔起鳧舉成語(yǔ)解析03-29
天高聽卑成語(yǔ)解析03-28
視人如傷成語(yǔ)解析03-26
局高蹐厚成語(yǔ)解析03-26
夕寐宵興成語(yǔ)解析03-26
頹垣敗井成語(yǔ)解析03-26
相鼠有皮成語(yǔ)解析03-25