http抓包分析GET延迟(wireshark)

一. 背景

本人在互联网视频行业, 需要经常使用http GET获取数据, 最近遇到一个bug,测试说页面在用户使用高峰时段偶尔会出现卡顿, 我们当即找了服务端的负责人.他们看了一下现象, 没当回事, bug拖了一周也没有解决.

后来才知道服务端也存在模块划分, 有人管数据处理, 有人管硬件运维, 一开始很难说是谁的问题. 一下子没有人全力承担解决. 在前端偶发的现象, 并没有在服务端看到什么现象. 服务端的人难重现, 也难跟踪.尽管问题已经从前端甩出去了, 但是要想让它更快的得到解决, 还需要更多的诊断信息. 为了加快解决, 我尝试从前端一侧积极寻找更多信息.

二. 抓包操作

1. 打开wireshark, 启动对本地网卡抓包. (wireshark的安装和简单操作可以百度搜索)

2. 重现问题

3. 停止wireshark抓包.

三. 分析抓包

1. 在wireshark上方绿条中输入http.request作为过滤条件.

发现http协议的GET数据包

2. 将这个包的Destination对应的IP 作为过滤条件, 替换原过滤条件, ip.addr==101.227.32.63

发现大量红色和黑色的数据包.

3. 首先查看time这一列, 从第1行(SYN)到第14行(GET), 时间间隔11秒.

恰恰与此次页面卡顿的时长12秒左右基本吻合. 详细比较之后, 发现三行红色的[RST]间隔分别是3秒和6秒, 这构成了11秒是主要间隔.

4. 为什么会出现这么多[RST]呢?

百度搜索了一下:

RST: 因异常终止一个连接: TCP任意一方可能因为异常, 可以发送一个RST报文中途释放一个连接, 收到RST的一方将终止该连接, 并通知应用层连接复位.

5. 这里有异常引发了[RST], 那么是什么异常导致的呢?

先别急, 我们温习一下TCP三次握手, 图中可以看到:

(1). 第一次握手: 请求方发送[SYN=1], 带有发送序号seq;

(2). 第二次握手: 接收方回应[SYN=1 ACK=1], 带有另一个seq, 以及ack=seq(请求方)+1.

(3). 第三次握手: 请求方回应[ACK=1], 带有seq=seq(请求方前一次), 以及ack=seq(接收方)+1.

6. 第一条[RST]

这里前三行的包可以看到:

(1). 第一行是第一次握手[SYN] seq=0, 没有问题

(2). 第二行是第二次握手[ACK] seq=1 ack=3347692635, 这里就是问题了.

相比正常的信令, 这里ack应该是1, 也缺少SYN标志位. 所以, 后面的RST就是对告知, 这里有异常, 终止.

7. 第二条[RST]

3秒之后触发了Restransmission, 秒, 可惜仍然出现同样的ack错误

8. 第三条[RST]

6秒之后又触发了Restransmission, 秒, 再次出现同样的ack错误

9. TCP建立

等待1秒, 这次前端触发了换了一个端口31851请求[SYN=1] seq=0, 回应[SYN=1 ACK=1] seq=0, ack=1 (正确), 再发[ACK=1] seq=1 ack=1, TCP建立成功, 发出GET.

后面的数据很快就拿到了. 所以问题出在TCP连接上.

10. 于是联系服务端的同事, 把调查的信息提供给他们, 才得到足够的重视, 很快通过扩容VIP(虚拟服务器)解决了.

四. 小结

抓包分析是应对网络问题最直接的手段, 所以遇到网络延迟问题或数据问题都可以使用该方法.

这里回顾了TCP的三次握手, 发现学校里学的三次握手真是远不如一次亲身经历来的印象深刻, 理解透彻.