應用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序列號至關穩定地增長，表示傳輸平穩，沒有過多重傳或丟包