RTMP协议抓包分析拉流过程

基本概念：

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

播放一个RTMP协议的流媒体需要经过四个阶段：

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

下面是使用librtmp执行拉流过程的API调用流，如下：

image.png

抓包分析：

RTMP定义了较为完善的协议标准，但是每种播放工具的实现略有差异，下面是我使用VLC播放器拉流时抓取的报文，使用wireshark分析过程整理为下面的图文。

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

image.png

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

握手阶段：

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

image.png

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

建立连接阶段：

包括以下报文和步骤：

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

客户端发起连接请求：

协议截图如下：

image.png

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 0
     CSID: 3
     时间戳：0
     BodySize: 201
     TypeID: 0x14
     Stream ID: 0
负载格式：AMF0表示，connect 1 object1
     object1属性列表：
          "app": "live"
          "flashVer": "LNX 9,0,124,2"
          "tcUrl": "rtmp://127.0.0.1:1935/live"
          "fpad": false
          "capabilities": 15,
          "audioCodes": 4071,
          "videoCodes": 252,
          "videoFunction": 1,
          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: 0x05
     Stream ID: 0
负载格式：4字节整型表示，如5000000

建立流阶段：

包括以下报文和步骤：

1. 客户端发起创建流请求
2. 服务器响应创建流结果

客户端发起创建流请求：

协议截图如下：

image.png

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

服务器响应创建流结果：

协议截图如下：

image.png

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

播放阶段：

包括以下报文和步骤：

1. 客户端发起播放节目请求
2. 客户端通知服务器设置缓冲区大小
3. 服务器通知客户端启动流
4. 服务器通知客户端流进入播放状态
5. 服务器向客户端发送媒体元数据
6. 服务器向客户端发送媒体数据

客户端发起播放节目请求：

协议截图如下：

image.png

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 0
     CSID: 8
     时间戳：0
     BodySize: 30
     TypeID: 0x14
     Stream ID: 1
负载格式：AMF0表示，play 4 Object(Null) String节目ID("a") Number开始时间(-2000)

客户端通知服务器设置缓冲区大小：

协议截图如下：

image.png

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 1
     CSID: 2
     时间戳：1
     BodySize: 10
     TypeID: 0x04
负载格式：Event Type，2字节的类型(3) 4字节的流ID(1) 4字节的MS时间单位(3000)

服务器通知客户端启动流：

协议截图如下：

image.png

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 6
     TypeID: 0x04
负载格式：Event Type，2字节的类型(0) 4字节的流ID(1)

服务器通知客户端流进入播放状态：

协议截图如下：

image.png

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

服务器向客户端发送媒体元数据：

协议截图如下：

image.png

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 5
     时间戳：0
     BodySize: 387
     TypeID: 0x12
     Stream ID: 1
负载格式：AMF0表示，onMetaData object
     object属性列表：
          "Server": "NGINX RTMP"
          "width": 480,
          "height": 270,
          "displayWidth": 480,
          "displayHeight": 270,
          "duration": 0,
          "framerate": 16,
          "fps": 16,
          "videodatarate": 193,
          "videocodeid": 7,
          "audiodatarate": 52,
          "audiocodeid": 10,
          "profile": "",
          "level": "",
          End Of Object Marker

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

协议截图如下：

image.png

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

流程时序：

结合以上分析，总结时序图如下：

拉流时序.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(createStream) HeaderType: 1 CSID: 3
0x14(createStream _result) HeaderType: 0 CSID: 3
0x14(play) HeaderType: 0 CSID: 8
0x04(SetBufferMS) HeaderType: 1 CSID: 2
0x04(Stream Begin) HeaderType: 0 CSID: 2
0x14(play onStatus) HeaderType: 0 CSID: 5
0x12(onMetaData) HeaderType: 0 CSID: 5
0x08(audioData) HeaderType: 0 CSID: 6
0x09(videoData) HeaderType: 0 CSID: 7

总结：
关于HeaderType的运用，有以下规则：
createStream使用1号HeaderType，借用3号CSID之前的StreamID。
SetBufferMS使用1号HeaderType。
audioData和videoData视情况使用0、1、2、3号HeaderType。
关于CSID的运用，有以下规则：

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