[c#]实现fms服务器,rtmp协议破解(2),数据包详解
1、握手
Client->Server:Sends Handshake Request. This is not a protocol packet but a single byte (0×03) followed by 1536 bytes. There is a counter which goes up, so it seems to be the clients uptime (time since system started).
Server -> Client : Sends a Handshake Response. This is not a RTMP packet but a single byte (0×03) followed by two 1536 byte chunks (so a total of 3072 raw bytes). The second chunk of bytes is the original client request bytes sent in handshake request. The first chunk can be anything. Use null bytes it doesnt seem to matter.
Client -> Server: Sends 1536 raw bytes which are the second 1536 chunk of server generated handshake.
到此为止,连接成功建立.接下来的为协议数据流。
2、协议数据
协议可以理解为由3部分组成
[协议头],[协议体],[协议数据]
协议头,1byte
其中前两位标示协议头长,它可能为以下的四种组合
0x00 -->头长12,完整头,标示新流
0x01 -->头长8
0x10 -->头长4
0x11 -->头长1
(注,此处头长包括此头本身)
后六位表示流的全局唯一id,red5将其理解为channel,因为有时音频和视频数据会同时传递,所以不同的流是可以交替的。最大同步流可能64.
一个完整的协议体(包括头),应该是12byte长
1 2 3 4 5 6 7 8 9 10 11 12
其中1号位的解释见上
2-4号位 unknow,据red5解释,其为时间相关。
5-7号位 标示了AMF体的长度,就是协议数据的长度。这儿需要说明下,流体最大为128的chunk,如果大于这个数值,将会被分包,但是有且仅有一个12位完整头描述了完整体的大小。
8号位 AMF对象类型,它可能为以下所示:
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.
9-12号位定义了AMF的来源和目的,详见下图分析:
Client->Server:Sends Handshake Request. This is not a protocol packet but a single byte (0×03) followed by 1536 bytes. There is a counter which goes up, so it seems to be the clients uptime (time since system started).
Server -> Client : Sends a Handshake Response. This is not a RTMP packet but a single byte (0×03) followed by two 1536 byte chunks (so a total of 3072 raw bytes). The second chunk of bytes is the original client request bytes sent in handshake request. The first chunk can be anything. Use null bytes it doesnt seem to matter.
Client -> Server: Sends 1536 raw bytes which are the second 1536 chunk of server generated handshake.
到此为止,连接成功建立.接下来的为协议数据流。
2、协议数据
协议可以理解为由3部分组成
[协议头],[协议体],[协议数据]
协议头,1byte
其中前两位标示协议头长,它可能为以下的四种组合
0x00 -->头长12,完整头,标示新流
0x01 -->头长8
0x10 -->头长4
0x11 -->头长1
(注,此处头长包括此头本身)
后六位表示流的全局唯一id,red5将其理解为channel,因为有时音频和视频数据会同时传递,所以不同的流是可以交替的。最大同步流可能64.
一个完整的协议体(包括头),应该是12byte长
1 2 3 4 5 6 7 8 9 10 11 12
其中1号位的解释见上
2-4号位 unknow,据red5解释,其为时间相关。
5-7号位 标示了AMF体的长度,就是协议数据的长度。这儿需要说明下,流体最大为128的chunk,如果大于这个数值,将会被分包,但是有且仅有一个12位完整头描述了完整体的大小。
8号位 AMF对象类型,它可能为以下所示:
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.
9-12号位定义了AMF的来源和目的,详见下图分析: