网站开发7个基本流程,wordpress中文标题,动漫设计难不难学,wordpress替换本地字体问题背景
应用传输慢是一种比较常见的问题#xff0c;慢在哪#xff0c;为什么慢#xff0c;有时候光从网络数据包分析方面很难回答的一清二楚#xff0c;毕竟不同的技术方向专业性太强#xff0c;全栈大佬只能仰望#xff0c;而我们能做到的是在专注于自身的专业方向之…问题背景
应用传输慢是一种比较常见的问题慢在哪为什么慢有时候光从网络数据包分析方面很难回答的一清二楚毕竟不同的技术方向专业性太强全栈大佬只能仰望而我们能做到的是在专注于自身的专业方向之外尽量扩展知识面学会找出问题的规律并提出可能的解决建议。
就像本次 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 8192Time precision microseconds (6)Time ticks per second 1000000Number of stat entries 0Number 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 开始的传输规律分析如下
客户端 192.168.1.1 一次性会发送三个数据分段长度分别为 1434、1434 和 1410可大致判断出 MSS 为 13801434-54因此是两个 MSS 一个以 PSH 标记的数据分段不到一个 MSS 长度服务器端 10.10.10.10 在连续收到两个 MSS 数据分段后会立马触发出一个 ACK 确认但在收到最后一个 PSH/ACK 的数据分段后在有 Delayed ACK 的情况下延迟确认约 99ms在服务器端第二个 ACK 返回至客户端后客户端会等待约 800ms900ms - IRTT 约 100ms才会再次发送下一次数据分段1434、1434 和 1410如此不断反复。 因此在整个数据传输交互过程中可以看出有三个规律
2 MSS 1 小于 MSS固定发送数据规律延迟确认 99ms 规律等待 800ms 间隔发送规律。
不要小看 ms一次传输如此次次传输也如此时间一长整体的传输效率自然相当低下。通过 Delta Time 从大到小排序接近 160 个 900ms 延迟总数据包才 810 个近 20%。 通过 TCP Trace 图更容易看到数据包的传输规律一图胜千言。 问题总结
总之网络数据包分析可以清楚传输缓慢问题所在慢在哪至于为什么是这样的传输规律MQ 发送这还得回归到 MQ 应用上的专业方向。还是那句话最后可能无法确定根因但网络数据包分析可以为我们指明正确的方向。
