聊聊wireshark的進(jìn)階使用功能

作者：京東云開發(fā)者 2023-10-27 08:59:00

如果只是簡單的排查網(wǎng)絡(luò)問題，只需要使用wireshark中簡單的添加過濾規(guī)則，通過觀察抓取到的數(shù)據(jù)包就可以達(dá)到定位問題的目的，其實(shí)這幾個(gè)進(jìn)階的功能，無論是專家模式、還是IO圖表，底層其實(shí)還是需要配置規(guī)則，亦或者是通過wireshark的內(nèi)置規(guī)則做了一個(gè)集成。

1. 前言

emmm，說起網(wǎng)絡(luò)知識學(xué)習(xí)肯定離不來wireshark工具，這個(gè)工具能夠幫助我們快速地定位網(wǎng)絡(luò)問題以及幫助正在學(xué)習(xí)網(wǎng)絡(luò)協(xié)議這塊的知識的同學(xué)驗(yàn)證理論與實(shí)際的一大利器，平時(shí)更多的只是停留在初步的使用階段。也是利用部門內(nèi)部的網(wǎng)絡(luò)興趣小組的討論機(jī)會，私下對wireshark的一些進(jìn)階功能，比如專家模式、圖表等功能進(jìn)行調(diào)研，并結(jié)合實(shí)際場景抓包分析對功能進(jìn)行對照說明。

2. wireshark中的分析菜單——專家模式

2.1什么是專家模式？

Wireshark的專家信息是非常強(qiáng)大的一個(gè)分析模塊，分別對錯(cuò)誤、警告、注意、對話等數(shù)據(jù)信息做出分類和注釋，對網(wǎng)絡(luò)故障分析提供了強(qiáng)有力的信息依據(jù)，讓你準(zhǔn)確快速地判斷出故障點(diǎn)，并進(jìn)行下一步處理。

2.2 嚴(yán)重性級別的每種分類分別代表什么含義？

?對話（Chat）：關(guān)于正常通信的基本信息；

?注意（Note）：正常通信時(shí)的異常數(shù)據(jù)包；

?警告（Warn）：不是正常通信中的異常數(shù)據(jù)包（個(gè)人理解為：非正常的通信產(chǎn)生的數(shù)據(jù)包）；

?錯(cuò)誤（Error）：數(shù)據(jù)包中的錯(cuò)誤，或者解析器解析時(shí)的錯(cuò)誤；

2.3 除了嚴(yán)重性級別之外，專家信息項(xiàng)還按組進(jìn)行了分類：

?假設(shè)(Assumption)：協(xié)議字段的數(shù)據(jù)不完整，根據(jù)假定值進(jìn)行了剖析

?檢驗(yàn)和(Checksum)：校驗(yàn)和無效

?注釋(Comment)：數(shù)據(jù)包注釋

?調(diào)試(Debug)：調(diào)試信息，你不應(yīng)該在wireshark的發(fā)布版本中看到這個(gè)組

?解密(Decryption)：解密問題

?已棄用(Deprecated)：協(xié)議字段已經(jīng)被棄用

?畸形的(Malformed)：格式錯(cuò)誤的數(shù)據(jù)包或者解析程序有錯(cuò)誤。此數(shù)據(jù)報(bào)的解析已中止

?協(xié)議(Protocol)：違反協(xié)議規(guī)范(比如無效字段值或者非法長度)。可能會繼續(xù)對該數(shù)據(jù)包進(jìn)行解析

?重新組裝()：重新組裝時(shí)出現(xiàn)問題。比如，不是所有的碎片都可用，或者在重新組裝期間發(fā)生異常

?請求代碼(Request Code)：一個(gè)應(yīng)用程序請求。通常分配聊天級別。

?響應(yīng)代碼(Response Code)：應(yīng)用程序響應(yīng)代碼表示潛在問題，比如找不到HTTP 404

?安全(Security)：安全問題，比如不安全的實(shí)現(xiàn)

?序列(Sequence)：協(xié)議序列號可疑，比如它不連續(xù)或者檢測到重傳

?未編碼(Undecoded)：解析不完整或者數(shù)據(jù)因?yàn)槠渌麊栴}無法解碼

2.4 TCP的14種專家模式？

?對話消息（Chat）：

窗口更新（window update）：由接收者發(fā)送，用來通知發(fā)送者TCP接收窗口的大小已經(jīng)發(fā)生變化。

