Wireshark?TS系統(tǒng)吞吐慢問(wèn)題如何解決

這篇文章主要講解了“Wireshark TS系統(tǒng)吞吐慢問(wèn)題如何解決”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Wireshark TS系統(tǒng)吞吐慢問(wèn)題如何解決”吧！

問(wèn)題背景

用戶(hù)反饋一個(gè)場(chǎng)景，說(shuō)是兩個(gè)系統(tǒng)之間的吞吐很慢。吞吐量是系統(tǒng)性能分析中一個(gè)很重要的衡量指標(biāo)，相關(guān)影響的因素也會(huì)有很多，因此反映在網(wǎng)絡(luò)數(shù)據(jù)包分析上，也會(huì)是一個(gè)相對(duì)比較復(fù)雜的分析過(guò)程。

問(wèn)題信息

跟蹤文件基本信息如下：

λ 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 上通過(guò) tcpdump 所捕獲，數(shù)據(jù)包數(shù)量 1004 個(gè)，長(zhǎng)度截?cái)酁?64 字節(jié)，文件數(shù)據(jù)大小 1109K 字節(jié)，捕獲時(shí)長(zhǎng)約 6 秒，平均速率 1475 kbps。

專(zhuān)家信息如下，異常簡(jiǎn)潔，可以看到?jīng)]有任何一條 Warning 信息，像是重傳、亂序等，在簡(jiǎn)單排除些常見(jiàn)性問(wèn)題之后，真實(shí)原因就需要進(jìn)一步實(shí)際分析了。

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

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

問(wèn)題分析

展開(kāi)數(shù)據(jù)包跟蹤文件的主視圖，首先是 TCP 三次握手信息 。

簡(jiǎn)要分析如下：

• IRTT 0.000339 秒，判斷在一個(gè)局域網(wǎng)內(nèi)；

• 考慮到 SYN、SYN/ACK、ACK 的時(shí)間差，判斷抓包點(diǎn)在服務(wù)器或者靠近服務(wù)器的地方；

• 客戶(hù)端 Win 64512，不支持 WS（Window Scale 因子）；服務(wù)器 Win 32768 ，也不支持 WS；

• 客戶(hù)端和服務(wù)器 MSS 均為 1460，標(biāo)準(zhǔn)值；

• 客戶(hù)端和服務(wù)器不支持 SACK 等；

• 客戶(hù)端和服務(wù)器不支持時(shí)間戳。

由于該 TCP Stream 不支持 WS 和 SACK ，此處的低效率可能會(huì)是一個(gè)問(wèn)題。

考慮到整體傳輸速率低以及 I/O Graph 圖示結(jié)果，可以增加 frame.time_delta_displayed 信息列，檢查數(shù)據(jù)幀之間的時(shí)間間隔，并從大到小依次排序。

可見(jiàn)有明顯的一些大延遲，包括最大的 3.26s，多個(gè) 195ms 等等，依次分析：

• 3.26s

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

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

故此處 3.26s 大延遲問(wèn)題是 TCP Window 過(guò)小的原因，建議開(kāi)啟支持 TCP WS 或檢查客戶(hù)端性能解決低效率問(wèn)題。

• 195ms

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

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

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

延遲 ACK參考

TCP Delayed ACK（延遲確認(rèn)）為了努力改善網(wǎng)絡(luò)性能，它將幾個(gè) ACK 響應(yīng)組合合在一起成為單個(gè)響應(yīng)，或者將 ACK 響應(yīng)與響應(yīng)數(shù)據(jù)一起發(fā)送給對(duì)方，從而減少協(xié)議開(kāi)銷(xiāo)。 具體的做法：

• 當(dāng)有響應(yīng)數(shù)據(jù)要發(fā)送時(shí)，ACK 會(huì)隨響應(yīng)數(shù)據(jù)立即發(fā)送給對(duì)方；

• 如果沒(méi)有響應(yīng)數(shù)據(jù)，ACK 將會(huì)延遲發(fā)送，以等待看是否有響應(yīng)數(shù)據(jù)可以一起發(fā)送；

• 如果在等待發(fā)送 ACK 期間，對(duì)方的第二個(gè)數(shù)據(jù)包又到達(dá)了，這時(shí)要立即發(fā)送 ACK。但是如果對(duì)方的三個(gè)數(shù)據(jù)包相繼到達(dá)，第三個(gè)數(shù)據(jù)段到達(dá)時(shí)是否立即發(fā)送 ACK，則取決于以上兩條。

感謝各位的閱讀，以上就是“Wireshark TS系統(tǒng)吞吐慢問(wèn)題如何解決”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Wireshark TS系統(tǒng)吞吐慢問(wèn)題如何解決這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！