理解RTMP协议——握手连接

本文梳理了理解RTMP协议的基本概念
访问我的博客了解更多

RTMP 的通信机制

rtmp 客户端与服务端通信的机制

下图是播放器与 rtmp 服务端通信的例子

另外推荐阅读 nginx-rtmp-module 源码，比如，握手协议相关代码在 ngx_rtmp_handshake.c 文件

RTMP 的握手连接的例子

step 1, tcp 三次握手

TCP 握手过程这里不详细展开，参考这篇文章 TCP 的那些事儿

step 2, RTMP 握手验证

RTMP 握手起到验证的作用，RTMP 握手方式主要分为：简单握手与复杂握手

Adobe 协议中描述的是简单握手，而 Adobe 产品 Flash Media Server 采用复杂握手的方式

简单握手

与流程图有点不同，握手的实际流程分三个步骤:

• 第一步， Client -> Server，内容是 C0+C1
• 第二步， Server -> Client，内容是 S0+S1+S2
• 第三步， Client -> Server，内容是 C2

我使用 Wireshark 抓包，验证了过程(我使用 nginx-rtmp-module 做服务器，ffmpeg推流，VLC Media Play播放)

报文的解释：

        C0 与 S0
    +-+-+-+-+-+-+-+-+
    |  version      |
    +-+-+-+-+-+-+-+-+

• C0 与 S0
  • C0：客户端发送其所支持的 RTMP 版本号：3~31。一般都是写 3
  • S1：服务端返回其所支持的版本号。如果没有客户端的版本号，默认返回 3

        C1 与 S1
    +-+-+-+-+-+-+-+-+-+-+
    |   time (4 bytes)  |
    +-+-+-+-+-+-+-+-+-+-+
    |   zero (4 bytes)  |
    +-+-+-+-+-+-+-+-+-+-+
    |   random bytes    |
    +-+-+-+-+-+-+-+-+-+-+
    |random bytes(cont) |
    |       ....        |
    +-+-+-+-+-+-+-+-+-+-+

• C1 与 S1
  • C1/S1 长度为 1536B。主要目的是确保握手的唯一性。
  • 格式为 time + zero + random
  • time 发送时间戳，长度 4 byte
  • zero 保留值 0，长度 4 byte
  • random 随机值，长度 1528 byte，保证此次握手的唯一性，确定握手的对象

        C2 与 S2
    +-+-+-+-+-+-+-+-+-+-+
    |   time (4 bytes)  |
    +-+-+-+-+-+-+-+-+-+-+
    |   time2(4 bytes)  |
    +-+-+-+-+-+-+-+-+-+-+
    |   random bytes    |
    +-+-+-+-+-+-+-+-+-+-+
    |random bytes(cont) |
    |       ....        |
    +-+-+-+-+-+-+-+-+-+-+

• C2 与 S2
  • C2/S2 的长度也是 1536B。相当于就是 S1/C1 的响应值，对应 C1/S1 的 Copy 值，在于字段有点区别
  • time， C2/S2 发送的时间戳，长度 4 byte
  • time2， S1/C1 发送的时间戳，长度 4 byte
  • random，S1/C1 发送的随机数，长度为 1528B

RTMP 是用于网络传输的二进制协议，默认使用 Big-Endian 格式，因为 Big-Endian 格式在抓包时可读性较好

复杂握手

对于复杂握手，不使用 Adobe 产品 FMS 的话，简单了解即可

相对于简单握手，复杂握手增加了严格的验证，主要是 random 字段上进行更细化的划分

1528Bytes随机数的部分平均分成两部分，一部分764Bytes存储public key(公共密钥)，另一部分764Bytes存储digest(密文，32字节)。

从二进制报文的角度，判断复杂握手的特征是，Version部分不为0，服务器端可根据这个来判断是否简单握手或复杂握手。

握手的了解到这里，下面继续看看握手之后的步骤

step 3, RTMP connect

RTMP 有一个重要的概念：Application Instance，直观上，可以体现在 rtmp 的 url 上

我测试的推流例子，用到的 url 为: rtmp://192.168.23.152/live/movie

大家可以注意到，上面 wireshark 对 rtmp 抓包的截图中，握手后紧接一个 client->server 的报文 connect('live')，

1909	36.398483095	192.168.23.152	192.168.23.152	RTMP	282	connect('live')

而这个 live 就是这次推流的 Application Instance

step 4, createStream(创建流) — 创建逻辑通道

上面 wireshark 对 rtmp 抓包的截图中，有下面两行，第一行是 client->server，第二行是 server->client

1933	36.484940956	192.168.23.152	192.168.23.152	RTMP	105	Window Acknowledgement Size 5000000|createStream()
1935	36.485004644	192.168.23.152	192.168.23.152	RTMP	109	_result()
1946	36.528398367	192.168.23.152	192.168.23.152	RTMP	168	getStreamLength()|play('movie')|Set Buffer Length 1,3000ms

直观地，rtmp://192.168.23.152/live/movie 的 movie 是这次拉流的 stream。

createStream 命令用于创建逻辑通道，该通道用于传输视频、音频、metadata。在服务器的响应报文 _result() 中会返回Stream ID，用于唯一的标示该Stream。

getStreamLength 命令用来获取 movie 的流的长度

Real Time Messaging Protocol (AMF0 Command getStreamLength())
    RTMP Header
    RTMP Body
        String 'getStreamLength'
        Number 3
        Null
        String 'movie'
Real Time Messaging Protocol (AMF0 Command play('movie'))
    RTMP Header
    RTMP Body
        String 'play'
        Number 4
        Null
        String 'movie'
        Number -2000

根据 Adobe’s Real Time Messaging Protocol 里对 _result 命令的定义，上面 body 中第四个字段 “Number 1” 便是此次的 Stream ID

step n，anything

一般的 rtmp 连接的流程，都如上所示，后面便是命令与音视频数据的消息，比如：

• 播放器的客户端发送play命令来播放指定流，等待服务端传输音视频数据。
• 推流的客户端会发送 publish 命令，开始上传音视频数据。

step last, deleteStream(删除流)

根据 Adobe’s Real Time Messaging Protocol

NetStream sends the deleteStream command when the NetStream object is getting destroyed.
当 NetStream 对象销毁的时候发送删除流命令。

比如，播放器客户端停止播放，可以删除指定Stream ID的流。服务器不用对这条命令发送响应报文。

Reference

• Adobe’s Real Time Messaging Protocol
• RTMP协议入门
• 网宿超大规模直播运营优化之旅
• TCP连接那些事
• RTMP H5直播流技术解析
• RTMP协议的message