Wireshark TS | MQ 传输缓慢问题

admin 2023年1月1日15:03:55安全工具评论1 views2474字阅读8分14秒阅读模式

2022年最后一篇,期待2023年。


问题背景
应用传输慢是一种比较常见的问题,慢在哪,为什么慢,有时候光从网络数据包分析方面很难回答的一清二楚,毕竟不同的技术方向专业性太强,全栈大佬只能仰望,而我们能做到的是在专注于自身的专业方向之外,尽量扩展知识面,学会找出问题的规律,并提出可能的解决建议。
就像本次 MQ 案例一样,说实话我对 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 相关信息,可见传输缓慢的问题并不是常见的丢包导致重传所引起。

Wireshark TS | MQ 传输缓慢问题


问题分析

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

Wireshark TS | MQ 传输缓慢问题


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

Wireshark TS | MQ 传输缓慢问题


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

Wireshark TS | MQ 传输缓慢问题


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

Wireshark TS | 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),如此不断反复。

Wireshark TS | MQ 传输缓慢问题


Wireshark TS | MQ 传输缓慢问题


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

  1. 2 MSS + 1 小于 MSS,固定发送数据规律;

  2. 延迟确认 99ms 规律;

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


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

Wireshark TS | MQ 传输缓慢问题


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

Wireshark TS | MQ 传输缓慢问题


问题总结

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



Wireshark TS | 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 系列 合集
如需交流,可后台直接留言,我会在第一时间回复,谢谢!
Wireshark TS | MQ 传输缓慢问题

原文始发于微信公众号(Echo Reply):Wireshark TS | MQ 传输缓慢问题

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年1月1日15:03:55
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  Wireshark TS | MQ 传输缓慢问题 http://cn-sec.com/archives/1491337.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: