基本IO Graphs:

IO graphs是一個非常好用的工具。基本的Wireshark IO graph會顯示抓包檔案中的整體流量情況，通常是以每秒為單位（報文數或位元組數）。預設X軸時間間隔是1秒，Y軸是每一時間間隔的報文數。如果想要檢視每秒bit數或byte數，點選“Unit”，在“Y Axis”下拉列表中選擇想要檢視的內容。這是一種基本的應用，對於檢視流量中的波峰/波谷很有幫助。要進一步檢視，點選圖形中的任意點就會看到報文的細節。

為了講解方便，點選示例報文包，或用自己的wireshark點選Statistics – IO Graphs。這個抓包是HTTP下載遇到報文丟失的情況。

注意：過濾條件為空，此圖形顯示所有流量。

這個預設條件下的顯示在大多數troubleshooting中並不是非常有用。將Y軸改為bits/tick這樣就可以看到每秒的流量。從這張圖可以看到峰值速率是300kbps左右。如果你看到有些地方流量下降為零，那可能是一個出問題的點。這個問題在圖上很好發現，但在看報文列表時可能不那麼明顯。

過濾：

每一個圖形都可以應用一個過濾條件。這裡建立兩個不同的graph，一個HTTP一個ICMP。可以看到過濾條件中Graph 1使用“http”Graph 2使用“icmp”。圖中可以看到紅色ICMP流量中有些間隙，進一步分析。

建立兩個圖形，一個顯示ICMP Echo（Type=8）一個顯示ICMP Reply（Type=0）。正常情況下對於每一個echo請求會有一個連續的reply。這裡的情況是：

可以看到紅色脈衝線(icmp type==0 – ICMP Reply)中間有間隙，而整張圖中ICMP請求保持連續。這意味著有些reply沒有接收到。這是由於報文丟失導致的reply drop。CLI中看到的ping資訊如下：

常用排錯過濾條件:

對於排查網路延時/應用問題有一些過濾條件是非常有用的：

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。如果這一時間間隔比較長那可能表示某種型別的網路延時（報文丟失，擁塞，等等）。

在抓包中應用以上一些過濾條件：

注意：Graph 1是HTTP總體流量，顯示形式為packets/tick，時間間隔1秒。Graph 2是TCP丟失報文片段。Graph 3是TCP 重複ACK。Graph 4是TCP重傳。

從這張圖可以看到：相比於整體HTTP流量，有很多數量的重傳以及重複ACK。從這張圖中，可以看到這些事件發生的時間點，以及在整體流量中所佔的比例。

函式:

IO Graphs有六個可用函式：SUM, MIN, AVG, MAX, COUNT, LOAD。

MIN( ), AVG( ), MAX( )

首先看一下幀之間的最小，平均和最大時間，這對於檢視幀/報文之間的延時非常有用。我們可以將這些函式結合“frame.time_delta”過濾條件看清楚幀延時，並使得往返延時更為明顯。如果抓包檔案中包含不同主機之間的多個會話，而只想知道其中一個pair，可將“frame.time_delta”結合源和目標主機條件如“ip.addr==x.x.x.x &&ip.addr==y.y.y.y”。如下圖所示：

我們做了以下步驟：

• 將Y軸設定為“Advanced”，讓Caculation域可見。不做這一步就看不到計算選項。
• X軸時間間隔1秒，所以每個柱狀圖代表1秒間隔的計算結果。
• 過濾出兩個特定IP地址的HTTP會話，使用條件：“(ip.addr==192.168.1.4&& ip.addr==128.173.87.169) && http”。
• 使用3個不同的graph，分別計算Min(), Avg(), Max()。
• 對每一個計算結果應用條件“frame.time_delta”，將style設定成“FBar”，顯示效果最佳。

從上圖可見，在第106秒時資料流的MAX frame.delta_time達到0.7秒，這是一個嚴重延時並且導致了報文丟失。如果想要深入研究，只需要點選圖中這一點，就會跳轉至相應幀。對應於本例抓包檔案中第1003個報文。如果你看見幀之間平均延時相對較低但突然某一點延時很長，可點選這一幀，看看這一時間點究竟發生了什麼。

Count( )       

此函式計算時間間隔內事件發生的次數，在檢視TCP分析識別符號時很有用，例如重傳。例圖如下：

Sum( )         

該函式統計事件的累加值。有兩種常見的用例是看在捕獲TCP資料量，以及檢查TCP序列號。讓我們看看第一個TCP長度的例子。建立兩個圖，一個使用客戶端IP 192.168.1.4為源，另一個使用客戶端IP作為一個目的地址。每個圖我們將sum()功能結合tcp.len過濾條件。拆分成兩個不同的圖我們就可以看到在一個單一的方向移動的資料量。

從圖表中我們可以看到，傳送到客戶端的資料量（IP.DST = = 192.168.1.4過濾條件）比來自客戶端的資料量要高。在圖中紅色表示。黑條顯示從客戶端到伺服器的資料，相對資料量很小。這是有道理的，因為客戶只是請求檔案和收到之後傳送確認資料，而伺服器傳送大檔案。很重要的一點是，如果你交換了圖的順序，把客戶端的IP作為圖1的目標地址，並且客戶端IP作為圖2的源地址，採用了FBAR的時候可能看不到正確的資料顯示。因為圖編號越低表示在前臺顯示，可能會覆蓋較高圖號。

現在讓我們看一下同一個數據包丟失和延遲的TCP序列號。

可以在圖中看到若干峰值和下降，表示TCP傳輸有問題。與正常TCP報文比較：

這張圖可以看到TCP序列號相當穩定地增加，表示傳輸平穩，沒有過多重傳或丟包。