Rtmp协议简单分析(二)——协议交互过程

具体传输的过程是这样的,首先双方先进行握手,握手过程官方文档上有说明,但是在flash10.1之后,adobe公司改了握手,文档上那个握手不能用了,至少播放AVC和ACC不能用,这东西太坑人了,改了又不说一声,而且一个本来简单的握手改的很是复杂,居然要依赖openssl加密,有必要吗。网上找不到有关文章,我只有看rtmpserver开源项目源码来弄。

       握手步骤没有变,但内容完全不一样,以前叫sample handshake,现在叫复杂握手(complex handshake)。

它的步骤是由三个固定大小的块组成,而不是可变大小的块加上头。握手开始于客户端发送C0C1块。在发送C2之前客户端必须等待接收S1。在发送任何数据之前客户端必须等待接收S2服务端在发送S0S1之前必须等待接收C0,也可以等待接收C1。服务端在发送S2之前必须等待接收C1。服务端在发送任何数据之前必须等待接收C2

网上有一个人说出了complex handshake的方式,http://blog.csdn.net/winlinvip/article/details/7714493,以下是他的说明:Rtmp协议简单分析(二)——协议交互过程_第1张图片

scheme1和scheme2这两种方式,是包结构的调换。
Rtmp协议简单分析(二)——协议交互过程_第2张图片

 keydigest的主要算法是:C1key128bytes随机数。C1_32bytes_digest = HMACsha256(P1+P2, 1504, FPKey, 30) ,其中P1digest之前的部分,P2digest之后的部分,P1+P2是将这两部分拷贝到新的数组,共1536-32长度。S1key根据C1key算出来,算法如下:Rtmp协议简单分析(二)——协议交互过程_第3张图片

 在Rtmpserver的sources\thelib\src\protocols\rtmp\inboundrtmpprotocol.cpp中有握手的代码,看他的说明也马马虎虎,我也看源码后才清楚具体过程。具体过程和他说的差不多,只是有些计算要用到openssl加密,所以要安装openssl,我也是从rtmpserver上面扣出来的代码然后自己改一下。

 

       握手之后就开始一些交互信令,这个如果按照文档上的来,根本不行,文档上省略的一些东西,坑人。

       我的交互过程是按照抓的FMS3.5的包来做的。握手之后首先client会发送一个connect消息过来。另外,RTMP交互的消息格式官方说明上有,还是比较清楚的。

字段名

类型

描述

命令名

字符串

命令名。设置为”connect”

传输ID

数字

总是设为1

命令对象

对象

含有名值对的命令信息对象

可选的用户变量

对象

任何可选信息

   下面是在连接命令的命令对象中使用的名值对的描述:

属性

类型

描述

示例值

App

字符串

客户端要连接到的服务应用名

Testapp

Flashver

字符串

Flash播放器版本。和应用文档中getversion()函数返回的字符串相同。

FMSc/1.0

SwfUrl

字符串

发起连接的swf文件的url

file://C:/ FlvPlayer.swf

TcUrl

字符串

服务url。有下列的格式。protocol://servername:port/appName/appInstance

rtmp://localhost::1935/testapp/instance1

fpad

布尔值

是否使用代理

true or false

audioCodecs

数字

指示客户端支持的音频编解码器

SUPPORT_SND_MP3

videoCodecs

数字

指示支持的视频编解码器

SUPPORT_VID_SORENSON

pageUrl

字符串

SWF文件被加载的页面的Url

http:// somehost/sample.html

objectEncoding

数字

AMF编码方法

kAMF3

 Rtmp协议简单分析(二)——协议交互过程_第4张图片

上图中app的vod就是请求文件的路径。

表示使用amf0编码格式传输命令,如果是3就是表示用amf3。

 

之后server回复windows acknowledgement size-    set peer bandwidth- user control message(begin 0)- result(connect response)

Rtmp协议简单分析(二)——协议交互过程_第5张图片

User control message (用户控制信息)的格式官方文档上有,消息数据的头两个字节用于标识事件类型,0表示Stream Begin。事件类型之后是事件数据。事件数据字段是可变长的,此时的数据时00

 Rtmp协议简单分析(二)——协议交互过程_第6张图片

