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.addrx.x.x.x &&ip.addry.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圖表例項場景：
5. 總結
如果只是簡單的排查網路問題，只需要使用wireshark中簡單的新增過濾規則，透過觀察抓取到的資料包就可以達到定位問題的目的，其實這幾個進階的功能，無論是專家模式、還是IO圖表，底層其實還是需要配置規則，亦或者是透過wireshark的內建規則做了一個整合。針對一些場景，比如觀測網路是否擁塞，可以透過IO圖表直觀的進行判斷,,,,,以上。
作者：京東科技 宋慧超
來源：京東雲開發者社群 轉載請註明來源