基本IO Graphs:

IO graphs是一個(gè)非常好用的工具。基本的Wireshark IO graph會(huì)顯示抓包文件中的整體流量情況，通常是以每秒為單位（報(bào)文數(shù)或字節(jié)數(shù)）。默認(rèn)X軸時(shí)間間隔是1秒，Y軸是每一時(shí)間間隔的報(bào)文數(shù)。如果想要查看每秒bit數(shù)或byte數(shù)，點(diǎn)擊“Unit”，在“Y Axis”下拉列表中選擇想要查看的內(nèi)容。這是一種基本的應(yīng)用，對(duì)于查看流量中的波峰/波谷很有幫助。要進(jìn)一步查看，點(diǎn)擊圖形中的任意點(diǎn)就會(huì)看到報(bào)文的細(xì)節(jié)。

為了講解方便，點(diǎn)擊示例報(bào)文包，或用自己的wireshark點(diǎn)擊Statistics – IO Graphs。這個(gè)抓包是HTTP下載遇到報(bào)文丟失的情況。

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

這個(gè)默認(rèn)條件下的顯示在大多數(shù)troubleshooting中并不是非常有用。將Y軸改為bits/tick這樣就可以看到每秒的流量。從這張圖可以看到峰值速率是300kbps左右。如果你看到有些地方流量下降為零，那可能是一個(gè)出問題的點(diǎn)。這個(gè)問題在圖上很好發(fā)現(xiàn)，但在看報(bào)文列表時(shí)可能不那么明顯。

過濾：

每一個(gè)圖形都可以應(yīng)用一個(gè)過濾條件。這里創(chuàng)建兩個(gè)不同的graph，一個(gè)HTTP一個(gè)ICMP?？梢钥吹竭^濾條件中Graph 1使用“http”Graph 2使用“icmp”。圖中可以看到紅色I(xiàn)CMP流量中有些間隙，進(jìn)一步分析。

創(chuàng)建兩個(gè)圖形，一個(gè)顯示ICMP Echo（Type=8）一個(gè)顯示ICMP Reply（Type=0）。正常情況下對(duì)于每一個(gè)echo請(qǐng)求會(huì)有一個(gè)連續(xù)的reply。這里的情況是：

可以看到紅色脈沖線(icmp type==0 – ICMP Reply)中間有間隙，而整張圖中ICMP請(qǐng)求保持連續(xù)。這意味著有些reply沒有接收到。這是由于報(bào)文丟失導(dǎo)致的reply drop。CLI中看到的ping信息如下：

常用排錯(cuò)過濾條件**:**

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

tcp.analysis.lost_segment：表明已經(jīng)在抓包中看到不連續(xù)的序列號(hào)。報(bào)文丟失會(huì)造成重復(fù)的ACK，這會(huì)導(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窗口大?。ǘx于最初3此TCP握手），為了最大化吞吐量你想要獲得盡可能接近TCP窗口大小。如果看到連續(xù)低于TCP窗口大小，可能意味著報(bào)文丟失或路徑上其他影響吞吐量的問題。

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

在抓包中應(yīng)用以上一些過濾條件：

注意：Graph 1是HTTP總體流量，顯示形式為packets/tick，時(shí)間間隔1秒。Graph 2是TCP丟失報(bào)文片段。Graph 3是TCP?重復(fù)ACK。Graph 4是TCP重傳。

從這張圖可以看到：相比于整體HTTP流量，有很多數(shù)量的重傳以及重復(fù)ACK。從這張圖中，可以看到這些事件發(fā)生的時(shí)間點(diǎn)，以及在整體流量中所占的比例。

函數(shù)**:**

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

MIN( ), AVG( ), MAX( )

首先看一下幀之間的最小，平均和最大時(shí)間，這對(duì)于查看幀/報(bào)文之間的延時(shí)非常有用。我們可以將這些函數(shù)結(jié)合“frame.time_delta**”過濾條件看清楚幀延時(shí)，并使得往返延時(shí)更為明顯。如果抓包文件中包含不同主機(jī)之間的多個(gè)會(huì)話，而只想知道其中一個(gè)pair，可將“frame.time_delta**”結(jié)合源和目標(biāo)主機(jī)條件如“ip.addr==x.x.x.x?&&ip.addr==y.y.y.y”。如下圖所示：

我們做了以下步驟：

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

從上圖可見，在第106秒時(shí)數(shù)據(jù)流的MAX frame.delta_time達(dá)到0.7秒，這是一個(gè)嚴(yán)重延時(shí)并且導(dǎo)致了報(bào)文丟失。如果想要深入研究，只需要點(diǎn)擊圖中這一點(diǎn)，就會(huì)跳轉(zhuǎn)至相應(yīng)幀。對(duì)應(yīng)于本例抓包文件中第1003個(gè)報(bào)文。如果你看見幀之間平均延時(shí)相對(duì)較低但突然某一點(diǎn)延時(shí)很長(zhǎng)，可點(diǎn)擊這一幀，看看這一時(shí)間點(diǎn)究竟發(fā)生了什么。

Count( )???????

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

Sum( )?????????

該函數(shù)統(tǒng)計(jì)事件的累加值。有兩種常見的用例是看在捕獲TCP數(shù)據(jù)量，以及檢查TCP序列號(hào)。讓我們看看第一個(gè)TCP長(zhǎng)度的例子。創(chuàng)建兩個(gè)圖，一個(gè)使用客戶端IP 192.168.1.4為源，另一個(gè)使用客戶端IP作為一個(gè)目的地址。每個(gè)圖我們將sum()功能結(jié)合tcp.len過濾條件。拆分成兩個(gè)不同的圖我們就可以看到在一個(gè)單一的方向移動(dòng)的數(shù)據(jù)量。