Wireshark TS系統吞吐慢問題解決方案

問題背景

使用者反饋一個場景，說是兩個系統之間的吞吐很慢。吞吐量是系統效能分析中一個很重要的衡量指標，相關影響的因素也會有很多，因此反映在網路封包分析上，也會是一個相對比較複雜的分析過程。

案例取自 SharkFest 2010《Packet Trace Whispering》

問題資訊

跟蹤檔案基本資訊如下：

λ capinfos EvilOddFinal.pcap
File name:           EvilOddFinal.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: 64 bytes
Number of packets:   1004
File size:           80 kB
Data size:           1109 kB
Capture duration:    6.013219 seconds
First packet time:   2010-01-13 04:55:32.247712
Last packet time:    2010-01-13 04:55:38.260931
Data byte rate:      184 kBps
Data bit rate:       1475 kbps
Average packet size: 1104.69 bytes
Average packet rate: 166 packets/s
SHA256:              19cc103f13f74f8c3359f99c5ff883cce880361c823ff736c4b6d89d26e68b9e
RIPEMD160:           d879ea22aaff08a5b7a44ecd68b86cb71053bf46
SHA1:                afc170ee286153a9d9ce8dd19a9a4fe27d3df46b
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 = 1004
λ

跟蹤檔案在 linux 上通過 tcpdump 所捕獲，封包數量 1004 個，長度截斷為 64 位元組，檔案資料大小 1109K 位元組，捕獲時長約 6 秒，平均速率 1475 kbps。

專家資訊如下，異常簡潔，可以看到沒有任何一條 Warning 資訊，像是重傳、亂序等，在簡單排除些常見性問題之後，真實原因就需要進一步實際分析了。

此外統計 - 對談資訊如下，僅有一條 TCP 流，資料主要傳輸的方向是 10.10.10.10 -> 192.168.1.10，速率低，僅為 1451 kbps，確實符合吞吐慢的現象。

同樣統計 - I/O Graphs 如下，有比較明顯一段時間，前後沒有任何資料傳輸，整體速率低。

問題分析

展開封包跟蹤檔案的主檢視，首先是 TCP 三次握手資訊 。

簡要分析如下：

• IRTT 0.000339 秒，判斷在一個區域網內；
• 考慮到 SYN、SYN/ACK、ACK 的時間差，判斷抓包點在伺服器或者靠近伺服器的地方；
• 使用者端 Win 64512，不支援 WS（Window Scale 因子）；伺服器 Win 32768 ，也不支援 WS；
• 使用者端和伺服器 MSS 均為 1460，標準值；
• 使用者端和伺服器不支援 SACK 等；
• 使用者端和伺服器不支援時間戳。

由於該 TCP Stream 不支援 WS 和 SACK ，此處的低效率可能會是一個問題。

考慮到整體傳輸速率低以及 I/O Graph 圖示結果，可以增加 frame.time_delta_displayed 資訊列，檢查資料框之間的時間間隔，並從大到小依次排序。

可見有明顯的一些大延遲，包括最大的 3.26s，多個 195ms 等等，依次分析：

• 3.26s

來自於使用者端 No.238 資料框，Wireshark 也明顯的指示出這是一個 TCP Window Update 封包，為使用者端的 Window 更新。

定位到 No.238 前後，可以看到資料傳輸方向是伺服器端 10.10.10.10 -> 使用者端 192.168.1.10 ，伺服器傳送多個 MSS 分段，使用者端依次進行 ACK 確認。但在 No.237 的 Window 視窗明顯持續降低至 436（可能是使用者端的應用處理能力問題，使得視窗未能及時釋放），由於接收視窗小於 1 個 MSS，使得伺服器無法繼續傳送資料，直到使用者端 No.238 傳送的 Window 更新，之後伺服器才繼續傳送資料。

故此處 3.26s 大延遲問題是 TCP Window 過小的原因，建議開啟支援 TCP WS 或檢查使用者端效能解決低效率問題。

• 195ms

195ms 同樣是來自於使用者端的延遲，展開其中一個 No.570 資料框前後，也是可以看到資料傳輸方向是伺服器端 10.10.10.10 -> 使用者端 192.168.1.10 ，伺服器傳送多個 MSS 分段，使用者端依次進行 ACK 確認。

使用者端 No.569 ACK 確認 No.553，但在收到伺服器應用所傳送資料的最後一個分段 No.554 （帶有 PSH 標誌位），由於延遲 ACK 的機制，使用者端在等待伺服器的第二個封包到達，但是剛好是應用傳送的最後一個分段，奇數問題~ 所以延遲確認約 200ms 左右，使用者端才傳送了 No.570 ACK 。

雖然看起來僅延遲了 200ms，但隨著資料傳輸的進行，會產生很多次類似這樣奇數包的接收延遲確認（以下 No.632 同樣），所以加總起來也是一段比較大的空閒等待時間。實際上延遲確認本身並沒有什麼問題，但視實際應用場景，也是可以通過設定像是 TCP_QUICKACK 選項來取消延遲確認。

延遲 ACK參考

TCP Delayed ACK（延遲確認）為了努力改善網路效能，它將幾個 ACK 響應組合合在一起成為單個響應，或者將 ACK 響應與響應資料一起傳送給對方，從而減少協定開銷。 具體的做法：

• 當有響應資料要傳送時，ACK 會隨響應資料立即傳送給對方；
• 如果沒有響應資料，ACK 將會延遲傳送，以等待看是否有響應資料可以一起傳送；
• 如果在等待傳送 ACK 期間，對方的第二個封包又到達了，這時要立即傳送 ACK。但是如果對方的三個封包相繼到達，第三個資料段到達時是否立即傳送 ACK，則取決於以上兩條。

問題總結

所以總體來說，系統吞吐慢，不一定全是網路擁塞、丟包所產生的問題，TCP 視窗以及協定層面的一些機制，同樣也有可能是原因所在。

以上就是Wireshark TS系統吞吐慢問題解決方案的詳細內容，更多關於Wireshark TS系統吞吐的資料請關注it145.com其它相關文章！