全部博文(135)
2010年(135)
分类:
2010-09-02 18:59:15
RTMP 协议研究
协 议设计和分析一直都是在工作遇到,正好在这里总结一下,说到协议,在这个网络的时代,没有人可以离开它了。他存在我们生活中的任何角落,只不过我们平时, 并没有注意到它的存在,可以这么说如果没有协议,我们生活和日常的工作生产都不能进行。如果仔细想想你生活中用到的所有东西,协议已经包含其中。那到底什 么是协议呢?说的简单一点就是双方达成的共识,以便更好的交流,理论上协议是什么呢?如果学过《信号与系统》的人都知道有个简单的道理,就是信息在经过一 个管道的符号集,到另一个符号集时信息不会丢失。
任何复杂的事物都有个最简单的本质,网络上的协议也是这样,有个最基本的本质。除去上下层的概念,协议就只剩下通信双方实体的规则。
一般的协议都包含最基本的协议头,不管是物理层、链路层、还是网络层,这个头就构成了协议的本质东西。通常协议头要包含以下最基本的三项信息:
其中,前两项是必须要有的,没有他们,通信双方的交互根本得不到保证,第三项在不太灵活的通信中可以去掉,而有第二项的类型推出。
协议的丰富性,有净核的多样性体现。
协议头除了以上的三项,还可以增加更多的信息(比如控制信息、时间信息等),取决于具体的应用。找到这些基本的东西,再去看协议的时候,能够更好的抓住协议的主体进行分析和设计了。
如图 协议物理结构
RTMP 协议是被 Flash 用于对象、视频、音频的传输。该协议建立在 TCP 协议或者轮询 HTTP 协议之上, RTMP 协议就像一个用来装数据包的容器,这些数据可以是 AMF 格式的数据,也可以是 FLV 中的视 / 音频数据。一个单一的连接可以通过不同的通道传输多路网络流,这些通道中的包都是按照固定大小的包传输的 .
struct RTMP_HEAD
{
char cChannelid : 6;// 第一个字节的后 6 位
char cCheadsize ; // 第一个字节的头两位
char cTimer[3]; // 三个字节表示的时间信息
char cLength[3]; // 三个字节表示的长度
char cDatatype; // 数据类型
char sStreamid[4]; // 流标识
};
这里有三个最基本的元素(唯一标示 )、(类型 )和(净核的长度 )分别是: cChannelid 、 cDatatype 和 cLength 。
数据类型 决定了协议上层可以做的具体的事情,和使用协议的人必须遵循的规则。
同时数据类型 说明了净核 的基本内容。
RTMP 数据类型:
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. |
RTMP
的协议净核是用
AMF
格式来描述,
AMF
格式本身的产生就是为了
RTMP
协议服务的,最初的
RTMP
采用
XML
的形式传输数据,但
XML
只是字符形式的值对的格式传输数据,而随着应用的普及这完全不能满足要求了,比如对象、结构、数组,甚至可以是数据集,配合
DataGrid
组件可以很方便地显示数据。
为了处理复杂数据类型,采用一种独有的方式使
Flash
与应用服务器间可以来回传送数据势在必行。于是
AMF
应运而生。
AMF
是
Adobe
独家开发出来的通信协议,它采用二进制压缩,序列化、反序列化、传输数据,从而为
Flash
播放器与
Flash Remoting
网关通信提供了一种轻量级的、高效能的通信方式。如下图所示。
AMF
最大的特色在于可直接将
Flash
内置对象,例如
Object, Array,
Date, XML
,传回服务器端,并且在服务器端自动进行解析成适当的对象,这就减轻了开发人员繁复工作,同时也更省了开发时间。由于
AMF
采用二进制编码,这种方式可以高度压缩数据,因此非常适合用
来传递大量的资料。数据量越大,
Flash Remoting
的传输效能就越高,远远超过
Web
Service
。至于
XML, LoadVars
和
loadVariables()
,它们使用纯文本的传输方式,效能就更不能与
Flash
Remoting
相提并论了。
注意:
Flash Remoting
需要浏览器支持
Binary POST
,
Flash
播放器在
Netscape
6.x.
环境下运行
Flash Remoting
会不起作用(
Flash Remoting
调用没有效果也不返回错误),
Netscape
7
已经纠正了这个
bug
。对于早期
Safari
和
Chimera
版的苹果机也有这个问题。
同样是轻量级数据交换协议,同样是通过调用远程服务,同样是基于标准的
HTTP
和
HTTPS
协议,
Flash Remoting
为什么选择了使用
AMF
而放弃了
SOAP
与
Flash
播放器通信呢 有如下原因:
SOAP
将数据处理成
XML
格式,相对于二进制的
AFM
太冗长了;
AMF
能更有效序列化数据;因为
AMF
的初衷只是为了支持
Flash
ActionScript
的数据类型,而
SOAP
却致力于提供更广泛的用途;
AMF
支持
Flash
播放器
6
只需要浏览器增加
4 KB
左右(压缩后)的大小,而
SOAP
就大多了;
SOAP
的一些头部文件请求在
Flash
播放器
6
不支持。那
Flash
播放器
6
为什么能访问基于
SOAP
的
Web
服务呢?原来
Flash Remoting
网关将
SOAP
请求在服务器端与转换成
AFM
格式,然后利用
AFM
与
Flash
播放器通信。另外,
AMF
包中包含
onResult
事件(比如说
response
事件)和
onStatus
事件(比如说
error
事件),这些事件对象在
Flash
中可以直接使用。
AMF
从
Flash MX
时代的
AMF0
发展到现在的
AMF3
。
AMF3
用作
Flash Playe
9
的
ActionScript 3.0
的默认序列化格式,而
AMF0
则用作旧版的
ActionScript 1.0
和
2.0
的序列化格式。
在网络传输数据方面,
AMF3
比
AMF0
更有效率。
AMF3
能将
int
和
uint
对象作为整数(
integer
)传输,并且能序列化
ActionScript
3.0
才支持的数据类型
,
比如
ByteArray
,
XML
和
Iexternalizable
。
AMF 很好的解决了内容的丰富性。(具体 AMF 格式参考附件格式文档)
AMF0 supports the following data types (with their type field values):
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.
Numbers are stored as 8 byte (big endian) float double. On x86 you can just byteswap a double to encode it correctly.
A boolean is encoded in one byte. FIXME: is true sent as 0xff? 0x01?
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?
A null has zero bytes following the type byte
A undefined has zero bytes following the type byte
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.
This is not really a value, but a marker for the end of an OBJECT. See above.
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.
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.
Flash Player 以系统时间作为种子通过某种算法生成的数字签名,大小是 1537 字节向服务器发起第一次握手,服务器根据客户端的数字签名产生一个 3073 字节的验证包,给客户端,客户端在接受到服务器的回应以后会发送一个 1536 字节的回复。
具体的流程:
第一个握手包 handshark1 和服务器的回复握手包 handshark2 都是以 0X03 开头。这三次握手不是 RTMP 协议本身的内容,所以在这并没有包含 RTMP 的协议头。是服务器的厂家自己产品做验证用的,严格的说就是你必须用 Adobe 的客户端和服务器才能使用我的协议。
具体连接和请求视频的过程
RTMP 的净核决定了内容服务, adobe 的服务器采用的 AMF 格式的字串命令来控制视频的传输和播放,具体的字串命令信息如下:(注:字串的定义有厂家( adobe )自己定义,只要满足 AMF 的格式就可以)
在服务器返回开始播放消息 "NetStream.Play.Start" 之后,服务器就会开始给客户端传输数据了,一般数据的萃取都是先解析协议的头,然后根据协议头中数据类型和净核长度就可以把数据部分取出, RTMP 协议也是这样。
struct RTMP_HEAD
{
char cChannelid : 6;// 第一个字节的后 6 位
char cCheadsize ; // 第一个字节的头两位
char cTimer[3]; // 三个字节表示的时间信息
char cLength[3]; // 三个字节表示的长度
char cDatatype; // 数据类型
char sStreamid[4]; // 流标识
}
首先判断 cDatatype 是那种类型,然后根据不同的类型进行萃取数据部分,进行不同的处理,获取视频的数据的方式先看是否是一下的类型:
0×08 | Audio Data | packet containing audio |
0×09 | Video Data | packet containing video data |
根据净核的长度读取出内存中的音视频数据,这里的音视频数据是有一定编码格式的数据,这个取决于应用的具体配置,
Flash play
使用的是
FLV
的格式。要对这部分数据进行存取,还有做一部分工作,对
FLV
的视频数据进行去壳,取出数据保存文件就可以了。