rtmp抓包分析

tcpdump抓包：

tcpdump host IP and tcp port 1935 -w a.pcap

whireshark分析：

用wireshark打开a.pcap

3握手（Handshake）

一个RTMP连接以握手开始，我们先看下图：

首先我们要明确的是客户端IP是192.168.1.102（我的电脑），123.183.164.23是RTMP服务器。

剧本应该是这样子的：

1. RTMP协议是TCP协议的上层协议，所以必须要先建立TCP连接，所以就看到了1-4这几个TCP三次握手的包。

2. 客户端向服务器发送C0块（chunks），表示要和服务器握手，C0中包含版本号。

3. 服务器收到C0后，检查C0中的版本是否支持，如果支持发送S0作为响应，否则应该终止连接。

4. 客户端和服务器都分别等待C1和S1，等待版本确认。

5. 客户端收到S1后发送C2，服务器收到C1后发送S2（确认发送，测试握手完成。）

然而，协议的实际执行却不是按照剧本来的（如果按剧本来，延迟就要大大增大了），实际执行是这样的：

1. RTMP协议是TCP协议的上层协议，所以必须要先建立TCP连接，所以就看到了1-4这几个TCP三次握手的包。

2. 客户端发送的是C0+C1块，直接告诉服务器我发的版本我自己确认了。

3. 服务器更狠，一个大嘴巴子就抽回来了（发送S0+S1+S2）。

4. 客户端收到后，发送C2，握手完成！

附上RTMP协议中的流程图：

有同学站起来提问了，No.13的包是C2，那么后面的connect是what？这位同学请坐下，往下看。

4建立一个网络连接（NetConnection)

提示：

     网络连接代表服务器端应用程序和客户端之间基础的连通关系。

我们接着看抓到的包：

RTMP握手完成后，要建立网络连接。大家都知道一个普通的标准的rtmp流是什么样子的？rtmp://IP:PORT/APP/Stream 是不是这样？

实际剧本是这样子滴：

1.客户端在发送C2的时候，顺带还发了一个请求连接的命令，要求与服务器应用（live7）建立网络连接，这就是RTMP URL中的的Application。soga，是不是恍然大悟？

2.服务器在收到客户端发送的连接请求后发送如下信息：

主要是告诉客户端确认窗口大小，设置节点带宽，然后服务器把“连接”连接到指定的应用并返回结果，“网络连接成功”。并且返回流开始的的消息（Stream Begin 0）。

3.客户端在收到服务器发来的消息后，返回确认窗口大小（No.18），此时网络连接创建完成。

协议流程图：

5建立一个网络流（NetStream
)

提示：

网络流代表了发送多媒体数据的通道。

服务器和客户端之间只能建立一个网络连接，且多个网络流可以复用这一个网络连接。

接着看抓包：

现在地洞挖好了，就差铺铁轨了！

1. 客户端向服务器发送设置Buffer Length为0，3000ms，并请求创建流（createStream）。

2. 客户端向服务器发送一个控制消息（去了，我也不知道干啥用的！）

3. 服务器收到请求后向客户端发送_result()，对创建流的消息进行响应。此时NetStream创建完成。

协议流程图：

6播放

提示：

主要功能：传输音视频数据

看抓包：

万事具备，只欠东风了。

1.客户端向服务器发送播放命令，请求播放stream，并设置Buffer Length 1，3000ms。

2.服务器收到请求后，向客户端发送设置块大小的协议消息，并且还附加了一堆其他的消息一起发送：

包括 Stream Begin（告知客户端流ID为0）、NetStream.Play.Reset和NetStream.Play.Start（告知客户端播放成功，其中reset会调整流ID为1）等。

3.服务器向客户端发送推流通知，并附带元数据信息（分辨率、帧率、音频采样率、音频码率等等）和视频、音频数据。此时客户端就可以开始正常播放rtmp流了。

协议流程图：

结语

本文总结了RTMP协议播放环节的全流程，后续文章将为大家带来更多RTMP实际输出中遇到的坑以及优化方案。