沿用之前文章的开头说明,应用传输慢是一种比较常见的问题,慢在哪,为什么慢,有时候光从网络数据包分析方面很难回答的一清二楚,毕竟不同的技术方向专业性太强,全栈大佬只能仰望,而我们能做到的是在专注于自身的专业方向之外,尽量扩展知识面,学会找出问题的规律,并提出可能的解决建议。
本篇案例是一个应用开发团队提出的“缓慢”问题,分别在发送和接收端抓取了相关数据包,“SendSideFinal.pcap” 以及 “RcvSideFinal.pcap”,实际上部分场景下的数据包分析确实需要在多点捕获,包括发送端或者接收端,甚至于中间路径的多个节点,这样更有助于网络问题分析。
案例取自 SharkFest 2010《Wireshark in the Large Enterprise》
跟踪文件基本信息如下:
λ capinfos SendSideFinal.pcap RcvSideFinal.pcap
File name: SendSideFinal.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 70 bytes
Number of packets: 220
File size: 18 kB
Data size: 46 kB
Capture duration: 95.639823 seconds
First packet time: 2009-09-11 05:24:51.255133
Last packet time: 2009-09-11 05:26:26.894956
Data byte rate: 485 bytes/s
Data bit rate: 3885 bits/s
Average packet size: 211.14 bytes
Average packet rate: 2 packets/s
SHA256: 104aeea149181060e3d3c744bb9ea4aea13c0be832e92e0852abf173df253f77
RIPEMD160: 3d5d768f175a949e818c9f1160688c8854234b59
SHA1: 1e117af53e4bbdd9b0cb3636117374a191c4ebf3
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 220
File name: RcvSideFinal.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Packet size limit: inferred: 70 bytes
Number of packets: 213
File size: 18 kB
Data size: 45 kB
Capture duration: 91.744055 seconds
First packet time: 2009-09-11 05:24:55.248731
Last packet time: 2009-09-11 05:26:26.992786
Data byte rate: 492 bytes/s
Data bit rate: 3936 bits/s
Average packet size: 211.94 bytes
Average packet rate: 2 packets/s
SHA256: 15731bbc644d0e2c1a304ef955ec62052d7fae377d3d8a420fc566e5be819404
RIPEMD160: d28207f0689fb74106d4d206c94cd305dd30cb2a
SHA1: bf129e7e359676a3d2cb496a8fa7169344356c7d
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 213
数据包跟踪文件在 linux 上通过 tcpdump 所捕获,两端数据包数量分别为 220 和 213 个,长度截断为 70 字节。发送端文件数据大小 46k 字节,捕获时长 95.64 秒,平均速率 3885 bps,而接收端文件数据大小 45k 字节,捕获时长 91.74 秒,平均速率 3936 bps,总体来说两端信息基本匹配,确实速率很低。
专家信息如下,可以看到异常的简洁,没有 Warning 相关信息,可见传输缓慢的问题并不是常见的丢包导致重传所引起。
首先从发送端 “SendSideFinal.pcap” 跟踪文件开始,展开数据包信息如下,可以看到数据包文件缺失 TCP 三次握手阶段的数据包,仅有数据传输 PSH/ACK 相关,最后以 RST 数据包结束。
其中 TCP 会话完整性分析中 tcp.completeness == 44
也说明了相关情况,44 = 4 + 8 + 32,其中 4 为 ACK,8 为 DATA,32 为 RST。
TCP 会话完整性分析说明详见《 Wieshark 提示和技巧 | TCP 会话完整性分析》
另从上面数据包交互来看,两端实际都有数据分段在传输,如果不是数据包文件的名字 “SendSideFinal.pcap” 以及 “RcvSideFinal.pcap”,也确实不好辨别哪个是发送端,哪个是接收端。从我个人的角度来说,定义出哪个是客户端,哪个是服务器端,以及两个文件的捕获点,可能会更加简单些。
首先因为是 TCP 传输,所以 TCP 端口 60301 和 7609 一般就可以分辨出,客户端 10.10.10.10,服务器 192.168.1.1。
其次如何判断这两个数据包跟踪文件分别是在哪里捕获的呢 ?可以通过两个字段值分析,一个 TTL,一个 ACK 间隔时间。
也有同学也会注意 No.7 以及 No.9 的间隔时间,为什么同样是 192.168.1.1 也是 ACK,而不考虑在内?首先简单来说,就是上面提到的,如果反过来判断,现象不匹配;其次细想下,No.7 只是发送端发送数据间隔的时间,譬如像浏览网页,停顿几秒再去点击一次的间隔,综合判断下来的结论就是 “SendSideFinal.pcap” 是在服务器端 192.168.1.1 所捕获,而 “RcvSideFinal.pcap” 是在客户端 10.10.10.10 所捕获。而剩下来的一个 No.9 ,不同于绝大部分的正常传输规律,那么它就真的是属于有问题的那一个了。
“SendSideFinal.pcap” 中数据交互规律如下图,总结一番:
找到 “SendSideFinal.pcap” 数据包传输的规律后,同时再结合“RcvSideFinal.pcap”对比分析,就比较容易识别出缓慢的问题所在,慢在哪。
以下仍以之前总结的数据交互规律,说明如下:
总结两个数据包跟踪文件的数据包交互规律以及时间分析,应用缓慢的问题主要出现在客户端 10.10.10.10 的数据请求阶段,每一次间隔基本都在 1.9s 左右,相对于如此大的延迟时间,两端基本都存在的延迟确认 100ms 左右的时间几乎都可以忽略不计了。