1. 前言
emmm,説起網絡知識學習肯定離不來wireshark工具,這個工具能夠幫助我們快速地定位網絡問題以及幫助正在學習網絡協議這塊的知識的同學驗證理論與實際的一大利器,平時更多的只是停留在初步的使用階段。也是利用部門內部的網絡興趣小組的討論機會,私下對wireshark的一些進階功能,比如專家模式、圖表等功能進行調研,並結合實際場景抓包分析對功能進行對照説明。
2. wireshark中的分析菜單——專家模式
2.1什麼是專家模式?
Wireshark的專家信息是非常強大的一個分析模塊,分別對錯誤、警告、注意、對話等數據信息做出分類和註釋,對網絡故障分析提供了強有力的信息依據,讓你準確快速地判斷出故障點,並進行下一步處理。
2.2 嚴重性級別的每種分類分別代表什麼含義?
◦對話(Chat):關於正常通信的基本信息;
◦注意(Note):正常通信時的異常數據包;
◦警告(Warn):不是正常通信中的異常數據包(個人理解為:非正常的通信產生的數據包);
◦錯誤(Error):數據包中的錯誤,或者解析器解析時的錯誤;
2.3 除了嚴重性級別之外,專家信息項還按組進行了分類:
◦假設(Assumption):協議字段的數據不完整,根據假定值進行了剖析
◦檢驗和(Checksum):校驗和無效
◦註釋(Comment):數據包註釋
◦調試(Debug):調試信息,你不應該在wireshark的發佈版本中看到這個組
◦解密(Decryption):解密問題
◦已棄用(Deprecated):協議字段已經被棄用
◦畸形的(Malformed):格式錯誤的數據包或者解析程序有錯誤。此數據報的解析已中止
◦協議(Protocol):違反協議規範(比如無效字段值或者非法長度)。可能會繼續對該數據包進行解析
◦重新組裝():重新組裝時出現問題。比如,不是所有的碎片都可用,或者在重新組裝期間發生異常
◦請求代碼(Request Code):一個應用程序請求。通常分配聊天級別。
◦響應代碼(Response Code):應用程序響應代碼表示潛在問題,比如找不到HTTP 404
◦安全(Security):安全問題,比如不安全的實現
◦序列(Sequence):協議序列號可疑,比如它不連續或者檢測到重傳
◦未編碼(Undecoded):解析不完整或者數據因為其他問題無法解碼
2.4 TCP的14種專家模式?
◦對話消息(Chat):
窗口更新(window update)_:_由接收者發送,用來通知發送者TCP接收窗口的大小已經發生變化。
◦注意消息(Note):
▪ 重複ACK(Duplicate ACK )_:_當一台主機沒有收到下一個期望序列號的數據包時,會生成最近一次收到的數據的重複ACK。
注意:其實重複確認本身並不是問題,但如果接收方連續發送多個重複確認,則可以視為網絡擁塞的信號。TCP協議中定義了一種擁塞控制機制,在發現網絡擁塞時會觸發這個機制,以減緩數據傳輸的速度,從而避免擁塞的加劇。 快速重傳:當TCP接收方連續發送三個重複確認時,發送方就會認為一個數據包已經丟失,並立即進行快速重傳(Fast Retransmit)操作。它會重新發送那個沒有收到確認的數據包,而不是等待超時時間後再重傳。這樣做可以儘快地填補丟失的數據包,提高數據傳輸速度和效率。
▪TCP重傳(retransmission)_:_數據包丟失的結果。發生在收到重傳的ACK, 或者數據包的重傳計時器超時的時候。
▪零窗口探查_:_在一個零窗口包被髮送出去後,用來監視TCP接收窗口的狀態。
▪零窗口探查ACK:用來響應零窗口探查數據包。
▪保活(TCP Keep-Alive Segment):當一個連接的保活數據出現時觸發。
▪保活ACK(ACK to Tcp keep-alive):用來響應保活數據包。
▪窗口已滿:用來通知傳輸主機接受者的TCP窗口已滿。
•警告信息(Warn):
◦上一段丟失(Previous segments not captured):指明數據包丟失。發生在當數據流中一個期望序列號被跳過時。
◦收到丟失數據包的ACK(ACKed segment that was not captured):發生在當一個數據包被確認丟失但在之後收到了這個已經被確認丟失的數據包的ACK數據包。
◦零窗口(TCP Zero Window):當接收方已經達到TCP接收窗口大小時,發出一個零窗口通知,要求發送方停止傳輸數據。可能是網絡擁塞或接收方未及時處理數據等原因導致的。
◦亂序:當數據包被亂序接收時,會利用序列號進行檢測。
◦快速重傳輸:一次重傳會在收到一個重複ACK的20毫秒內進行。
3. 統計菜單——IO圖表、數據流圖
3.1 IO圖表的用途?
Wireshark IO Graph能把原始數據過濾並把數據以圖表的形式展示出來,是一個非常好用的工具。 基本的Wireshark IO Graph會顯示抓包文件中的整體流量情況。X軸為時間,Y軸是每一時間間隔的報文數。默認情況下,X軸時間單位為1s,Y軸是Packet/tick,可以自己調節單位。通過調節單位,對於查看流量中的波峯/波谷很有幫助。
3.2 一些常用的排錯過濾條件?
對於排查網絡延時/應用問題有一些過濾條件是非常有用的,下面羅列了一些常用的過濾條件:
◦tcp.analysis.lost_segment:表明已經在抓包中看到不連續的序列號。報文丟失會造成重複的ACK,這會導致重傳。
◦tcp.analysis.duplicate_ack:顯示被確認過不止一次的報文。大量的重複ACK是TCP端點之間高延時的跡象。
◦tcp.analysis.retransmission:顯示抓包中的所有重傳。如果重傳次數不多的話還是正常的,過多重傳可能有問題。這通常意味着應用性能緩慢和/或用户報文丟失。
◦tcp.analysis.window_update:將傳輸過程中的TCP window大小圖形化。如果看到窗口大小下降為零,這意味着發送方已經退出了,並等待接收方確認所有已傳送數據。這可能表明接收端已經不堪重負了。
◦tcp.analysis.bytes\_in\_flight:某一時間點網絡上未確認字節數。未確認字節數不能超過你的TCP窗口大小(定義於最初3此TCP握手),為了最大化吞吐量你想要獲得儘可能接近TCP窗口大小。如果看到連續低於TCP窗口大小,可能意味着報文丟失或路徑上其他影響吞吐量的問題。
◦tcp.analysis.ack_rtt:衡量抓取的TCP報文與相應的ACK。如果這一時間間隔比較長那可能表示某種類型的網絡延時(報文丟失,擁塞,等等)。
3.3 IO圖表中的一些常用的函數?
IO Graphs有六個可用函數:SUM, MIN, AVG, MAX, COUNT, LOAD。
◦MIN(), AVG(), MAX()
MIN、AVG、MAX分別表示幀/報文之間的最小、平均、最大時間,對於查看幀/報文之間的延時非常有用。
我們可以將這些函數結合“frame.time\_delta”過濾條件看清楚幀延時,並使得往返延時更為明顯。如果抓包文件中包含不同主機之間的多個會話,而只想知道其中一個pair,可將“frame.time\_delta”結合源和目標主機條件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。
從上圖可見,在第106秒時數據流的MAX frame.delta_time達到0.7秒,這是一個嚴重延時並且導致了報文丟失。
◦Count()
此函數計算時間間隔內事件發生的次數,在查看TCP分析標識符時很有用,例如重傳。
◦Sum()
該函數統計事件的累加值。有兩種常見的用例是看在捕獲TCP數據量,以及檢查TCP序列號。
參數設置:分別使用客户端IP 192.168.1.4為源、目的地址,並將SUM功能結合tcp.len過濾條件;
從圖表中我們可以看到,發送到客户端的數據量(IP.DST = = 192.168.1.4過濾條件)比來自客户端的數據量要高。在圖中紅色表示。黑條顯示從客户端到服務器的數據,相對數據量很小。這是有道理的,因為客户只是請求文件和收到之後發送確認數據,而服務器發送大文件。很重要的一點是,如果你交換了圖的順序,把客户端的IP作為圖1的目標地址,並且客户端IP作為圖2的源地址,採用了FBAR的時候可能看不到正確的數據顯示。因為圖編號越低表示在前台顯示,可能會覆蓋較高圖號。
4. 實例場景分析
參數設置:1是HTTP總體流量,顯示形式為packets/tick,時間間隔1秒。圖2是TCP丟失報文片段。圖3是TCP 重複ACK。圖4是TCP重傳。
圖1:HTTP總體流量圖
圖2:TCP丟失報文片段圖
圖3:TCP 重複ACK
從這張圖可以看到:整體的HTTP流量,TCP重傳以及重複ACK的流量,這些事件發生的時間點,以及在整體流量中所佔的比例。
•數據包丟失和延遲的TCP序列號場景:我們可以在下面的圖中看到若干峯值和下降,表示TCP傳輸有問題。
圖4:數據包丟失和延遲的TCP序列號場景
與正常TCP報文比較:
這張圖可以看到TCP序列號相當穩定地增加,表示傳輸平穩,沒有過多重傳或丟包。
•對比視頻會議在網絡卡頓與流暢時的IO圖表實例場景:
https://zhiliao.h3c.com/Theme/details/104284
5. 總結
如果只是簡單的排查網絡問題,只需要使用wireshark中簡單的添加過濾規則,通過觀察抓取到的數據包就可以達到定位問題的目的,其實這幾個進階的功能,無論是專家模式、還是IO圖表,底層其實還是需要配置規則,亦或者是通過wireshark的內置規則做了一個集成。針對一些場景,比如觀測網絡是否擁塞,可以通過IO圖表直觀的進行判斷,,,,,以上。
作者:京東科技 宋慧超
來源:京東雲開發者社區 轉載請註明來源