溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Wireshark TS系統吞吐慢問題如何解決”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Wireshark TS系統吞吐慢問題如何解決”吧！
用戶反饋一個場景，說是兩個系統之間的吞吐很慢。吞吐量是系統性能分析中一個很重要的衡量指標，相關影響的因素也會有很多，因此反映在網絡數據包分析上，也會是一個相對比較復雜的分析過程。
跟蹤文件基本信息如下：
λ 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，則取決于以上兩條。
感謝各位的閱讀，以上就是“Wireshark TS系統吞吐慢問題如何解決”的內容了，經過本文的學習后，相信大家對Wireshark TS系統吞吐慢問題如何解決這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
