Wireshark TS | MQ 传输缓慢问题

2023年 9月 22日 40.5k 0

问题背景

应用传输慢是一种比较常见的问题,慢在哪,为什么慢,有时候光从网络数据包分析方面很难回答的一清二楚,毕竟不同的技术方向专业性太强,全栈大佬只能仰望,而我们能做到的是在专注于自身的专业方向之外,尽量扩展知识面,学会找出问题的规律,并提出可能的解决建议。

就像本次 MQ 案例一样,说实话我对 MQ 一无所知,但并不会让我们在拿到相关数据包跟踪文件后无从下手,总还是有解题思路,并能找到一定规律的。

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

问题信息

跟踪文件基本信息如下:

λ capinfos B2BXfer.pcap
File name:           B2BXfer.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 8192 bytes
Packet size limit:   inferred: 55 bytes
Number of packets:   810
File size:           57 kB
Data size:           702 kB
Capture duration:    162.247000 seconds
First packet time:   2007-09-26 17:16:57.337002
Last packet time:    2007-09-26 17:19:39.584002
Data byte rate:      4332 bytes/s
Data bit rate:       34 kbps
Average packet size: 867.85 bytes
Average packet rate: 4 packets/s
SHA256:              dfbebcc56cd4a5ccfa42ed455daaa8e3ad4e21bcf91be01f5069afbb5271ee15
RIPEMD160:           aac286e82a30280f229055b711810f9c27809305
SHA1:                0d23af488435de254906ad7be75485d0ad8101e9
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 = 810

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

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

image.png

问题分析

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

image.png

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

image.png

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

image.png

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

image.png

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

  • 客户端 192.168.1.1 一次性会发送三个数据分段,长度分别为 1434、1434 和 1410,可大致判断出 MSS 为 1380(1434-54),因此是两个 MSS + 一个以 PSH 标记的数据分段(不到一个 MSS 长度);
  • 服务器端 10.10.10.10 在连续收到两个 MSS 数据分段后,会立马触发出一个 ACK 确认,但在收到最后一个 PSH/ACK 的数据分段后,在有 Delayed ACK 的情况下,延迟确认约 99ms;
  • 在服务器端第二个 ACK 返回至客户端后,客户端会等待约 800ms(900ms - IRTT 约 100ms)才会再次发送下一次数据分段(1434、1434 和 1410),如此不断反复。
  • image.png

    image.png

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

  • 2 MSS + 1 小于 MSS,固定发送数据规律;
  • 延迟确认 99ms 规律;
  • 等待 800ms 间隔发送规律。
  • 不要小看 ms,一次传输如此,次次传输也如此,时间一长,整体的传输效率自然相当低下。通过 Delta Time 从大到小排序,接近 160 个 900+ms 延迟(总数据包才 810 个,近 20%)。

    image.png

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

    image.png

    问题总结

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

    相关文章

    JavaScript2024新功能:Object.groupBy、正则表达式v标志
    PHP trim 函数对多字节字符的使用和限制
    新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
    使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
    为React 19做准备:WordPress 6.6用户指南
    如何删除WordPress中的所有评论

    发布评论