访问X友软件卡顿

2017年应用访问卡慢分析

1.基本情况:

客户环境现象:

总部和分支使用sangfor vpn对接,分支内网电脑ping总部内网服务器,没有丢包,没有延时。但是在分支使用X友客户端访问总部的X友服务器会出现卡顿(即打开客户端后,有些内容显示出来的等待时间较长)

为了排错,客户那边基本没有其他流量在跑。


客户内网拓扑:

总部和分部通过woc做vpn对接(没开加速),其中eth0口是内网口,pppoe和wan(eth2)口是外网口。分支woc的wan口(pppoe)地址是100.64.7.184,eth0(lan口)地址是10.37.11.254,lan口下连一台测试电脑10.37.11.180。总部单臂部署,X友服务器是10.37.1.77。分支pc通过X友软件和总部的X友服务器做数据交互。

2.排错操作:

  1. 在分支客户端电脑开始访问X友前,在分支woc和总部woc的eth0口,vpntun口,wan口写下抓包命令。写完之后执行命令,之后再用电脑正式访问X友。看到现象后,等待几秒再停止所有接口的抓包。

  1. 其实在抓到上述6份比较漂亮的包之前,我还重复上述操作过几次。虽然时间比较久了,但是我看到自己有导出csv的后缀文件,估计是我那时候想通过比较几个文件中的ip.id来判断访问应用的时候是否存在丢包。估计那时候我没看出啥东西来,就纯浪费时间去了。

  1. 后来听说X友这种应用访问卡慢,是因为小包交互过多导致的。就试着打开了一个包fenzhieth0.pcap,然后输入过滤条件,来看下200字节以下的包有多少。emmmm一看占比57.6%呢,小包很多了很多了

  1. 于是脑补出理由,打电话给渠道。举个例子,访问X友打开软件要传输15000字节的数据,公网延时是20-30ms,比如小包只传100字节,那这15000字节的数据就要传输150次,时间上就是20ms*150,这样访问就会出现卡顿的情况。如果是用ftp等测试,每次传输是1000字节的话,就是传输15次,所以访问ftp服务器的时候你就不会觉得卡。所以这是X友那边发包机制的问题,和我们设备没有关系

  2. 渠道觉得好有道理,然后就信了,之后他去和客户解释就再也没找我了。工单关闭


3.上述排错错在哪

  1. 自己想当然的瞎JB乱讲,同时基础概念不清晰,或者说是完全没有概念

  2. 在TCP中,发送方和接收方都会存在一个发送窗口和接受窗口。发送窗口表示我发送方一口气能发送多少数据,接收窗口表示我接收方还能接收多少数据放在缓存区中。发送方要尽量保证多发数据,同时也得保证接收方能接收的过来,不至于数据发生溢出。MSS是一个数据段的数据最大长度,那么发送窗口和MSS存在啥关系呢。刚刚说道,发送窗口表示我发送方一口气能发送多少数据,那么MSS的值就确定了,我要一口气发这么多数据要发出多少个包。举个例子来说,我发送方一口气能发送1000个字节,但是一个数据段的MSS是100字节,那么我一口气就能发10个包出去。

  3. 给渠道说的理由,看上去好像没问题。其实概念就没弄清。给渠道的说法表明,我的数据包是一个一个发出的,但是实际上TCP中不是这么传输数据的


4.重新整理排错思路

  1. 访问一个应用卡慢,分两种情况。一个是网络问题,一个是设备性能问题。

  2. ping测试是在网络层的测试。客户环境中ping测试不丢包不延时,基本上可以判断网络是没啥问题的

  3. 之前做了这么一个操作,把pcap文件导出成csv文件,想通过比较各个csv文件中是否存在丢包。但是没有看是什么东西来,而且上述操作比较耗时间。要知道的是,如果数据包丢失,就会导致重传或是有重复ACK。那我们是不是可以通过wireshark工具来自动分析下

  4. 先通过过滤条件,把测试电脑与服务器的互访流量给过滤处理

  5. 然后在把文件重新保存一份

  6. 先打开fenzhieth0这个包。过滤出客户端和服务器双向交互的流量

  7. 随机选择一个包,然后右键点击Follow—>tcp stream,过滤出一个tcp连接的互访流量

  8. 然后点击统计 statistics—>TCP Stream Graphs—>time sequence (stevens),可以看到该连接,一个方向上的seq号增长情况

  9. 可以看到弹出下框,也就意味着。在该连接中,服务器到用户客户端方向的数据流增长过程中,有5s左右是卡住了。那我们通过Stevens图,可以找到卡住的2个点,包号分别是467号包与819号包

  10. 可以看到下图,服务器在等待客户端发送816号包。而816号包的发出,是在468号包发出之后耗时近6s。

  11. 后续又按上述操作,观察了其他的几个tcp连接,以及zongbueth0口的抓包情况。都是一模一样的,总会有几秒卡住

  12. 也就意味着,这是180这台客户端的问题

  13. 为什么会出现这种情况,这就是X友厂商应该去分析的了。因为这个是X友应用层层面的问题


5.联想

  • 为什么和我们设备无关了?

​ ——因为在woc的eth0口抓包,发现上图中468号包发出之后,隔了近6s才收到了816号包。我们设备都没做封装啥的操作呢,只是单纯接收包而已

  • 用woc开启加速后,会有效果吗?

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