音视频推流中使用wireshark进行抓包分析RTMP

一、前期工作

        最近使用开发板采集音视频数据合成FLV流后进行推流到PC端（RTMP协议），PC端需要安装对应的nginx以及支持rtmp的nginx，在网上找了教程后安装成功，现在使用wireshark工具对开发板于pc端之间的通信协议进行解析。

二、wireshark配置

        安装wireshark后选择正确的接口（我这里是以太网2，如果不清楚的可以把开发板的电源线拔掉，看那个端口有流量变化）。

        然后需要进行过滤器的配置否则会有很多乱七八糟的数据，看不懂

        这里由于我们使用的是RTMP协议，其是基于tcp协议的，因此我们新增一个过滤器名字随便设置，然后设置其功能为：

        意思就是我们只捕获tcp协议的 port 1935的端口的（RTMP协议默认端口1935），而且是192.168.1.22（开发板）于192.168.1.20（PC）之间通信的数据：

tcp port 1935 and host 192.168.1.22 and host 192.168.1.20

        这里我建议提前排查一下开发板与pc端口之间是否能ping的通。

        然后对以太网2端口开始捕获数据，并把配置好的过滤器选中

三、数据解析

下图为我的部分捕获结果：

从上面的一栏可以看到，其中包括包次序、时间、源、目的、协议、长度、信息

从源地址和目的地址来看我们可以初步判断，我们没有抓错包，因为数据是开发板与pc端之间的通信，protocol可以看出有tcp与rtmp两种，其不同之处如下：

TCP数据包：在TCP连接建立或传输控制（如三次握手、窗口大小调整）时，Wireshark会识别出TCP协议，并显示为TCP。这些数据包主要用于维护可靠的连接，确认数据的传输顺序和状态。

RTMP数据包：当实际的音视频流数据被封装在TCP数据包中进行传输时，Wireshark会进一步解析这个数据包，发现其中包含了RTMP协议的数据，并在Protocol字段中显示为RTMP。

3.1TCP3次握手

第一行：

        源192.168.1.22（开发板）    目的192.168.1.20（PC）    协议TCP    

40494 → 1935 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=2033509860 TSecr=0 WS=128；

        表示开发板向PC端进行传输数据，端口是40494到1935，其中40494是开发板使用的临时端口，而1935则是RTMP中默认的端口

        SYN是TCP的标志，在这里的作用是告诉PC请求建立tcp连接

        Seq=0表示是第1个消息

第二行：

        源192.168.1.20（PC） 目的192.168.1.22（开发板） 协议TCP

1935 → 40494 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM TSval=1142957703 TSecr=2033509860

        表示PC端应答开发板的TCP请求信号，因此为SYN，ACK且Ack=1

第三行：

        这行与第二行的内容是一样的，大概率是网络问题导致重新传输Retransmission

第四行：        

        源：192.168.1.22（开发板） 目的：192.168.1.20（PC）协议TCP

40494 → 1935 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2033509860 TSecr=1142957703

        这里表示开发板收到了PC的应答信号因此再发送一个应答信号。

        【这里我自己的理解是，可能由于网络的原因，PC收到开发板请求的时间和PC应答的时间较长，在这段时间内，开发板可能等太久后超过一个时间阈值后不再等待PC，因此为了确保PC端应答的时候开发板还在等待，因此开发板等待到应答信号后再次给PC发送一个应答信号，就好像再说：我还在等你】

        至此，TCP的三次握手完成。

第五行：

        这里又对整体的配置进行了一次发送，包含在是有数据长度的，前面几次数据长度都是0；

3.2RTMP握手

RTMP协议建立在TCP之上，因此与TCP类似，也需要三次握手：

第六行：

        开发板发送C0与C1给PC端

        C0：一个1字节的协议版本号；C1：1536字节的随机数据，包含客户端发送的时间戳和其他信息。

第14行：

        PC端回应开发板

        S0 + S1 + S2：服务器（如PC）收到C0和C1后，回应三个数据包：S0：1字节的协议版本号；S1：1536字节的随机数据，包含服务器发送的时间戳；S2：返回C1中接收的时间戳，作为对客户端数据的回应。

第20行:

        开发板再次回应PC端

        C2：客户端最后发送一个C2包，回应服务器的S1和S2中的时间戳，握手完成。

3.3RTMP建立连接

在23行建立连接，connect命令建立，这里的live是在推流时候设置的，我当时设置的命令是:

这里rtmp://为协议 192.168.1.20为服务器地址 live为应用名称 stream是流名称

rtmp://192.168.1.20/live/stream

        然后这里的33行是准备发布流，23行配置了应用名称，33行配置了流名称并发送准备发送流的信号，然后34行是PC对开发板的回应说，我已经准备好了。

3.4RTMP正式发布

这里的39 行表示正式向stream推流，然后40 表示成功接收

第45行表示服务器发送数据包并标记为setDataFrame

3.5停止

客户端发送FIN，ACK信号作为停止信号

服务器恢复FIN，ACK信号即表示应答

最后客户端再次发送ACK作为总体的停止信号