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。
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,839评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,543评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,116评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,371评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,384评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,111评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,416评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,053评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,558评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,756评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,324评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2 345

推荐阅读更多精彩内容

  • RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写,它是由Adobe公司...
    iOS小肖阅读 3,471评论 0 4
  • RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写,它是由Adobe公司...
    日月当头阅读 39,547评论 6 67
  • 本文转自://www.greatytc.com/p/b2144f9bbe28 RTMP协议是Real T...
    pandazhong阅读 359评论 0 0
  • 一、RTMP 协议简介 RTMP(Real-Time Messaging Protocol),译为:实时消息传输协...
    村口大白杨阅读 896评论 0 1
  • RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写,它是由Adobe公司...
    我是李小胖阅读 1,261评论 0 0