問題背景

應用傳輸慢是一種比較常見的問題，慢在哪，為什么慢，有時候光從網(wǎng)絡數(shù)據(jù)包分析方面很難回答的一清二楚，畢竟不同的技術方向?qū)I(yè)性太強，全棧大佬只能仰望，而我們能做到的是在專注于自身的專業(yè)方向之外，盡量擴展知識面，學會找出問題的規(guī)律，并提出可能的解決建議。

就像本次 MQ 案例一樣，說實話我對 MQ 一無所知，但并不會讓我們在拿到相關數(shù)據(jù)包跟蹤文件后無從下手，總還是有解題思路，并能找到一定規(guī)律的。

案例取自 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 所捕獲，數(shù)據(jù)包數(shù)量 810 個，長度截斷為 55 字節(jié)，文件數(shù)據(jù)大小 702k 字節(jié)，捕獲時長 162.247 秒，平均速率 34k bps。

專家信息如下，可以看到異常的簡潔，沒有 Warning 相關信息，可見傳輸緩慢的問題并不是常見的丟包導致重傳所引起。

問題分析

展開數(shù)據(jù)包跟蹤文件實際信息如下：

首先是 TCP 三次握手，IRTT 約0.099s，另通過 TTL 64 可知，捕獲點在服務器端上或者靠近服務器端的地方。

由于數(shù)據(jù)包文件截斷為 55 字節(jié)的原因，所以像是 TCP SYN 數(shù)據(jù)包中的 TCP Options 字段實際僅有 1 字節(jié)顯示，這也是每個數(shù)據(jù)包會顯示 [Packet size limited during capture] 的原因。而這樣的設置其實也可大致判斷，這個傳輸慢并非 TCP 窗口之類的問題，像是接收窗口滿等。

既然說是傳輸緩慢，那么使用統(tǒng)計中的一些圖形展示會更加清楚，如下所示可以看到 I/O 圖，顯示的傳輸速率在一定時間后呈現(xiàn)一條筆直的橫線，約 35k bps，這說明整個 MQ 傳輸是以一個極其規(guī)律的方式來交互，慢也有慢的規(guī)律不是。。。

通過點選 I/O 圖中的散點，定位到從 No.16 開始的傳輸規(guī)律，分析如下：

1. 客戶端 192.168.1.1 一次性會發(fā)送三個數(shù)據(jù)分段，長度分別為 1434、1434 和 1410，可大致判斷出 MSS 為 1380（1434-54），因此是兩個 MSS + 一個以 PSH 標記的數(shù)據(jù)分段（不到一個 MSS 長度）；
2. 服務器端 10.10.10.10 在連續(xù)收到兩個 MSS 數(shù)據(jù)分段后，會立馬觸發(fā)出一個 ACK 確認，但在收到最后一個 PSH/ACK 的數(shù)據(jù)分段后，在有 Delayed ACK 的情況下，延遲確認約 99ms；
3. 在服務器端第二個 ACK 返回至客戶端后，客戶端會等待約 800ms（900ms - IRTT 約 100ms）才會再次發(fā)送下一次數(shù)據(jù)分段（1434、1434 和 1410），如此不斷反復。

因此在整個數(shù)據(jù)傳輸交互過程中，可以看出有三個規(guī)律：

1. 2 MSS + 1 小于 MSS，固定發(fā)送數(shù)據(jù)規(guī)律；
2. 延遲確認 99ms 規(guī)律；
3. 等待 800ms 間隔發(fā)送規(guī)律。

不要小看 ms，一次傳輸如此，次次傳輸也如此，時間一長，整體的傳輸效率自然相當?shù)拖隆Ｍㄟ^ Delta Time 從大到小排序，接近 160 個 900+ms 延遲（總數(shù)據(jù)包才 810 個，近 20%）。

通過 TCP Trace 圖，更容易看到數(shù)據(jù)包的傳輸規(guī)律，一圖勝千言。

問題總結(jié)

總之，網(wǎng)絡數(shù)據(jù)包分析可以清楚傳輸緩慢問題所在，慢在哪，至于為什么是這樣的傳輸規(guī)律（MQ 發(fā)送），這還得回歸到 MQ 應用上的專業(yè)方向。還是那句話，最后可能無法確定根因，但網(wǎng)絡數(shù)據(jù)包分析可以為我們指明正確的方向。