?注意消息（Note）：

? 重復(fù)ACK（Duplicate ACK ）：當(dāng)一臺主機(jī)沒有收到下一個(gè)期望序列號的數(shù)據(jù)包時(shí)，會生成最近一次收到的數(shù)據(jù)的重復(fù)ACK。

注意：其實(shí)重復(fù)確認(rèn)本身并不是問題，但如果接收方連續(xù)發(fā)送多個(gè)重復(fù)確認(rèn)，則可以視為網(wǎng)絡(luò)擁塞的信號。TCP協(xié)議中定義了一種擁塞控制機(jī)制，在發(fā)現(xiàn)網(wǎng)絡(luò)擁塞時(shí)會觸發(fā)這個(gè)機(jī)制，以減緩數(shù)據(jù)傳輸?shù)乃俣龋瑥亩苊鈸砣募觿　?nbsp;快速重傳：當(dāng)TCP接收方連續(xù)發(fā)送三個(gè)重復(fù)確認(rèn)時(shí)，發(fā)送方就會認(rèn)為一個(gè)數(shù)據(jù)包已經(jīng)丟失，并立即進(jìn)行快速重傳（Fast Retransmit）操作。它會重新發(fā)送那個(gè)沒有收到確認(rèn)的數(shù)據(jù)包，而不是等待超時(shí)時(shí)間后再重傳。這樣做可以盡快地填補(bǔ)丟失的數(shù)據(jù)包，提高數(shù)據(jù)傳輸速度和效率。

?TCP重傳（retransmission）：數(shù)據(jù)包丟失的結(jié)果。發(fā)生在收到重傳的ACK, 或者數(shù)據(jù)包的重傳計(jì)時(shí)器超時(shí)的時(shí)候。

?零窗口探查：在一個(gè)零窗口包被發(fā)送出去后，用來監(jiān)視TCP接收窗口的狀態(tài)。

?零窗口探查ACK：用來響應(yīng)零窗口探查數(shù)據(jù)包。

?保活（TCP Keep-Alive Segment ）：當(dāng)一個(gè)連接的保活數(shù)據(jù)出現(xiàn)時(shí)觸發(fā)。

?保活A(yù)CK(ACK to Tcp keep-alive)：用來響應(yīng)保活數(shù)據(jù)包。

?窗口已滿：用來通知傳輸主機(jī)接受者的TCP窗口已滿。

?警告信息(Warn):

?上一段丟失(Previous segments not captured)：指明數(shù)據(jù)包丟失。發(fā)生在當(dāng)數(shù)據(jù)流中一個(gè)期望序列號被跳過時(shí)。

?收到丟失數(shù)據(jù)包的ACK(ACKed segment that was not captured)：發(fā)生在當(dāng)一個(gè)數(shù)據(jù)包被確認(rèn)丟失但在之后收到了這個(gè)已經(jīng)被確認(rèn)丟失的數(shù)據(jù)包的ACK數(shù)據(jù)包。

?零窗口(TCP Zero Window)：當(dāng)接收方已經(jīng)達(dá)到TCP接收窗口大小時(shí)，發(fā)出一個(gè)零窗口通知，要求發(fā)送方停止傳輸數(shù)據(jù)。可能是網(wǎng)絡(luò)擁塞或接收方未及時(shí)處理數(shù)據(jù)等原因?qū)е碌摹?/p>

?亂序：當(dāng)數(shù)據(jù)包被亂序接收時(shí)，會利用序列號進(jìn)行檢測。

?快速重傳輸：一次重傳會在收到一個(gè)重復(fù)ACK的20毫秒內(nèi)進(jìn)行。

3. 統(tǒng)計(jì)菜單——IO圖表、數(shù)據(jù)流圖

3.1 IO圖表的用途？

Wireshark IO Graph能把原始數(shù)據(jù)過濾并把數(shù)據(jù)以圖表的形式展示出來，是一個(gè)非常好用的工具。基本的Wireshark IO Graph會顯示抓包文件中的整體流量情況。X軸為時(shí)間，Y軸是每一時(shí)間間隔的報(bào)文數(shù)。默認(rèn)情況下，X軸時(shí)間單位為1s，Y軸是Packet/tick，可以自己調(diào)節(jié)單位。通過調(diào)節(jié)單位，對于查看流量中的波峰／波谷很有幫助。

3.2 一些常用的排錯(cuò)過濾條件？

