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:75505(72585+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。