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

望伊如西 发表于 2019-2-19 20:06

之前写了一篇文档投稿,名称是远程桌面无法访问——用wireshark定位问题,有朋友说比较实用,这鼓励我再写一篇。
之前的那个案例比较简单,就是远程桌面访问不了的问题,定位起来比较快。今天的这篇投稿涉及到性能问题,性能问题是比较难的,因为没有特别的报错给你做参考。
客户问题
总部部署了一台ERP服务器,分支电脑的ERP客户端要通过深信服搭建的VPN来进行访问总部服务器。系统上线后,发现在分支用客户端打开后,有些数据内容要等很久才能显示出来。而在总部内网使用客户端访问ERP服务器则没有问题。同时在分支内网电脑去ping总部的服务器没有任何的丢包延时。
即,ping测试没有丢包延时,应用也能访问,没有报错,只是访问的时候显示内容要等很长时间。
拓扑环境如图(因为和公网ip没有关系,所以拓扑图中隐去不写):
900565c6bf0a824ac2.png
排查思路:
1.分别在分支和总部设备的lan口,wan口,vpn口共6个接口上抓包。开启抓包后,再在分支电脑上打开ERP客户端访问,出现现象后,结束操作停止抓包。
227125c6bf0b72fbb4.png
2.我们要知道,TCP/IP体系模型是分层的。各层关注于自身的事物,同时下层又为上层提供服务。就比如寄信,写信双方只需要关注信件内容,快递员只需要关注如何把信件送达。但是快递员的工作又是为写信双方提供服务的。
所以做ping测试的时候,如果存在丢包延时,那肯定会影响数据的传输访问,因为ping测试是基于ICMP协议的,ICMP协议是网络层的协议。网络层出现问题,会影响上层。
是不是ping测试不丢包不延时,那访问就一定没问题呢。也不是,因为网络层上面还有传输层及应用层,也可能是传输层或应用层的问题。所以有时候客户说,“你看没有丢包延时啊,咋访问卡呢,这是咋回事啊小老弟?”,你现在应该能够解释了
3.我们先来打开第一个抓包文件看看。即fenzhieth0,通过过滤条件,先过滤出我们先要的内容
307695c6bf0c7d1ca3.png

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

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

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

7.从会话信息中,我们可以看到传输数据的过程中建立了49个连接。
968925c6bf0f663e9e.png
8.我们挑选其中一个数据传输比较多的连接。比如上图中的第三个连接,发送了815KB的数据,然后右键过滤出来。
140595c6bf0fdd9915.png
9.此时的过滤条件会自动给你填写好显示出来
59415c6bf104ccfcc.png
10.再次查看该连接下,按上述方法看专家信息,其实该连接下是一个重传都没有的。接下来,我们点击一个从服务器发往客户端的包,再来看TCP流图中的Stevens时序流图,统计statistics—>TCP Stream Graphs—>time sequence (stevens)
430775c6bf10cda31f.png
11.展示了如下界面,可以看到,服务器发往客户端的数据,seq号在一段时间内突然就卡住了。一直没有变化增长。我们要知道的是,tcp中的seq号用来表示一个tcp段,len表示他的长度。比如一个tcp段,他的seq号是0,长度len是2,那么下一个tcp段的seq号就是(0+2)2。这张图中,seq号连续增长就说明服务器就在一直发送数据。如果seq号在一段时间内一直保持一致,说明就没有发送数据了。
132145c6bf114c9eff.png
12.也就说明问题很可能就出在这块了。这段时间为什么服务器突然就停住了
13.点击Stevens图中的卡住的点,你就能找到对应的数据包,分别是467号包和819号包
1985c6bf11bef343.png
14.此时一看上图,467号包到819号包之间的内容,就可以发现问题了。819号包在等816号包发出,而816号包发出的时候,距离468号包发出足足等了近6s。也就是说服务器再等客户端发送一个数据包,但是这个数据包不知道为何突然等了近6s才发出,才导致服务器给客户端传输的时候,seq号在一段时间内上不去。
15.而后续又看了几个连接的情况都是一模一样的。也就说明,访问卡慢是由客户端引起的,不知为何客户端会突然停止发包
16.因为看的是分支设备eth0口抓的包,所以数据包是从内网传到设备eth0口的,可以确定的是和我们的vpn设备没有任何关系了,剩下的问题可以让ERP的工程师去排查。
同时猜想用woc开启加速后,会有效果吗?
——个人认为不会,因为woc开启后,是分支的woc设备和分支内网电脑做交互。把woc设备当做是总部的服务器,那内网客户端和woc交互数据的时候,依旧会出现上面这种情况,因为这种情况是在客户端电脑上发生的。要想解决,就得从客户端上看是什么原因导致了这6s的延时发包。

喜欢这篇分享吗?喜欢就给楼主打点赏吧!点个赞也是极大的鼓励!

发帖可获得5S豆;若您的分享被加精或推荐优秀等,将获得更多S豆奖励,了解更多S豆奖励信息

完善手机号和公司名称,让服务更省心更便捷!立即完善

×
有话想说?点这里!
可评论、可发帖

本版热帖

本版达人

新手57412...

本周提问达人