提示
X
本案例来自tskb,请前往tskb修改源内容:立即前往
'>

【AD】七层虚拟服务访问慢,如何深入分析数据包

|

问题描述

某客户发布的七层虚拟服务,但部分客户端访问会出现非常卡慢的情况。

告警信息

客户端PC使用浏览器httpwatch抓包文件:1117-7ceng-2.hwl
AD上分别抓包了前后端数据包文件:
pc->AD方向:    1117-pc-ad-2.cap
AD->srv方向:   1117-ad-srv-2.cap

有效排查步骤

1、以下面这个请求为例,从浏览器抓包看,是花费了677ms, 且是花费在receive数据上,即收数据慢,这是不正常的。该请求源端口(客户端端口)为46355,URI为:
GET /static/staticize/byd/imgtmp/1416211447001_%E5%85%85%E7%94%B5%E5%A1%94.jpg



2、从AD上抓pc->AD的数据包分析, AD约在0.918802s收到客户端的请求,并在1.554741s将该应答转发完,用时1.554741秒-0.918802秒=635毫秒(跟浏览器抓包看所有的时间基本相等), 在这期间数据包转发没有任何异常。



3、从AD->srv的抓包数据看,刚开始的时候,数据交互是正常的。但是在下面截图中出现了异常,服务器发了两个连续数据包(这两个数据包携带数据是图片的一部分)到AD, seq序号和长度分别是,第1个包seq:72585,  len:1460; 紧跟着第2个包的seq:7550572585+1460), len:1460;  服务器紧接着继续发的数据包的seq应该为76965 (即第2个包的75505+1460), 而AD在此的期间的行为就是向服务器发ack包(确认数据收到), 所以AD向服务器回的ack值为74045(72585+1460)和75505,但是在这两个ack包中间,由服务器发给AD,seq是79885的数据包这就意味着期间有79885-76965个字节被丢掉了, (如果AD收到的话, 两个数据包中间应该有一个由AD发给服务器, 值为79885的ack),相当于有2个数据包被丢掉了, 因此后面有大量的服务器的重传包,时间也花费在这个地方,这种丢包会对客户端造成的体验就是浏览器会卡(一个图片如果缺少部分数据的话,是无法在浏览器呈现的,所以会卡住)
抓包是从网卡抓取的,丢包意味着AD的网卡没有收到,也就是AD->srv之间的网络丢包了。




4、由于这个请求花费了677ms, 这就意味着后面同一个tcp连接里的请求会被阻塞住, 比如下面这个请求, 客户端端口也是46355,意味着该请求与上面刚才分析的请求是同一个tcp连接的。下面这个请求从浏览器抓包看是用704毫秒,但实际光被之前的请求block住,就有679毫秒, 而发出请求到收到数据仅仅用了0.001+0.018+0.006= 25毫秒, 也就是如果没有丢包,上述请求没问题的话, 那这个图片只用25毫秒就可以接收完毕。




其他请求分析:

AD->SRV抓包, 从seq是103617至106537之间的字节被丢掉了。




由于这个不正常的请求, 会导致同一个tcp连接的其他请求被block住; 比如下面截图里的图片请求,即本来24ms就可以完成的请求,却被阻塞住,用了有427ms。









解决方案

基于以上分析过程,重点是学会如何深入的分析数据包,甚至丢包是丢了哪个分片。根据分析结论知道是因为AD到节点服务器间丢包导致的,最终查明因为中间存在防火墙策略导致。

我要分享
文档编号: 199417
作者: admin
更新时间: 2023-04-04 09:37
适用版本: