2021-07-02

我们在平常的通信类软件开发完成后，需要测试，测试的过程中如果出现问题，例如，没有收到数据，或者收到的数据错误等问题，那我们可能就需要抓包分析，当我们抓到数据包后，我们怎么去分析来查找问题呢？
下面我就简单介绍如果使用wireshark分析数据包。

抓包两种方法：

• Linux平台我们用tcpdump抓包，上一篇已经讲过怎么用。
• windos平台我们直接打开wireshark抓包即可。

1.数据包分析的基本思路

• 根据条件过滤数据包
• 依次通过tcp，udp协议层和应用层分析需要的数据
• 通过问题发生的时间和应用层协议维度定位数据报文
• 通过分析定位出来的报文，找到问题

2.具体操作方法

2.1 抓包

tcpdump -i lo -w /temp/test/modbus.cap

• 上面命令是在Linux平台下抓取本机（127.0.0.1）的数据包保存到/temp/test/modbus.cap文件中。

2.2 用wirshark打开数据包

我们重点要关注三个信息：

• 时间
• protocol及协议类型
• ip及端口

2.3 报文分析

一般我们先看一次完整的数据报文，也就是说从通信建立成功，开始数据收发到通信端口这样一个过程。

1. 通信建立成功报文

**127.0.0.1的端口36935为客户端 127.0.0.1的端口502为服务端

• 主动打开。发送SYN，协商window size 、TCP MSS seq=0 len=0 MSS=65459 win=43690最大窗口大小。

• 服务端接收到syn。回复syn ack=0+1 并发送自身seq=0 确认自己的最大win=43690 MSS=65459

• 客户端接收到服务端发送来的ack和服务端自身的seq，客户端要发送ack= 0+1，给服务端发送确认报文。

• 服务端接收后，通信建立成功

2. 数据收发报文

• 可以看到数据收发实际上是应用层协议数据，例如图中是modbus协议的数据报文，如何区分报文是数据报文还是网络报文，可以通过len长度或者下方的协议层查看区分

3. 通信断开报文

• 主动关闭，发送FIN。Seq=328

• 服务端状态为FIN_wait1 处于半关闭状态

• 客户端状态为closed_wait 处于半关闭状态

• 客户端发送确认ack ack=328+1

• 服务端状态为FIN_wait2

• 客户端发送FIN seq=133

• 客户端状态为LAST_ack

• 服务端状态为time_wait

• 服务端发送ack ack=133+1

• 客户端状态closed

• 服务端状态closed，至此本次通信结束

2.4 根据问题定位问题发生的报文段

当我们的通信程序出现问题后，一般情况下我们是可以知道什么时间段出现的问题，例如程序日志记录2021年6月29日7点56分22秒数据不正确，那这个时候我们就可以通过时间维度去找报文。

经过时间过滤，我们找到2021年6月29日7点56分22秒的报文片段。

2.5 分析报文片段，定位问题原因

当我们找到报文片段后，就可以找到数据报文，例如我们图中是modbus协议报文，那我们可以根据点表或者寄存器地址，知道是哪个点的值出现了问题，例如我们的程序问题是寄存器地址为5004的点的值错误，那我们看看报文中的值是多少，就可以知道是对方的程序发送的问题，还是我们接受的程序解析问题。

• 首先我们找到了召唤报文，召唤的起始地址是0x138c及5004地址，然后我们在看回复报文：

我们看到服务端给我们回复的报文数据0x1388，如果按int类型转换就是5000，那么我们就可以拿这个值跟我们的应用程序解析的值做比较，如果相同但又不是我们期望的值，那就是服务端的问题，这样我们的问题就定位了。

总结

总的来说，我们做通信程序，一定要学会抓包，其次要回分析报文，只有这样我们才能定位各种问题，便于解决问题，当然，这是基本方法，还有很多异常问题也需要抓包分析，例如网络经常中断，数据经常丢失等问题，都需要通过抓包来分析和解决。

后面我讲讲抓包分析的一些包过滤技巧和常见的网络故障排除方法，希望你也能加入进来，我们一起学习，交流。