信號發生器的使用方法總結，wireshark使用方法總結

wireshark使用方法總結

www.cnblogs.com?2016-12-25 14:47

抓取報文:

下載和安裝好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網絡協議實現細節，檢查安全問題，網絡協議內部構件等等。

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過程。

基本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”。如下圖所示：

我們做了以下步驟：

從上圖可見，在第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序列號相當穩定地增加，表示傳輸平穩，沒有過多重傳或丟包。