应用访问卡慢——用wireshark定位问题

之前写了一篇文档投稿，名称是远程桌面无法访问——用wireshark定位问题,有朋友说比较实用，这鼓励我再写一篇。

之前的那个案例比较简单，就是远程桌面访问不了的问题，定位起来比较快。今天的这篇投稿涉及到性能问题，性能问题是比较难的，因为没有特别的报错给你做参考。

客户问题：

总部部署了一台ERP服务器，分支电脑的ERP客户端要通过某公司搭建的VPN来进行访问总部服务器。系统上线后，发现在分支用客户端打开后，有些数据内容要等很久才能显示出来。而在总部内网使用客户端访问ERP服务器则没有问题。同时在分支内网电脑去ping总部的服务器没有任何的丢包延时。

即，ping测试没有丢包延时，应用也能访问，没有报错，只是访问的时候显示内容要等很长时间。

拓扑环境如图（因为和公网ip没有关系，所以拓扑图中隐去不写）：

排查思路：

1.分别在分支和总部设备的lan口，wan口，vpn口共6个接口上抓包。开启抓包后，再在分支电脑上打开ERP客户端访问，出现现象后，结束操作停止抓包。

2.我们要知道，TCP/IP体系模型是分层的。各层关注于自身的事物，同时下层又为上层提供服务。就比如寄信，写信双方只需要关注信件内容，快递员只需要关注如何把信件送达。但是快递员的工作又是为写信双方提供服务的。

所以做ping测试的时候，如果存在丢包延时，那肯定会影响数据的传输访问，因为ping测试是基于ICMP协议的，ICMP协议是网络层的协议。网络层出现问题，会影响上层。

是不是ping测试不丢包不延时，那访问就一定没问题呢。也不是，因为网络层上面还有传输层及应用层，也可能是传输层或应用层的问题。所以有时候客户说，“你看没有丢包延时啊，咋访问卡呢，这是咋回事啊小老弟？”，你现在应该能够解释了

3.我们先来打开第一个抓包文件看看。即fenzhieth0，通过过滤条件，先过滤出我们先要的内容

4.过滤完之后，可以查看丢包与重传。因为我们可以看到，使用ERP软件，传输层是用的TCP协议。如果传输层存在一定比例的丢包与重传就会影响性能。我们在主界面看到，过滤条件搜索之后的数据包展示了4157个，再点开专家信息。

5.在专家信息中，勾选只展示过滤条件搜索后的信息。可以看到重传的数据包个数。重传将近千分之五，可能会影响性能，毕竟是在公网上传输了数据。

6.我们再打开会话信息。

7.从会话信息中，我们可以看到传输数据的过程中建立了49个连接。

8.我们挑选其中一个数据传输比较多的连接。比如上图中的第三个连接，发送了815KB的数据，然后右键过滤出来。

9.此时的过滤条件会自动给你填写好显示出来

10.再次查看该连接下，按上述方法看专家信息，其实该连接下是一个重传都没有的。接下来，我们点击一个从服务器发往客户端的包，再来看TCP流图中的Stevens时序流图，统计statistics—>TCP Stream Graphs—>time sequence （stevens）

11.展示了如下界面，可以看到，服务器发往客户端的数据，seq号在一段时间内突然就卡住了。一直没有变化增长。我们要知道的是，tcp中的seq号用来表示一个tcp段，len表示他的长度。比如一个tcp段，他的seq号是0，长度len是2，那么下一个tcp段的seq号就是（0+2）2。这张图中，seq号连续增长就说明服务器就在一直发送数据。如果seq号在一段时间内一直保持一致，说明就没有发送数据了。

12.也就说明问题很可能就出在这块了。这段时间为什么服务器突然就停住了

13.点击Stevens图中的卡住的点，你就能找到对应的数据包，分别是467号包和819号包

14.此时一看上图，467号包到819号包之间的内容，就可以发现问题了。819号包在等816号包发出，而816号包发出的时候，距离468号包发出足足等了近6s。也就是说服务器再等客户端发送一个数据包，但是这个数据包不知道为何突然等了近6s才发出，才导致服务器给客户端传输的时候，seq号在一段时间内上不去。

15.而后续又看了几个连接的情况都是一模一样的。也就说明，访问卡慢是由客户端引起的，不知为何客户端会突然停止发包

16.因为看的是分支设备eth0口抓的包，所以数据包是从内网传到设备eth0口的，可以确定的是和我们的vpn设备没有任何关系了，剩下的问题可以让ERP的工程师去排查。

同时猜想用woc开启加速后，会有效果吗？

——个人认为不会，因为woc开启后，是分支的woc设备和分支内网电脑做交互。把woc设备当做是总部的服务器，那内网客户端和woc交互数据的时候，依旧会出现上面这种情况，因为这种情况是在客户端电脑上发生的。要想解决，就得从客户端上看是什么原因导致了这6s的延时发包。

这个文档是简单讲了下TCP的内容。传输层除了tcp，还有udp协议。udp这个协议报文头部比tcp简单，所以没有所谓的建立连接过程与重传机制。在使用视频会议、语音通话等应用时，传输层一般是udp。那么如果出现视频会议卡顿时，是否可以尝试用wireshark抓包来排查问题呢？是可以的，如果有朋友感兴趣，下期再出一个通过wireshark来定位视频会议卡顿的问题

文章地址

视频会议卡顿——用wireshark定位问题

学习了，最近也在学wireshark，受益匪浅

太狠了，这个技术真的是可望不可及。汝之秀，我等望尘莫及。

学习了，感谢

棒棒哒冲鸭:耍酷:

楼主厉害

感谢分享

牛逼，像是原厂的工程师啊哈哈哈

这个是真高手