Wireshark?TS系統(tǒng)吞吐慢問題解決方案

更新時間：2023年03月05日 10:57:01 作者：7ACE

這篇文章主要為大家介紹了Wireshark?TS系統(tǒng)吞吐慢問題解決方案詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

問題背景

用戶反饋一個場景，說是兩個系統(tǒng)之間的吞吐很慢。吞吐量是系統(tǒng)性能分析中一個很重要的衡量指標，相關影響的因素也會有很多，因此反映在網絡數(shù)據包分析上，也會是一個相對比較復雜的分析過程。

案例取自 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 所捕獲，數(shù)據包數(shù)量 1004 個，長度截斷為 64 字節(jié)，文件數(shù)據大小 1109K 字節(jié)，捕獲時長約 6 秒，平均速率 1475 kbps。

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

此外統(tǒng)計 - 會話信息如下，僅有一條 TCP 流，數(shù)據主要傳輸?shù)姆较蚴?10.10.10.10 -> 192.168.1.10，速率低，僅為 1451 kbps，確實符合吞吐慢的現(xiàn)象。

同樣統(tǒng)計 - I/O Graphs 如下，有比較明顯一段時間，前后沒有任何數(shù)據傳輸，整體速率低。

問題分析

展開數(shù)據包跟蹤文件的主視圖，首先是 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 信息列，檢查數(shù)據幀之間的時間間隔，并從大到小依次排序。

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

3.26s

來自于客戶端 No.238 數(shù)據幀，Wireshark 也明顯的指示出這是一個 TCP Window Update 數(shù)據包，為客戶端的 Window 更新。

定位到 No.238 前后，可以看到數(shù)據傳輸方向是服務器端 10.10.10.10 -> 客戶端 192.168.1.10 ，服務器發(fā)送多個 MSS 分段，客戶端依次進行 ACK 確認。但在 No.237 的 Window 窗口明顯持續(xù)降低至 436（可能是客戶端的應用處理能力問題，使得窗口未能及時釋放），由于接收窗口小于 1 個 MSS，使得服務器無法繼續(xù)發(fā)送數(shù)據，直到客戶端 No.238 發(fā)送的 Window 更新，之后服務器才繼續(xù)發(fā)送數(shù)據。

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

195ms

195ms 同樣是來自于客戶端的延遲，展開其中一個 No.570 數(shù)據幀前后，也是可以看到數(shù)據傳輸方向是服務器端 10.10.10.10 -> 客戶端 192.168.1.10 ，服務器發(fā)送多個 MSS 分段，客戶端依次進行 ACK 確認。

客戶端 No.569 ACK 確認 No.553，但在收到服務器應用所發(fā)送數(shù)據的最后一個分段 No.554 （帶有 PSH 標志位），由于延遲 ACK 的機制，客戶端在等待服務器的第二個數(shù)據包到達，但是剛好是應用發(fā)送的最后一個分段，奇數(shù)問題~ 所以延遲確認約 200ms 左右，客戶端才發(fā)送了 No.570 ACK 。

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

延遲 ACK參考

TCP Delayed ACK（延遲確認）為了努力改善網絡性能，它將幾個 ACK 響應組合合在一起成為單個響應，或者將 ACK 響應與響應數(shù)據一起發(fā)送給對方，從而減少協(xié)議開銷。具體的做法：

當有響應數(shù)據要發(fā)送時，ACK 會隨響應數(shù)據立即發(fā)送給對方；
如果沒有響應數(shù)據，ACK 將會延遲發(fā)送，以等待看是否有響應數(shù)據可以一起發(fā)送；
如果在等待發(fā)送 ACK 期間，對方的第二個數(shù)據包又到達了，這時要立即發(fā)送 ACK。但是如果對方的三個數(shù)據包相繼到達，第三個數(shù)據段到達時是否立即發(fā)送 ACK，則取決于以上兩條。