Wireshark基本用法
抓取報文:
下載和安裝好Wireshark之後，啓動Wireshark並且在接口列表中選擇接口名，然後開始在此接口上抓包。例如，如果想要在無線網絡上抓取流量，點擊無線接口。點擊Capture Options可以配置高級屬性，但現在無此必要。
點擊接口名稱之後，就可以看到實時接收的報文。Wireshark會捕捉系統發送和接收的每一個報文。如果抓取的接口是無線並且選項選取的是混合模式，那麼也會看到網絡上其他報文。
上端面板每一行對應一個網絡報文，默認顯示報文接收時間（相對開始抓取的時間點），源和目標IP地址，使用協議和報文相關信息。點擊某一行可以在下面兩個窗口看到更多信息。“+”圖標顯示報文裏面每一層的詳細信息。底端窗口同時以十六進制和ASCII碼的方式列出報文內容。
需要停止抓取報文的時候，點擊左上角的停止按鍵。
色彩標識:
進行到這裏已經看到報文以綠色，藍色，黑色顯示出來。Wireshark通過顏色讓各種流量的報文一目瞭然。比如默認綠色是TCP報文，深藍色是DNS，淺藍是UDP，黑色標識出有問題的TCP報文——比如亂序報文。
報文樣本:
比如說你在家安裝了Wireshark，但家用LAN環境下沒有感興趣的報文可供觀察，那麼可以去Wireshark wiki下載報文樣本文件。
打開一個抓取文件相當簡單，在主界面上點擊Open並瀏覽文件即可。也可以在Wireshark裏保存自己的抓包文件並稍後打開。
過濾報文:
如果正在嘗試分析問題，比如打電話的時候某一程序發送的報文，可以關閉所有其他使用網絡的應用來減少流量。但還是可能有大批報文需要篩選，這時要用到Wireshark過濾器。
最基本的方式就是在窗口頂端過濾欄輸入並點擊Apply（或按下回車）。例如，輸入“dns”就會只看到DNS報文。輸入的時候，Wireshark會幫助自動完成過濾條件。
也可以點擊Analyze菜單並選擇Display Filters來創建新的過濾條件。
另一件很有趣的事情是你可以右鍵報文並選擇Follow TCP Stream。
你會看到在服務器和目標端之間的全部會話。
關閉窗口之後，你會發現過濾條件自動被引用了——Wireshark顯示構成會話的報文。
檢查報文:
選中一個報文之後，就可以深入挖掘它的內容了。
也可以在這裏創建過濾條件——只需右鍵細節並使用Apply as Filter子菜單，就可以根據此細節創建過濾條件。
Wireshark是一個非常之強大的工具，第一節只介紹它的最基本用法。網絡專家用它來debug網絡協議實現細節，檢查安全問題，網絡協議內部構件等等。
一站式學習Wireshark（二）：應用Wireshark觀察基本網絡協議
TCP:
TCP/IP通過三次握手建立一個連接。這一過程中的三種報文是：SYN，SYN/ACK，ACK。
第一步是找到PC發送到網絡服務器的第一個SYN報文，這標識了TCP三次握手的開始。
如果你找不到第一個SYN報文，選擇Edit -> Find Packet菜單選項。選擇Display Filter，輸入過濾條件：tcp.flags，這時會看到一個flag列表用於選擇。選擇合適的flag，tcp.flags.syn並且加上==1。點擊Find，之後trace中的第一個SYN報文就會高亮出來了。
注意：Find Packet也可以用於搜索十六進制字符，比如惡意軟件信號，或搜索字符串，比如抓包文件中的協議命令。
一個快速過濾TCP報文流的方式是在Packet List Panel中右鍵報文，並且選擇Follow TCP Stream。這就創建了一個只顯示TCP會話報文的自動過濾條件。
這一步驟會彈出一個會話顯示窗口，默認情況下包含TCP會話的ASCII代碼，客戶端報文用紅色表示服務器報文則爲藍色。
窗口類似下圖所示，對於讀取協議有效載荷非常有幫助，比如HTTP，SMTP，FTP。
更改爲十六進制Dump模式查看載荷的十六進制代碼，如下圖所示：
關閉彈出窗口，Wireshark就只顯示所選TCP報文流。現在可以輕鬆分辨出3次握手信號。
注意：這裏Wireshark自動爲此TCP會話創建了一個顯示過濾。本例中：(ip.addr eq 192.168.1.2 and ip.addr eq 209.85.227.19) and (tcp.port eq 80 and tcp.port eq 52336)
SYN報文：
圖中顯示的5號報文是從客戶端發送至服務器端的SYN報文，此報文用於與服務器建立同步，確保客戶端和服務器端的通信按次序傳輸。SYN報文的頭部有一個32 bit序列號。底端對話框顯示了報文一些有用信息如報文類型，序列號。
SYN/ACK報文：
7號報文是服務器的響應。一旦服務器接收到客戶端的SYN報文，就讀取報文的序列號並且使用此編號作爲響應，也就是說它告知客戶機，服務器接收到了SYN報文，通過對原SYN報文序列號加一併且作爲響應編號來實現，之後客戶端就知道服務器能夠接收通信。
ACK報文：
8號報文是客戶端對服務器發送的確認報文，告訴服務器客戶端接收到了SYN/ACK報文，並且與前一步一樣客戶端也將序列號加一，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
ARP & ICMP：
開啓Wireshark抓包。打開Windows控制檯窗口，使用ping命令行工具查看與相鄰機器的連接狀況。
停止抓包之後，Wireshark如下圖所示。ARP和ICMP報文相對較難辨認，創建只顯示ARP或ICMP的過濾條件。
ARP報文：
地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。其功能是：主機將ARP請求廣播到網絡上的所有主機，並接收返回消息，確定目標IP地址的物理地址，同時將IP地址和硬件地址存入本機ARP緩存中，下次請求時直接查詢ARP緩存。
最初從PC發出的ARP請求確定IP地址192.168.1.1的MAC地址，並從相鄰系統收到ARP回覆。ARP請求之後，會看到ICMP報文。
ICMP報文：
網絡控制消息協定（Internet Control Message Protocol，ICMP）用於TCP/IP網絡中發送控制消息，提供可能發生在通信環境中的各種問題反饋，通過這些信息，令管理者可以對所發生的問題作出診斷，然後採取適當的措施解決。
PC發送echo請求，收到echo回覆如上圖所示。ping報文被mark成Type 8，回覆報文mark成Type 0。
如果多次ping同一系統，在PC上刪除ARP cache，使用如下ARP命令之後，會產生一個新的ARP請求。
C:\> ping 192.168.1.1… ping output … C:\> arp –d *
HTTP：
HTTP協議是目前使用最廣泛的一種基礎協議，這得益於目前很多應用都基於WEB方式，實現容易，軟件開發部署也簡單，無需額外的客戶端，使用瀏覽器即可使用。這一過程開始於請求服務器傳送網絡文件。
從上圖可見報文中包括一個GET命令，當HTTP發送初始GET命令之後，TCP繼續數據傳輸過程，接下來的鏈接過程中HTTP會從服務器請求數據並使用TCP將數據傳回客戶端。傳送數據之前，服務器通過發送HTTP OK消息告知客戶端請求有效。如果服務器沒有將目標發送給客戶端的許可，將會返回403 Forbidden。如果服務器找不到客戶端所請求的目標，會返回404。
如果沒有更多數據，連接可被終止，類似於TCP三次握手信號的SYN和ACK報文，這裏發送的是FIN和ACK報文。當服務器結束傳送數據，就發送FIN/ACK給客戶端，此報文表示結束連接。接下來客戶端返回ACK報文並且對FIN/ACK中的序列號加1。這就從服務器端終止了通信。要結束這一過程客戶端必須重新對服務器端發起這一過程。必須在客戶端和服務器端都發起並確認FIN/ACK過程。
應用Wireshark IO圖形工具分析數據流
基本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序列號相當穩定地增加，表示傳輸平穩，沒有過多重傳或丟包。