對于排查網(wǎng)絡(luò)延時(shí)/應(yīng)用問題有一些過濾條件是非常有用的，下面羅列了一些常用的過濾條件：

?tcp.analysis.lost_segment：表明已經(jīng)在抓包中看到不連續(xù)的序列號。報(bào)文丟失會造成重復(fù)的ACK，這會導(dǎo)致重傳。

?tcp.analysis.duplicate_ack：顯示被確認(rèn)過不止一次的報(bào)文。大量的重復(fù)ACK是TCP端點(diǎn)之間高延時(shí)的跡象。

?tcp.analysis.retransmission：顯示抓包中的所有重傳。如果重傳次數(shù)不多的話還是正常的，過多重傳可能有問題。這通常意味著應(yīng)用性能緩慢和/或用戶報(bào)文丟失。

?tcp.analysis.window_update：將傳輸過程中的TCP window大小圖形化。如果看到窗口大小下降為零，這意味著發(fā)送方已經(jīng)退出了，并等待接收方確認(rèn)所有已傳送數(shù)據(jù)。這可能表明接收端已經(jīng)不堪重負(fù)了。

?tcp.analysis.bytes_in_flight：某一時(shí)間點(diǎn)網(wǎng)絡(luò)上未確認(rèn)字節(jié)數(shù)。未確認(rèn)字節(jié)數(shù)不能超過你的TCP窗口大小（定義于最初3此TCP握手），為了最大化吞吐量你想要獲得盡可能接近TCP窗口大小。如果看到連續(xù)低于TCP窗口大小，可能意味著報(bào)文丟失或路徑上其他影響吞吐量的問題。

?tcp.analysis.ack_rtt：衡量抓取的TCP報(bào)文與相應(yīng)的ACK。如果這一時(shí)間間隔比較長那可能表示某種類型的網(wǎng)絡(luò)延時(shí)（報(bào)文丟失，擁塞，等等）。

3.3 IO圖表中的一些常用的函數(shù)？

IO Graphs有六個(gè)可用函數(shù)：SUM, MIN, AVG, MAX, COUNT, LOAD。

?MIN（）, AVG（）, MAX（）

MIN、AVG、MAX分別表示幀/報(bào)文之間的最小、平均、最大時(shí)間，對于查看幀/報(bào)文之間的延時(shí)非常有用。

我們可以將這些函數(shù)結(jié)合“frame.time_delta”過濾條件看清楚幀延時(shí)，并使得往返延時(shí)更為明顯。如果抓包文件中包含不同主機(jī)之間的多個(gè)會話，而只想知道其中一個(gè)pair，可將“frame.time_delta”結(jié)合源和目標(biāo)主機(jī)條件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。

從上圖可見，在第106秒時(shí)數(shù)據(jù)流的MAX frame.delta_time達(dá)到0.7秒，這是一個(gè)嚴(yán)重延時(shí)并且導(dǎo)致了報(bào)文丟失。

?Count（）

此函數(shù)計(jì)算時(shí)間間隔內(nèi)事件發(fā)生的次數(shù)，在查看TCP分析標(biāo)識符時(shí)很有用，例如重傳。

?Sum（）

該函數(shù)統(tǒng)計(jì)事件的累加值。有兩種常見的用例是看在捕獲TCP數(shù)據(jù)量，以及檢查TCP序列號。

參數(shù)設(shè)置：分別使用客戶端IP 192.168.1.4為源、目的地址，并將SUM功能結(jié)合tcp.len過濾條件；

從圖表中我們可以看到，發(fā)送到客戶端的數(shù)據(jù)量（IP.DST = = 192.168.1.4過濾條件）比來自客戶端的數(shù)據(jù)量要高。在圖中紅色表示。黑條顯示從客戶端到服務(wù)器的數(shù)據(jù)，相對數(shù)據(jù)量很小。這是有道理的，因?yàn)榭蛻糁皇钦埱笪募褪盏街蟀l(fā)送確認(rèn)數(shù)據(jù)，而服務(wù)器發(fā)送大文件。很重要的一點(diǎn)是，如果你交換了圖的順序，把客戶端的IP作為圖1的目標(biāo)地址，并且客戶端IP作為圖2的源地址，采用了FBAR的時(shí)候可能看不到正確的數(shù)據(jù)顯示。因?yàn)閳D編號越低表示在前臺顯示，可能會覆蓋較高圖號。