基本**IO Graphs:**
IO graphs是一個非常好用的工具。基本的Wireshark IO graph會顯示抓包文件中的整體流量情況，通常是以每秒為單位（報文數或字節數）。默認X軸時間間隔是1秒，Y軸是每一時間間隔的報文數。如果想要查看每秒bit數或byte數，點擊“Unit”，在“Y Axis”下拉列表中選擇想要查看的內容。這是一種基本的應用，對于查看流量中的波峰/波谷很有幫助。要進一步查看，點擊圖形中的任意點就會看到報文的細節。
為了講解方便，點擊[示例報文包](https://www.cloudshark.org/captures/d6f9e83699c8)，或用自己的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分析標識符時很有用，例如重傳。例圖如下：
[](https://box.kancloud.cn/2015-09-09_55efb09b0180c.jpg "一站式學習Wireshark（三）：應用Wireshark IO圖形工具分析數據流")
**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序列號相當穩定地增加，表示傳輸平穩，沒有過多重傳或丟包。
