这篇文章主要讲解了“Wireshark TS系统吞吐慢问题如何解决”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Wireshark TS系统吞吐慢问题如何解决”吧!
问题背景
用户反馈一个场景,说是两个系统之间的吞吐很慢。吞吐量是系统性能分析中一个很重要的衡量指标,相关影响的因素也会有很多,因此反映在网络数据包分析上,也会是一个相对比较复杂的分析过程。
问题信息
跟踪文件基本信息如下:
λ capinfos EvilOddFinal.pcapFile name: EvilOddFinal.pcapFile type: Wireshark/tcpdump/... - pcapFile encapsulation: EthernetFile timestamp precision: microseconds (6)Packet size limit: file hdr: 8192 bytesPacket size limit: inferred: 64 bytesNumber of packets: 1004File size: 80 kBData size: 1109 kBCapture duration: 6.013219 secondsFirst packet time: 2010-01-13 04:55:32.247712Last packet time: 2010-01-13 04:55:38.260931Data byte rate: 184 kBpsData bit rate: 1475 kbpsAverage packet size: 1104.69 bytesAverage packet rate: 166 packets/sSHA256: 19cc103f13f74f8c3359f99c5ff883cce880361c823ff736c4b6d89d26e68b9eRIPEMD160: d879ea22aaff08a5b7a44ecd68b86cb71053bf46SHA1: afc170ee286153a9d9ce8dd19a9a4fe27d3df46bStrict time order: TrueNumber of interfaces in file: 1Interface #0 info: Encapsulation = Ethernet (1 - ether) Capture length = 8192 Time precision = microseconds (6) Time ticks per second = 1000000 Number of stat entries = 0 Number of packets = 1004λ
跟踪文件在 linux 上通过 tcpdump 所捕获,数据包数量 1004 个,长度截断为 64 字节,文件数据大小 1109K 字节,捕获时长约 6 秒,平均速率 1475 kbps。
专家信息如下,异常简洁,可以看到没有任何一条 Warning 信息,像是重传、乱序等,在简单排除些常见性问题之后,真实原因就需要进一步实际分析了。
此外统计 - 会话信息如下,仅有一条 TCP 流,数据主要传输的方向是 10.10.10.10 -> 192.168.1.10,速率低,仅为 1451 kbps,确实符合吞吐慢的现象。
同样统计 - I/O Graphs 如下,有比较明显一段时间,前后没有任何数据传输,整体速率低。
问题分析
展开数据包跟踪文件的主视图,首先是 TCP 三次握手信息 。
简要分析如下:
IRTT 0.000339 秒,判断在一个局域网内;
考虑到 SYN、SYN/ACK、ACK 的时间差,判断抓包点在服务器或者靠近服务器的地方;
客户端 Win 64512,不支持 WS(Window Scale 因子);服务器 Win 32768 ,也不支持 WS;
客户端和服务器 MSS 均为 1460,标准值;
客户端和服务器不支持 SACK 等;
客户端和服务器不支持时间戳。
由于该 TCP Stream 不支持 WS 和 SACK ,此处的低效率可能会是一个问题。
考虑到整体传输速率低以及 I/O Graph 图示结果,可以增加 frame.time_delta_displayed
信息列,检查数据帧之间的时间间隔,并从大到小依次排序。
可见有明显的一些大延迟,包括最大的 3.26s,多个 195ms 等等,依次分析:
3.26s
来自于客户端 No.238 数据帧,Wireshark 也明显的指示出这是一个 TCP Window Update
数据包,为客户端的 Window 更新。
定位到 No.238 前后,可以看到数据传输方向是服务器端 10.10.10.10 -> 客户端 192.168.1.10 ,服务器发送多个 MSS 分段,客户端依次进行 ACK 确认。但在 No.237 的 Window 窗口明显持续降低至 436(可能是客户端的应用处理能力问题,使得窗口未能及时释放),由于接收窗口小于 1 个 MSS,使得服务器无法继续发送数据,直到客户端 No.238 发送的 Window 更新,之后服务器才继续发送数据。
故此处 3.26s 大延迟问题是 TCP Window 过小的原因,建议开启支持 TCP WS 或检查客户端性能解决低效率问题。
195ms
195ms 同样是来自于客户端的延迟,展开其中一个 No.570 数据帧前后,也是可以看到数据传输方向是服务器端 10.10.10.10 -> 客户端 192.168.1.10 ,服务器发送多个 MSS 分段,客户端依次进行 ACK 确认。
客户端 No.569 ACK 确认 No.553,但在收到服务器应用所发送数据的最后一个分段 No.554 (带有 PSH 标志位),由于延迟 ACK 的机制,客户端在等待服务器的第二个数据包到达,但是刚好是应用发送的最后一个分段,奇数问题~ 所以延迟确认约 200ms 左右,客户端才发送了 No.570 ACK 。
虽然看起来仅延迟了 200ms,但随着数据传输的进行,会产生很多次类似这样奇数包的接收延迟确认(以下 No.632 同样),所以加总起来也是一段比较大的空闲等待时间。实际上延迟确认本身并没有什么问题,但视实际应用场景,也是可以通过设置像是 TCP_QUICKACK 选项来取消延迟确认。
延迟 ACK参考
TCP Delayed ACK(延迟确认)为了努力改善网络性能,它将几个 ACK 响应组合合在一起成为单个响应,或者将 ACK 响应与响应数据一起发送给对方,从而减少协议开销。 具体的做法:
当有响应数据要发送时,ACK 会随响应数据立即发送给对方;
如果没有响应数据,ACK 将会延迟发送,以等待看是否有响应数据可以一起发送;
如果在等待发送 ACK 期间,对方的第二个数据包又到达了,这时要立即发送 ACK。但是如果对方的三个数据包相继到达,第三个数据段到达时是否立即发送 ACK,则取决于以上两条。
感谢各位的阅读,以上就是“Wireshark TS系统吞吐慢问题如何解决”的内容了,经过本文的学习后,相信大家对Wireshark TS系统吞吐慢问题如何解决这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是编程网,小编将为大家推送更多相关知识点的文章,欢迎关注!