Wireshark TS | MQ 传输缓慢问题

案例取自 SharkFest 2010《Wireshark in the Large Enterprise》

λ capinfos B2BXfer.pcapFile name:           B2BXfer.pcapFile type:           Wireshark/tcpdump/... - pcapFile encapsulation:  EthernetFile timestamp precision:  microseconds (6)Packet size limit:   file hdr: 8192 bytesPacket size limit:   inferred: 55 bytesNumber of packets:   810File size:           57 kBData size:           702 kBCapture duration:    162.247000 secondsFirst packet time:   2007-09-26 17:16:57.337002Last packet time:    2007-09-26 17:19:39.584002Data byte rate:      4332 bytes/sData bit rate:       34 kbpsAverage packet size: 867.85 bytesAverage packet rate: 4 packets/sSHA256:              dfbebcc56cd4a5ccfa42ed455daaa8e3ad4e21bcf91be01f5069afbb5271ee15RIPEMD160:           aac286e82a30280f229055b711810f9c27809305SHA1:                0d23af488435de254906ad7be75485d0ad8101e9Strict 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 = 810

跟踪文件在 linux 上通过 tcpdump 所捕获，数据包数量 810 个，长度截断为 55 字节，文件数据大小 702k 字节，捕获时长 162.247 秒，平均速率 34k bps。

专家信息如下，可以看到异常的简洁，没有 Warning 相关信息，可见传输缓慢的问题并不是常见的丢包导致重传所引起。

问题分析

展开数据包跟踪文件实际信息如下：

首先是 TCP 三次握手，IRTT 约0.099s，另通过 TTL 64 可知，捕获点在服务器端上或者靠近服务器端的地方。

由于数据包文件截断为 55 字节的原因，所以像是 TCP SYN 数据包中的 TCP Options 字段实际仅有 1 字节显示，这也是每个数据包会显示 [Packet size limited during capture] 的原因。而这样的设置其实也可大致判断，这个传输慢并非 TCP 窗口之类的问题，像是接收窗口满等。

既然说是传输缓慢，那么使用统计中的一些图形展示会更加清楚，如下所示可以看到 I/O 图，显示的传输速率在一定时间后呈现一条笔直的横线，约 35k bps，这说明整个 MQ 传输是以一个极其规律的方式来交互，慢也有慢的规律不是。。。

通过点选 I/O 图中的散点，定位到从 No.16 开始的传输规律，分析如下：

1. 客户端 192.168.1.1 一次性会发送三个数据分段，长度分别为 1434、1434 和 1410，可大致判断出 MSS 为 1380（1434-54），因此是两个 MSS + 一个以 PSH 标记的数据分段（不到一个 MSS 长度）；

2. 服务器端 10.10.10.10 在连续收到两个 MSS 数据分段后，会立马触发出一个 ACK 确认，但在收到最后一个 PSH/ACK 的数据分段后，在有 Delayed ACK 的情况下，延迟确认约 99ms；

3. 在服务器端第二个 ACK 返回至客户端后，客户端会等待约 800ms （900ms - IRTT 约 100ms）才会再次发送下一次数据分段（1434、1434 和 1410），如此不断反复。

因此在整个数据传输交互过程中，可以看出有三个规律：

1. 2 MSS + 1 小于 MSS，固定发送数据规律；

2. 延迟确认 99ms 规律；

3. 等待 800ms 间隔发送规律。

不要小看 ms，一次传输如此，次次传输也如此，时间一长，整体的传输效率自然相当低下。通过 Delta Time 从大到小排序，接近 160 个 900+ms 延迟（总数据包才 810 个，近 20%）。

通过 TCPTrace 图，更容易看到数据包的传输规律，一图胜千言。

问题总结

总之，网络数据包分析可以清楚传输缓慢问题所在，慢在哪，至于为什么是这样的传输规律（MQ 发送），这还得回归到 MQ 应用上的专业方向。还是那句话，最后可能无法确定根因，但网络数据包分析可以为我们指明正确的方向。

往期推荐

1. Wireshark 提示和技巧 | 捕获点之 TCP 三次握手

2. Wireshark 提示和技巧 | a == ${a} 显示过滤宏

3. Wireshark TS | 系统吞吐慢问题

4. Wireshark TS | 消失的 TCP DUP ACK

5. 网络设备 MTU MSS Jumboframe 全解

后台回复「TT」获取 Wireshark 提示和技巧系列 合集

后台回复「TS」获取 Wireshark Troubleshooting 系列 合集

如需交流，可后台直接留言，我会在第一时间回复，谢谢！

原文始发于微信公众号（Echo Reply）：Wireshark TS | MQ 传输缓慢问题