在发送了windows acknowledgement size之后client会回一个windows adknowledgement size此时需要接收

然后server接收client发的一个create stream过来
Rtmp协议简单分析(二)——协议交互过程_第7张图片

接收到之后server返回一个_result
Rtmp协议简单分析(二)——协议交互过程_第8张图片

Server接收client发来的recv set buffer length - play commcand from

字段名 类型 描述
命令名 字符串 命令名,设为”play”
传输ID 数字 设置为0
命令对象 NULL 命令信息不存在,设为NULL类型
流名 字符串 要播放的流名。对于播放一个FLV文件,则流名不带文件后缀(例如,"sample”)。对于回放MP3或ID3标签,必须在流名前加MP3(例如:”MP3:Sample”)。对于播放H264/AAC文件,必须在流名前加MP4前缀,并且指定扩展名,例如播放sample.m4v,则指定”mp4:sample.m4v”。
开始 数字 一个指定开始时间的可选参数。默认值是-2,意味着用户首先尝试播放流名中指定的直播流。如果流名字段中指定的直播流不存在,则播放同名的录制流。如果本字段设置为-1,则只播放流名字段中指定的直播流。如果,本字段为0,或正值,则在本字段指定的时间,播放流名字段中指定的录制流。如果指定的录制流不存在,则播放播放列表中的下一项。
时长 数字 指定播放时长的可选字段。默认值是-1。-1意味着播放一个直播流,直到没有数据可以活到,或者播放一个录制流知道结束。如果本字段位0,则播放一个录制流中从start字段中指定的时间开始的单个帧。假设,start字段中指定的是大于或等于0的值。如果本字段为正值,则以本字段中的值为时间周期播放直播流。之后,则以时长字段中指定的时间播放录制流?。(如果一个流在时长字段中指定的时间之前结束,则回放结束。)。如果传递一个非-1的负值,则把值当作-1。
Reset 布尔值 指定是否刷新先前的播放列表的BOOL值或数值。

 Rtmp协议简单分析(二)——协议交互过程_第9张图片

Client发的play命了中包含的请求的文件名,上图是1(string ‘1’ 这个数据)。

 

然后server发送set chunk size - user control message(stream is recorded) - onstatus-play reset (AMF0 Command) - user control message(begin1) - onstatus-play start (AMF0 Command) - RtmpSampleAccess (AMF0 Data) 空audio数据 - onstatus-data start (AMF0 Data)

Rtmp协议简单分析(二)——协议交互过程_第10张图片

Rtmp协议简单分析(二)——协议交互过程_第11张图片

 Set chunk size这里就是改默认128字节的消息,这里改成了4096,当然也可以不发次消息。注意,在改之前发送的消息如果超过了128bytes都要分块发送的之后就可以每块大小事4096了。

Begin这里,这个前2bytes是0,表示stream begin,和上面的begin是个类型,只是数据段是1,这个抓包有点问题,没有显示数据段而已,此begin 1之后,所有的包头里面的streamID都是1了,之前的都是0

字段 类型 描述
命令名 字符串 命令名。如果播放成功,则命令名设为响应状态。
描述 字符串 如果播放命令成功,则客户端从服务端接收NetStream.Play.Start状态响应消息。如果指定的流没有找到,则接收到NetStream.Play.StreamNotFound响应状态消息。

 

这里的加载amf数据和解析amf数据(也就是交互的消息)可以用我写的一个amf0的解析模块来做。Rtmp协议简单分析(二)——协议交互过程_第12张图片

然后就发送flv的元数据(metadata)了,如果没有也可以不发这个。之后再发音视频的配置信息项。最后就可以发送音视频数据了。

发送音视频数据的时候可以用以前的方式发:包头的AMFType是8或者9,数据是flv的 tag data(没有tag header)

Rtmp协议简单分析(二)——协议交互过程_第13张图片

也可以按照新的类型amf type为0x16,数据就是一个tag (header + data)来发。

 要注意下就是rtmp都是大端模式,所以发送数据,包头、交互消息都要填成大端模式的,但是只有streamID是小端模式,这个也是文档没有说明,rtmp坑人的地方。


参考资料:
1、rtmp协议简单解析以及用其发送h264的flv文件

你可能感兴趣的:(rtmp)