RTMP协议抓包分析推流过程

基本概念:

RTMP协议规定,发布一个流媒体有两个前提步骤:
第一步,建立一个网络连接(NetConnection)。
第二步,建立一个网络流(NetStream)。
网络连接代表服务器端应用程序和客户端之间基础的连通关系,网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接,但是基于该连接可以创建很多网络流。

发布一个RTMP协议的流媒体需要经过四个阶段:

  1. 握手阶段
  2. 建立连接阶段
  3. 建立流阶段
  4. 推流阶段
    RTMP连接都是以握手作为开始的,建立连接阶段用于建立客户端与服务器之间的“网络连接”。
    建立流阶段用于建立客户端与服务器之间的“网络流”。
    推流阶段用于传输视音频数据。

下面是使用librtmp执行推流过程的API调用流,如下:


image.png

抓包分析:

RTMP定义了较为完善的协议标准,遵循规范,我们可以使用合适的工具进行推流,但是由于有些操作是可选的,因而抓包过程又略有差异,下面是我使用ffmpeg工具推流时抓取的报文,使用wireshark分析过程整理为下面的图文。

先看一张总览图,图中显示的报文和时序包含了握手、建立连接、建立流和推流阶段,如下:


image.png

还有申明下,以下的流程是根据实际抓包情况分析出来的,由于不同的工具省略了一些不必要的步骤,故不代表标准结果,仅供参考。

握手阶段:

由于讲解握手过程的文档资料比较多,我这里就不重复描述了,摘图如下:


image.png

个人认为这张图是最符合标准时序的,细节拿捏得非常讲究,虽然很多实现简化了流程。

建立连接阶段:

包括以下报文和步骤:

  1. 客户端发起连接请求
  2. 服务器设置客户端的应答窗口大小
  3. 服务器设置客户端的发送带宽大小
  4. 服务器设置客户端的接收块大小
  5. 服务器响应连接结果
  6. 客户端设置服务器的接收块大小
客户端发起连接请求:

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 0
     CSID: 3
     时间戳:0
     BodySize: 143
     TypeID: 0x14
     Stream ID: 0
负载格式:AMF0表示,connect 1 object1
     object1属性列表:
          "app": "live"
          "type": "nonprivate"
          "flashVer": "LNX 9,0,124,2"
          "tcUrl": "rtmp://127.0.0.1:1935/live"
          End Of Object Marker

服务器设置客户端的应答窗口大小:

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 2
     时间戳:0
     BodySize: 4
     TypeID: 0x05
     Stream ID: 0
负载格式:4字节整型表示,如5000000

服务器设置客户端的发送带宽大小:

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 2
     时间戳:0
     BodySize: 5
     TypeID: 0x06
     Stream ID: 0
负载格式:5字节整型表示,前4字节为带宽,后1字节为标志,如5000000, 2(动态调整)

服务器设置客户端的接收块大小:

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 2
     时间戳:0
     BodySize: 4
     TypeID: 0x01
     Stream ID: 0
负载格式:4字节整型表示,如4096

服务器响应连接结果:

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 3
     时间戳:0
     BodySize: 190
     TypeID: 0x14
     Stream ID: 0
负载格式:AMF0表示,_result 1 object1 object2
     object1属性列表:
          "fmsVer": "FMS/3,0,1,123"
          "capabilities": 31,
          End Of Object Marker
     object2属性列表:
          "level": "status"
          "code": "NetConnection.Connect.Success",
          "description": "Connection succeeded.",
          "objectEncoding": 0
          End Of Object Marker

客户端设置服务器的接收块大小:

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 0
     CSID: 2
     时间戳:0
     BodySize: 4
     TypeID: 0x01
     Stream ID: 0
负载格式:4字节整型表示,如4096

建立流阶段:

包括以下报文和步骤:

  1. 客户端通知服务器释放推流点
  2. 客户端通知服务器准备推流点
  3. 客户端发起创建流请求
  4. 服务器响应创建流结果
客户端通知服务器释放推流点

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 1
     CSID: 3
     时间戳:0
     BodySize: 30
     TypeID: 0x14
负载格式:AMF0表示,releaseStream 2 object(Null) String("a")

客户端通知服务器准备推流点

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 1
     CSID: 3
     时间戳:0
     BodySize: 26
     TypeID: 0x14
负载格式:AMF0表示,FCPublish 3 object(Null) String("a")

客户端发起创建流请求:

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 1
     CSID: 3
     时间戳:0
     BodySize: 25
     TypeID: 0x14
负载格式:AMF0表示,createStream 4 object(Null)

服务器响应创建流结果:

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 3
     时间戳:0
     BodySize: 29
     TypeID: 0x14
     Stream ID: 0
负载格式:AMF0表示,_result 4 object(Null) Number(1)

推流阶段:

包括以下报文和步骤:

  1. 客户端发起创建绑定推流点请求
  2. 服务器响应创建绑定推流点结果
  3. 客户端向服务器设置媒体元数据
  4. 客户端向服务器推送媒体数据

