之前的那个案例比较简单,就是远程桌面访问不了的问题,定位起来比较快。今天的这篇投稿涉及到性能问题,性能问题是比较难的,因为没有特别的报错给你做参考。 客户问题: 总部部署了一台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的延时发包。 |