网站开发需要数据库技术搜索引擎优化策略不包括

问题背景

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

就像本次 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 开始的传输规律，分析如下：

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%）。

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

问题总结

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