完成推推后,还包括以下报文和步骤:

  1. 客户端通知服务器解绑释放推流点请求
  2. 客户端发起删除流请求
  3. 服务器响应解绑释放推流点和删除流结果
客户端发起创建绑定推流点请求

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 0
     CSID: 8
     时间戳:0
     BodySize: 31
     TypeID: 0x14
     Stream ID: 1
负载格式:AMF0表示,publish 5 Object(Null) String节目ID("a") String("live")

服务器响应创建绑定推流点结果

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 5
     时间戳:0
     BodySize: 105
     TypeID: 0x14
     Stream ID: 1
负载格式:AMF0表示,onStatus 0 Object1(Null) object2
     object2属性列表:
          "level": "status"
          "code": "NetStream.Publish.Start",
          "description": "Start publishing",
          End Of Object Marker

客户端向服务器设置媒体元数据

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 0
     CSID: 4
     时间戳:0
     BodySize: 387
     TypeID: 0x12
     Stream ID: 1
负载格式:AMF0表示,@setDataFrame "onMetaData" ECMAarray
     ECMAarray属性列表:
          "duration": 0,
          "width": 480,
          "height": 270,
          "videodatarate": 195.3125,
          "framerate": 16,
          "videocodeid": 2,
          "audiodatarate": 62.5,
          "audiosamplerate": 44100,
          "audiosamplesize": 16,
          "stereo": false,
          "audiocodeid": 2,
          "major_brand": "isom",
          "minor_version": "512",
          "compatible_brands": "isomiso2avc1mp41",
          "encoder": "Lavf59.8.100",
          "filesize": 0,
          End Of Object Marker

客户端向服务器推送媒体数据

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 0
     CSID: 4
     时间戳:0
     BodySize: 209
     TypeID: 0x08
     Stream ID: 1
负载格式:格式头,媒体数据

客户端通知服务器解绑释放推流点请求

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 1
     CSID: 3
     时间戳:0
     BodySize: 28
     TypeID: 0x14
负载格式:AMF0表示,FCUnpublish 6 object(Null) String("a")

客户端发起删除流请求

协议截图如下:


image.png

协议方向:客户端 -> 服务器
块头字段:
     HeaderType: 1
     CSID: 3
     时间戳:0
     BodySize: 34
     TypeID: 0x14
负载格式:AMF0表示,deleteStream 7 object(Null) Number(1)

服务器响应解绑释放推流点和删除流结果

协议截图如下:


image.png

协议方向:服务器 -> 客户端
块头字段:
     HeaderType: 0
     CSID: 5
     时间戳:0
     BodySize: 108
     TypeID: 0x14
     Stream ID: 1
负载格式:AMF0表示,onStatus 0 Object1(Null) object2
     object2属性列表:
          "level": "status"
          "code": "NetStream.Unpublish.Start",
          "description": "Stop publishing",
          End Of Object Marker

流程时序:

结合以上分析,总结时序图如下:


RTMP推流流程.png

另外,关于HeaderType和CSID的运用,先归纳使用情况:
0x14(connect) HeaderType: 0 CSID: 3
0x05(Ack Window Size) HeaderType: 0 CSID: 2
0x06(BrandWidth) HeaderType: 0 CSID: 2
0x01(ChunkSize) HeaderType: 0 CSID: 2
0x14(connect _result) HeaderType: 0 CSID: 3
0x14(releaseStream) HeaderType: 1 CSID: 3
0x14(FCPublish) HeaderType: 1 CSID: 3
0x14(createStream) HeaderType: 1 CSID: 3
0x14(createStream _result) HeaderType: 0 CSID: 3
0x14(publish) HeaderType: 0 CSID: 8
0x14(publish onStatus) HeaderType: 0 CSID: 5
0x12(onMetaData) HeaderType: 0 CSID: 4
0x08(audioData) HeaderType: 0 CSID: 4
0x09(videoData) HeaderType: 0 CSID: 6
0x14(FCUnpublish) HeaderType: 1 CSID: 3
0x14(deleteStream) HeaderType: 1 CSID: 3
0x14(deleteStream onStatus) HeaderType: 0 CSID: 5

总结:
关于HeaderType的运用,有以下规则:
releaseStream、FCPublish、createStream、FCUnpublish、deleteStream使用1号HeaderType,借用3号CSID之前的StreamID。
audioData和videoData视情况使用0、1、2、3号HeaderType。
关于CSID的运用,有以下规则:

  1. 0x01~0x06命令用2号CSID。
  2. 大部分0x14命令用3号CSID,但有例外,如publish用8号CSID,publish onStatus用5号CSID。
  3. 0x12媒体元数据用4号CSID。
  4. 0x08音频数据用4号CSID。
  5. 0x09视频数据用6号CSID。

经与拉流对比,发现CSID的使用没有明显的约束规则,如果某类数据需要压缩头部,建议使用相同的CSID。

你可能感兴趣的:(RTMP协议抓包分析推流过程)