Wireshark TS系统吞吐慢问题解决方案

摘要： 问题背景用户反馈一个场景，说是两个系统之间的吞吐很慢。吞吐量是系统性能分析中一个很重要的衡量指标，相关影响的因素也会有很多，因此反映在网络数据包分析上，也会是一个相对比较复杂的分析...

?=问题背景

用户反馈一个场景，说是两个系统之间的吞吐很慢。吞吐量是系统性能分析中一个很重要的衡量指标，相关影响的因素也会有很多，因此反映在网络数据包分析上，也会是一个相对比较复杂的分析过程。

案例取自 SharkFest 2010《Packet Trace Whispering》

问题信息

跟踪文件基本信息如下：

λ cAPInfos EvilOddFinal.pCAP File name:   EvilOddFinal.pcap File type:   Wireshark/TCPdump/... - pcap File encapsulatiON:  Ethe.net File timestamp precision:  microseconds (6) Packet size limit:   file hdr: 8192 bytes Packet size limit:   inferred: 64 bytes Number of packeTS:   1004 File size:   80 kB Data size:   1109 kB Capture duration:6.013219 seconds First packet time:   2010-01-13 04:55:32.247712 Last packet time:2010-01-13 04:55:38.260931 Data byte rate:  184 kBps Data bit rate:   1475 kbps Average packet size: 1104.69 bytes Average packet rate: 166 packets/s SHA256:  19cc103f13f74f8c3359f99c5ff883cce880361c823ff736c4b6d89d26e68b9e RIPEMD160:   d879ea22aaff08a5b7a44ecd68b86cb71053bf46 SHA1:afc170ee286153a9d9ce8dd19a9a4fe27d3Df46b Strict time order:   True Number of interfaces in file: 1 interface #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 三次握手信息 。

简要分析如下：

由于该 TCP Stream 不支持 WS 和 SACK ，此处的低效率可能会是一个问题。

考虑到整体传输速率低以及 I/O Graph 图示结果，可以增加 frame.time_delta_DIsplayed 信息列，检查数据帧之间的时间间隔，并从大到小依次排序。

可见有明显的一些大延迟，包括最大的 3.26s，多个 195ms 等等，依次分析：

来自于客户端 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 同样是来自于客户端的延迟，展开其中一个 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 响应与响应数据一起发送给对方，从而减少协议开销。 具体的做法：

问题总结

所以总体来说，系统吞吐慢，不一定全是网络拥塞、丢包所产生的问题，TCP 窗口以及协议层面的一些机制，同样也有可能是原因所在。

以上就是Wireshark TS系统吞吐慢问题解决方案的详细内容，更多关于Wireshark TS系统吞吐的资料请关注云初冀北其它相关文章！

本站提供的资源，都来自网络，版权争议与本站无关，所有内容及软件的文章仅限用于学习和研究目的。不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负，我们不保证内容的长久可用性，通过使用本站内容随之而来的风险与本站无关，您必须在下载后的24个小时之内，从您的电脑/手机中彻底删除上述内容。如果您喜欢该程序，请支持正版软件，购买注册，得到更好的正版服务。侵删请致信E-mail：Goliszhou@gmail.com