一站式學習Wireshark（轉載）

一站式學習Wireshark（一）：Wireshark基本用法

2014/06/10 · IT技術 · 4 評論 · WireShark

分享到： 115

• 與《YII框架》不得不說的故事—擴展篇
• sass進階篇
• IOS基礎教程之界面初體驗
• Spring事務管理

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

按照國際慣例，從最基本的提及。

抓取報文:

下載和安裝好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觀察基本網絡協議

2014/06/10 · IT技術 · WireShark

分享到： 25

• CSS3圖片動態提示效果
• Python操做MySQL數據庫
• C++遠征之多態篇
• python進階

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

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（三）：應用Wireshark IO圖形工具分析數據流

2014/06/10 · IT技術 · WireShark

分享到： 17

• Struts2攔截器淺析
• 使用Struts2+Hibernate開發學生信息管理功能
• C#開發輕鬆入門
• 神奇的JpGraph類庫

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

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

 

一站式學習Wireshark（四）：網絡性能排查之TCP重傳與重複ACK

2014/06/17 · IT技術 · WireShark

分享到： 54

• 側欄工具條開發
• PHP入門篇
• C++遠征之繼承篇
• 觀察者模式

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

做爲網絡管理員，不少時間必然會耗費在修復慢速服務器和其餘終端。但用戶感到網絡運行緩慢並不意味着就是網絡問題。

解決網絡性能問題，首先從TCP錯誤恢復功能（TCP重傳與重複ACK）和流控功能提及。以後闡述如何發現網絡慢速之源。最後，對網絡各組成部分上的數據流進行概況分析。這幾張內容將會幫助讀者識別，診斷，以及排查慢速網絡。

更多信息
接下來的內容，較可能是黑白圖片了。雖然看起來有點不爽，但仍是很值得一看。

TCP錯誤恢復功能：

TCP的錯誤恢復功能是定位，診斷及修復網絡延時的最佳工具。延時能夠在單程也能夠往返方向測量。高延時是網絡管理員的頭號大敵。本節咱們討論TCP高延時是如何致使序列號和確認號亂序的。

TCP重傳：

主機報文重傳是TCP最基本的錯誤恢復功能，它的目的是防止報文丟失。

報文丟失的可能因素有不少種，包括應用故障，路由設備過載，或暫時的服務宕機。報文級別速度是很高的，而一般報文丟失是暫時的，所以TCP可以發現和恢復報文丟失顯得尤其重要。

決定報文是否有必要重傳的主要機制是重傳計時器（retransmission timer），它的主要功能是維護重傳超時（RTO）值。當報文使用TCP傳輸時，重傳計時器啓動，收到ACK時計時器中止。報文發送至接收到ACK的時 間稱爲往返時間（RTT）。對若干次時間取平均值，該值用於肯定最終RTO值。在最終RTO值肯定以前，肯定每一次報文傳輸是否有丟包發生使用重傳計時 器，下圖說明了TCP重傳過程。

當報文發送以後，但接收方還沒有發送TCP ACK報文，發送方假設源報文丟失並將其重傳。重傳以後，RTO值加倍；若是在2倍RTO值到達以前仍是沒有收到ACK報文，就再次重傳。若是仍然沒有收 到ACK，那麼RTO值再次加倍。如此持續下去，每次重傳RTO都翻倍，直到收到ACK報文或發送方達到配置的最大重傳次數。

最大重傳次數取決於發送操做系統的配置值。默認狀況下，Windows主機默認重傳5次。大多數Linux系統默認最大15次。兩種操做系統均可配置。
示例以下圖：

TCP重傳過程發送的第一個報文以下圖所示（圖片不很清楚，已經盡力了）：

這是一個TCP PSH/ACK報文①，包含648字節數據②，從10.3.30.1發送至10.3.71.7。這是一個典型的數據報文。

在一般狀況下，第一個報文發送以後很快會收到TCP ACK報文。然而，在這個case裏，第二個是重傳報文。能夠在Packet list面板裏看到。Info欄清楚的標明「TCP Retransmission」，報文以黑色背景紅色字體標出。下圖是Packet List面板中的重傳示例（仍然不清楚，但可參見上圖）：

也能夠在Packet Details和Packet Bytes面板中查看來肯定是不是重傳報文，以下圖所示：

注意此報文與源報文相同（除了IP標識和checksum字段）。要驗證這一點，比較兩個報文的Packet Bytes①。

在Packet Details面板，注意到重傳報文在SEQ/ACK Analysis下面有些額外的信息②。這些信息是由Wireshark提供的而並不是報文自己。SEQ/ACK Analysis告訴咱們這確實是一個重傳報文，RTO值是0.206秒，此時的RTO是基於報文1的時間增量。

檢查剩下的報文會獲得相似的結果，不一樣之處只有IP標識和checksum，以及RTO值。要使報文之間的時間間隔形象化，在Packet List面板中查看Time欄，以下圖所示。這裏能夠看到RTO值的翻倍增加關係。

TCP重複ACK以及快速重傳：

重複ACK是指在接收方收到亂序報文時，所發出的一類TCP報文。TCP使用報文頭的序列號和確認號以有效保證數據按照發送的順序接收和重組。

當TCP鏈接創建之後，握手過程當中交換的一個最重要的信息是初始序列號（ISN）。一旦鏈接雙方設定了ISN以後，接下來發送的報文所包含的序列號增長一個數據載荷值。

假設有個主機ISN是5000，發送500字節報文至接收方。一旦報文接收以後，接收端回覆一個ACK號爲5500的TCP ACK報文，基於如下公式：

Sequence Number In + Bytes of Data Received = Acknowledgment Number Out

按照上述計算結果，返回發送端的確認編號其實是接收端但願收到的序列號。示例以下圖：

數據接收方經過序列號來檢查報文丟失。接收方經過追蹤接收到的序列號，可以確認序列號是否亂序。當接收方收到一個不正常的序列號，它會假設傳輸過程當中有報 文丟失。爲了正確重傳數據，接收方必須擁有丟失報文，因此它發送包含有丟失報文正確序列號的ACK報文，以便發送方重傳此報文。

當重傳主機從發送端接收到3個重複ACK時，它會假設此報文確實在傳送中丟失，而且當即發送一個快速重傳。一旦觸發了快速重傳，全部正在傳輸的其餘報文都被放入隊列中，直到快速重傳報文發送爲止。過程以下圖所示：

承接上文的彩圖：

本例中第一個報文以下圖：

這是一個TCP ACK報文，從數據接收端（172.31.136.85）發給發送端（195.81.202.68）①，確認前一個報文所發送的數據。
此報文中的確認編號是1310973186②，應當是下一個接收報文的序列號，以下圖所示：

不幸的是接收端的序列號是1310984130①，並非所指望的值。這意味着報文在傳送中丟失。接收端注意到報文亂序，而且在第三個報文中發送重複ACK，以下圖所示：

能夠經過如下兩種方式之一來確認這是一個重複ACK：

在Packet Detaisl面板中的Info欄。報文呈現黑色背景紅色字體。

SEQ/ACK Analysis下的Packet Deatails面板。擴展這一欄會發現報文顯示爲duplicate ACK。接下來幾個報文重複此過程。以下圖所示：

此文件中的第四個報文是發送端所發出具備錯誤序列號①的另外一個數據塊。所以，接收端發送第二個重複ACK②。接收端又收到一個亂序報文③。從而觸發了第三以及最後一個重複ACK④.

一旦發送方接收到接收方所發來的第三個重複ACK，它就會暫停全部傳輸報文而且重傳丟失報文，下圖顯示了快速重傳過程：

重傳報文一樣能夠經過Packet List面板的Info欄觀察到。報文呈現黑色背景紅色字體。這個報文的SEQ/ACK Analysis截面告訴咱們這多是一個快速重傳幀。（標識報文爲快速重傳的信息不是報文自己所包含的內容，而是Wireshark的功能）。最後一個 報文是接收到快速重傳的ACK。

 

一站式學習Wireshark（五）：TCP窗口與擁塞處理

2014/06/24 · IT技術 · WireShark

分享到： 14

• 前端開發工具技巧介紹—Sublime篇
• 瀑布流佈局
• SEO在網頁製做中的應用
• MySQL開發技巧（三）

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

TCP經過滑動窗口機制檢測丟包，並在丟包發生時調整數據傳輸速率。滑動窗口機制利用數據接收端的接收窗口來控制數據流。

接收窗口值由數據接收端指定，以字節數形式存儲於TCP報文頭，並告知傳輸設備有多少數據將會存儲在TCP緩衝區。緩衝區就是數據暫時放置的地方， 直至傳遞至應用層協議等待處理。所以，發送端每次只能發送Window Size字段指定的數據量。爲了使發送端繼續傳送數據，接收端必須發送確認信息：以前的數據接收到了。同時必須對佔用緩衝區的數據進行處理以釋放緩存空 間。下圖顯示了接收窗口是如何工做的：

上圖中，客戶端向服務器發送數據，服務器接收窗口是5000字節。客戶端發送了2500字節，服務器緩衝區還剩2500字節，以後又發送了2000 字節，從而緩衝區只剩500字節。服務器發送確認信息。對緩存中數據進行處理並清空緩存。此過程重複進行，客戶端又發送3000字節和1000字節，服務 器緩存減小至1000字節，客戶端再次確認數據並處理緩存中內容。

更多信息

調整窗口大小：

當TCP堆 棧接收到數據的時候，生成一個確認信息並以回覆的方式發送，可是放置在接收端緩存中的數據並不老是當即被處理。當服務器忙於處理從多個客戶端接收的報文， 服務器頗有可能由於清理緩存而變得緩慢，沒法騰出空間接收新的數據，若是沒有流控，則可能會形成丟包和數據損壞。好在，接收窗口所設定的速率沒法使服務器 正常處理數據時，可以調整接收窗口大小。經過減少返回給發送端的ACK報文的TCP頭窗口大小值來實現。以下圖所示：

上圖中，服務器初始窗口大小爲5000字節。客戶端發送2000字節，以後又發送了2000字節，緩衝區中只有1000字節可用。服務器意識到緩衝 區正在快速填滿，它知道若是數據繼續以此速率傳輸，很快會有報文丟失。爲了防止報文丟失，服務器發送確認信息給客戶端，更新窗口大小爲1000字節。結 果，客戶端減小數據發送，服務器以能夠接受的速率處理緩存內容，即保持數據流以穩定的速率傳輸。

調整窗口大小在兩個方向都是可行的。當服務器可以更加快速的處理報文時，它會發送一個較大窗口的ACK報文。

零窗口暫停數據流：

某些狀況下，服務器沒法再處理從客戶端發送的數據。多是因爲內存不足，處理能力不夠，或其餘緣由。這可能會形成數據被丟棄以及傳輸暫停，但接收窗口可以幫助減少負面影響。

當上述狀況發生時，服務器會發送窗口爲0的報文。當客戶端接收到此報文時，它會暫停全部數據傳輸，但會保持與服務器的鏈接以傳輸探測（keep- alive）報文。探測報文在客戶端以穩定間隙發送，以查看服務器接收窗口狀態。一旦服務器可以再次處理數據，將會返回非零值窗口大小，傳輸會恢復。下圖 示例了零窗口通知過程。

服務器初始接收數據窗口爲5000字節大小。從客戶端接收4000字節數據以後，服務器負載變得很是繁重，沒法繼續處理客戶端任何數據。服務器因而 發送窗口大小值爲0的報文。客戶端暫停數據傳輸併發送一個探測報文。探測報文以後，服務器回覆以告知客戶端如今能夠接收數據的報文，以及窗口大小爲 1000字節。客戶端恢復傳送數據。

TCP滑動窗口實戰：

本例中，開始從192.168.0.20發送至192.168.0.30。咱們關心的是窗口大小字段，能夠從Packet List面板的Info欄以及Packet Details的TCP報文頭看到。前三個報文後，可看到該值馬上減少，以下圖所示：

窗口大小值從第一個報文的8760字節變成第二個報文的5840字節到第三個報文的2920字節①。窗口大小值的減少是主機延時的典型標誌。在時間 欄注意到這一過程發生的很是迅速②。當窗口大小迅速減少的時候，一般就有可能降低爲零。這就是第四個報文所發生的，以下圖所示：

第四個報文從192.168.0.20發送至192.168.0.30，目的是告訴192.168.0.30它再也不接收任何數據。0值見於TCP報 文頭①，Wireshark的Packet List面板Info欄，以及TCP報文頭的SEQ/ACK Analysis字段②也告訴咱們這是一個0窗口報文。

一旦發送了零窗口報文，192.168.0.30的設備不會再發送任何數據，直到收到從192.168.0.20的窗口更新，告知窗口大小已經增長了。本例中致使零窗口的問題是暫時的，因此在下一個報文中發送了窗口更新信息，以下圖所示。

本例中，窗口大小增長到一個很是健康的數值64，240字節①。Wireshark再次在SEQ/ACK Analysis告訴咱們這是一個窗口更新。

一旦收到更新報文，192.168.0.30的主機就再次開始發送數據，在報文6和報文7中。這一過程發生很快。若是它持續時間再長一點，就可能會致使網絡的潛在中斷，引發數據傳輸減慢或失敗。

下一個關於滑動窗口的例子，第一個報文是正常HTTP，從195.81.202.68至172.31.136.85。此報文以後馬上跟隨一個從172.31.136.85發送的零窗口報文，以下圖所示：

這與上一個例子中的零窗口報文十分相似，但結果顯著不一樣，172.31.136.85主機不是發送一個窗口更新並回復通信，而是一個探測報文，以下圖所示：

此報文被Wireshark標註爲探測報文①。時間欄告訴咱們這一報文發生於最後一個接收到的報文3.4秒以後。這一過程持續若干次，一端發送零窗口報文另外一端發送探測報文，以下圖所示：

探測報文發送間隙爲3.4，6.8，13.5秒。這一過程可能會持續至關長一段時間，取決於通信設備的操做系統。該狀況下，把時間欄的值加起來，通信暫停了25秒。

TCP差錯控制和流控排查總結：

重傳報文

重 傳的發生是因爲客戶端檢測到服務器沒有接收到它所發送的數據。所以，取決於你所分析的是通信的哪一端，有多是看不見重傳的。若是從服務器端抓取數據，並 且它確實沒有接收到客戶端所發送的和重傳報文，可能會一無所得由於沒法看見重傳報文。若是懷疑並非服務器端致使的報文丟失，能夠考慮在客戶端嘗試抓取報 文，以查看實際是否有重傳發生。

重複ACK

能夠將重複ACK看做重傳的「所謂相反面」，由於它是在服務器檢測到客戶端發送報文丟失的時候產生的。大多數狀況下，在通信兩端抓取流量時均可以看 到重複ACK。需記住當接收報文亂序時會觸發重複ACK。例如，若是服務器之接收到發送的第一個和第三個報文，就會致使發送重複ACK引發客戶端對第二個 報文的快速重傳，由於你已經收到了第一個和第三個報文，所以無論致使第二個報文丟棄的緣由是什麼，都頗有多是暫時的，所以大多數狀況下重複ACK都會成 功發送和接收。固然，這種情形並不必定永遠會發生，所以當你懷疑在服務器端丟失報文而又看不到任何重複ACK，考慮從通信的客戶端抓取報文。

零窗口和探測報文

滑動窗口直接與服務器沒法接收和處理報文有關，任何窗口大小的縮小以及零值都是服務器問題的直接結果。因此若是你在哪裏看到這二者之一發生，就應該在那裏深刻研究。一般應當在網絡通信兩端一直主機窗口更新報文。

 

一站式學習Wireshark（六）：狙擊網絡高延時點

2014/07/14 · IT技術 · WireShark

分享到： 15

• 與《YII框架》不得不說的故事—擴展篇
• sass進階篇
• IOS基礎教程之界面初體驗
• Spring事務管理

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

在某些狀況下，丟包可能並非形成延時的緣由。你可能會發現儘管兩臺主機之間通信速度很慢，但這種慢速並無伴隨着TCP重傳或是重複ACK的徵兆。在這種狀況下，須要使用另外一種方式來定位高延時點。

查找高延時點最有效的方法之一是檢查最初的握手信號以及跟隨其後的幾個報文。例如，一個簡單的客戶端與網絡服務器的鏈接，客戶端嘗試經過瀏覽器訪問 網絡服務器的站點。咱們只關心這一通訊序列的前六個報文，包括TCP握手過程，首次HTTP GET請求，對此GET請求的確認，以及從服務器發至客戶端的第一個數據報文。

更多信息

正常通信:

在討論高延時情況以前，找一個正常的通信做爲參照。在第二節已經介紹過TCP握手過程以及HTTP通信，這裏再也不贅述。在下面這張圖裏，咱們關心的部分只有Time列：

這一通信序列是很是快速的，整個過程耗時不到0.1秒。

接下來幾個抓包文件包含一樣的traffic模式，可是在報文時序上有所不一樣。

慢速通信——線路延時：

讓咱們看看下面這個報文。注意到全部報文都是相同的，除了報文2和5的時間延時較長：

逐一分析這六個報文，馬上就會看到第一次延時。客戶端（172.16.16.128）發送首次SYN報文以開始TCP握手，在服務器 （74.125.95.104）返回SYN/ACK以前，有0.87秒的延時。這是線路延時的第一個信號，這是由客戶端和服務器之間的設備引發的。

咱們判斷這是線路延時的依據是所傳送的報文類型特徵。當服務器接收到一個SYN報文，只需花費不多的處理過程就可發送回覆，由於這一工做負載並不包 含任何傳輸層之上的處理。即便服務器工做負載很是繁重，它一般也會快速地以SYN/ACK來回復SYN報文。這就排除了服務器是高延時的潛在緣由。

客戶端也被排除的緣由在於，它除了接收SYN/ACK報文以外，沒有進行任何處理。

這一抓包的前兩個報文幫咱們排除了客戶端和服務器，並指出了潛在緣由。

繼續分析，咱們發現結束三步握手信號的ACK報文快速出現，客戶端發送的HTTP GET請求也是如此。產生這兩個報文的全部處理在本地客戶端接收到SYN/ACK以後進行，所以在客戶端沒有繁重的負載須要處理的狀況下，這兩個報文預計會很快傳送。

到了報文5，咱們看到另外一個延時高得離譜的報文。出如今最初的HTTP GET請求發送事後，從服務器返回的ACK報文花費了1.15秒才收到。接收到HTTP GET請求以後，服務器在開始發送數據以前首先發送了一個TCP ACK，一樣只需佔用服務器不多的處理。這是另外一個線路延時的信號。

無論什麼時候你經歷着線路延時，你幾乎老是會看到：在最初的握手信號期間的SYN/ACK報文，以及整個通信過程的ACK報文中，存在着高延時。即便這 一信息並無告訴你網絡上延時的確切緣由，至少讓你明白客戶端和服務器都不是延時點所在，所以延時發生在二者之間的設備。這時，你應當開始檢查受影響主機 之間的各類防火牆，路由器，以及代理，以定位罪魁禍首。

慢速通信——客戶端延時：

下一個延時場景的抓包以下圖所示：

這一抓包開始時很正常，TCP握手很是迅速，沒有任何延時的跡象。正常狀態持續至第四個報文：握手信號結束以後接收到一個HTTP GET請求。這個報文距離前一個接收到的報文有1.34秒的延時。

要確認網絡的延時點，須要檢查第3和第4個報文之間發生了什麼。報文3是客戶端發送到服務器的TCP握手信號中的最後一個ACK，報文4是從客戶端 發送至服務器的GET請求。這兩個報文的共同之處在於都是由客戶端發送，而且獨立於服務器。因爲全部這些操做都集中在客戶端上，GET請求應當在發送了 ACK以後快速傳送。

不幸的是對於終端用戶，從ACK到GET的傳送並無快速發生。GET報文的建立與傳輸取決於應用層的處理，這一過程當中的延時意味着客戶端沒法及時的執行這一功能。這表示客戶端最終爲通信中的高延時負責。

慢速通信——服務器延時：

最後一個延時場景的抓包以下圖所示：

在這一抓包中，兩個主機之間的TCP握手過程完成得乾脆利落，所以開始時並沒有問題。接下來幾個報文也很順利，首個GET請求及回覆ACK報文也在快速交付。直到最後一個報文，咱們看到了高延時的信號。

第六個報文是服務器響應客戶端GET請求的第一個HTTP數據報文，可是在服務器發送GET請求的TCP ACK 0.98秒以後纔到達。報文5和6的傳送過程與咱們在前一個場景所見ACK和GTE請求的傳送相似。可是，在這一狀況下，服務器是咱們關注的焦點。

報文5是服務器對從客戶端接收GET請求的迴應。只要該報文被髮送，服務器就應當當即發送數據。這一讀取，封裝，傳送的過程是由HTTP協議完成 的，因爲這是應用層協議，須要服務器參與處理過程。這一報文的延遲接收代表服務器沒法在合理的時間內處理數據，最終指向服務器是延時點。

延時定位思路：

經過六個報文，咱們可以定位服務器與客戶端之間的網絡高延時點。這些場景可能看起來有點複雜，可是下圖能使你的定位延時過程變得簡單快捷。這一原則幾乎能應用於任何基於TCP的通信。

 

一站式學習Wireshark（七）：Statistics統計工具功能詳解與應用

2014/07/14 · IT技術 · WireShark

分享到： 14

• jQuery源碼解析（架構與依賴模塊）
• Android高級特效-3D畫廊
• 從D2到D2(大話遊戲開發實戰技巧)
• 與《YII框架》不得不說的故事—高效篇

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

Wireshark 一個強大的功能在於它的統計工具。使用Wireshark的時候，咱們有各類類型的工具可供選擇，從簡單的如顯示終端節點和會話到複雜的如Flow和IO 圖表。本文將介紹基本網絡統計工具。包括：捕捉文件摘要（Summary）,捕捉包的層次結構（Protocol Hirarchy）, 會話（Conversations）, 終端節點（Endpoints）, HTTP。

更多信息

Summary:

從statistics菜單，選擇Summary：

以下圖的截屏所示，你會看到：

File：

捕捉文件的通常信息，如文件名和路徑，長度，等等

Time：

第一個包和最後一個包的時間戳，以及抓包過程持續時間

Capture：

顯示文件捕捉於哪個接口，以及評論窗口

在窗口的較低部分是Display窗口，展現抓包文件統計信息的摘要，包括：

捕捉報文的總數與百分比

顯示報文的數量（加上過濾條件以後）

標記報文的數量

什麼時候使用：

這一菜單簡單收集全部抓包數據，在定義了過濾條件的時候，將呈現過濾後的數據。當想要知道每秒的平均報文數或是字節數時，可使用此工具。

Protocol Hierarchy:

這一部分闡述如何確知網絡運行數據。從statistics菜單，選擇Protocol Hierarchy。

這個窗口現實的是捕捉文件包含的全部協議的樹狀分支。以下圖所示：

Protocol Hierarchy窗口有以下字段：

Protocol：

協議名稱

% Packets：

含有該協議的包數目在捕捉文件全部包所佔的比例

Packets：

含有該協議的包的數目

Bytes：

含有該協議的字節數

Mbit/s：

抓包時間內的協議帶寬

End Packets：

該協議中的包的數目（做爲文件中的最高協議層）

End Bytes：

該協議中的字節數（做爲文件中的最高協議層）

End Mbit/s：

抓包時間內的協議帶寬（做爲文件中的最高協議層）

小貼士：

包一般會包含許多協議，有不少協議會在每一個包中被統計。End Packets，End Bytes，End Mbit/s列是該層在抓包中做爲最後一層協議的統計數據（也就是說，協議處於報文的頂層，而且沒有更高層信息了）。例如，沒有載荷的TCP報文（例 如，SYN報文），這一類沒有負載任何上層信息的報文。這就是爲何在Ethernet層，IPv4層和UDP層報文計數爲0，由於沒有接收到以這些協議 做爲最後一層的幀。

什麼時候使用：

值得注意的兩點是：

百分比永遠指的是相同協議層級。例如，

使用要點：

1. Percentage永遠參照的是相同協議層。例如，上例中81.03%是IPv4報文，8.85%是IPv6報文，10.12%是ARP報文。第二層之上的各協議所佔百分比總和是100%。

2. 另外一方面，TCP佔總數據的75.70%，在TCP協議以內，只有12.74%的報文是HTTP，除此以外沒有其餘統計。這是因爲Wireshark只統計有HTTP頭的報文。它不統計如確認報文或數據報文這樣沒有HTTP頭的報文。

3. 爲了使Wireshark同時統計數據報文，例如，TCP報文內部的HTTP報文，關閉Allow sub-dissector選項，對TCP數據流從新統計。可在Preferences菜單或Packet Details面板中右鍵TCP來實現。

Conversations：

1. 在Statistics菜單中，選擇Coversations。

2. 會看到如下窗口：

3. 能夠選擇第2層以太網統計數據，第3層IP統計數據，或第4層TCP或UDP統計數據。

4. 能夠選擇如下統計工具：

• On layer 2(Ethernet)：查找並過濾廣播風暴或
• On layer 3 or 4(TCP/IP)：經過互聯網路由器端口並行鏈接，查看誰在向ISP傳輸數據

小貼士：

若是你看到互聯網上某一IP地址經過端口80（HTTP）向外傳輸大量數據流，你就須要將該地址複製入瀏覽器而且查看你的用戶與哪個網站通信最多。

若是沒有獲得結果，只需到標準DNS查詢站點（Google一下DNS lookup）查看哪種流量佔用了你的網線。

5. 也能夠經過選擇位於窗口左下方的Limit to display filter複選框，將會話統計信息進行顯示過濾。這樣，僅呈現全部經過顯示過濾條件的統計數據。

6.要查看IP地址對應名稱，能夠選擇Name resolution複選框。要查看IP名稱解析，進入View | Name Resolution | Enable for Network layer進行激活。

7. 對於TCP或UDP，能夠在Packet list中對指定報文進行標記，以後從菜單中選擇Follow TCP Stream或Follow UDP Stream。從而定義一個顯示過濾條件，僅顯示指定數據流。

使用要點：

網絡會話是兩個指定終端之間的數據流。例如，IP會話是兩個IP地址之間的全部數據流，TCP會話包含了全部TCP鏈接。

經過Conversations列表，能看出不少網絡問題。

以太網會話統計

在Ethernet conversations statistics中，查找如下問題：

• 大量的廣播風暴：能夠看見較輕微的廣播風暴；而對於每秒數千甚至數萬個報文的嚴重廣播風暴，Wireshark會中止顯示數據而且屏幕凍結。只有斷開Wireshark鏈接時才能看見。
• 若是你看到來自某一MAC地址的大量數據，查看會話第一部分的vendor ID，會給你一些致使問題的線索。即便MAC地址的第一部分標識了vendor，但它並不必定就標識了PC自己。這是因爲MAC地址屬於PC上安裝的以太 網芯片廠商，而並不必定屬於PC製造商。若是沒法識別數據流來源地址，能夠ping嫌疑地址並經過ARP獲取它的MAC地址，在交換機中查找該地址，若是 有操做系統的話直接用find命令來定位。

IP會話統計

在IP conversations statistics中，查找如下問題：

• 查看收發大量數據流的IP地址。若是是你知道的服務器（你記得服務器的地址或地址範圍），那問題就解決了；但也有可能只是某臺設備正在掃描網絡，或僅是一臺產生過多數據的PC。
• 查看掃描模式（scan pattern）。這多是一次正常的掃描，如SNMP軟件發送ping報文以查找網絡，但一般掃描都不是好事情。
• 一次典型的掃描模式以下圖所示：

本例中的掃描模式，一個IP地址，192.168.110.58，發送ICMP報文至192.170.3.44, 192.170.3.45, 192.170.3.46, 192.170.3.47,等等（上圖僅顯示掃描的很小一部分）。這種狀況下咱們有一個蠕蟲病毒感染了網絡上的全部PC，在它感染PC的時候，它就開始產 生ICMP請求並將它們發送至網絡。這些窄帶鏈接（例如：WAN鏈接）能夠很容易地被封鎖。

TCP/UDP會話統計

• 查看帶有太多TCP鏈接的設備。每個PC合理的鏈接數是10到20個，上百個則是不正常的。
• 嘗試查找沒法辨識的端口號。它多是正常的，但也多是有問題的。下圖顯示了一次典型的TCP掃描：

Endpoints:

1. 從statistics菜單，選擇Endpoints：

2. 出現如下窗口：

3. 此窗口中，可以看到第2,3,4層的endpoints，也就是以太網，IP, TCP或UDP。

使用要點：

這一工具列出了Wireshark發現的全部endpoints上的統計信息。能夠是如下任意一種狀況：

• 少許以太網endpoints（MAC地址）與大量IP終端節點（IP地址）：可能的狀況例如，一個路由器從不少遠端設備收發報文，咱們會看見路由器的MAC地址及不少IP地址經由此處。
• 少許IP終端節點與大量TCP終端節點：可能的狀況是每一臺主機有不少個TCP鏈接。多是有不少鏈接的服務器的一個正常操做，也多是一種網絡攻擊（如SYN攻擊）。

如下是一個網絡中心的抓包示例，一個內部網絡有四個HP服務器和一個Cisco路由器，MAC地址的第一部分已經解析了廠商名稱：

當咱們查看IPv4:191下的endpoints，咱們看到有不少來自192.168.10.0, 192.168.30.0，以及其餘網絡地址。

HTTP:

1. 從statistics菜單，選擇HTTP，將會出現如下窗口：

在HTTP子菜單中，能夠看到如下信息：

Packet Counter：

每個網站的報文數量。幫助識別有多少響應和請求。

Requests：

各網站的請求分佈。

Load Distribution：

各網站的負載分佈。

按照如下操做步驟查看Packet Counter統計信息：

1. 進入Statistics | HTTP | Packet Counter。

2. 顯示如下過濾窗口：

3. 此窗口中，可設置過濾條件以查看符合過濾條件的統計信息。若是想要查看整個抓包文件的統計信息，留白不填。這就會顯示IP層之上的統計信息，也就是全部HTTP報文。

4. 點擊Create Stat按鈕，會看到如下窗口：

若是要查看某一特定節點的HTTP統計信息，能夠經過display filter的方式配置過濾條件。

按照如下操做步驟查看HTTP Requests統計信息：

1. 進入Statistics | HTTP | Requests，出現如下窗口：

2. 選擇所需過濾條件。對於全部數據，留白。

3. 點擊Create Stat按鈕，會出現如下窗口：

4. 要得到指定HTTP主機的統計信息，設置過濾條件http.host contains <host_name> 或 http.host==<host_name>。

5. 例如，經過設置過濾條件http.host contains ndi-com.com，能夠得到站點 www.ndi-com.com的統計信息，以下圖所示：

6. 結果以下圖所示：

按照如下操做步驟查看Load Distribution統計信息：

1. 進入Statistics | HTTP | Load Distribution。

2. 出現如下窗口：

3. 選擇所需過濾條件。對於全部數據，留白。

4. 點擊Create Stat按鈕，會出現如下窗口：

使用要點：

當咱們打開一個網頁，一般會向若干個URL發送請求。本例中，咱們打開的其中一個網頁是www.cnn.com，並將咱們導向edition.cnn.com。咱們發送了若干個請求：到root URL，到breaking_news URL，以及主頁上兩個其餘位置。

 

一站式學習Wireshark（八）：應用Wireshark過濾條件抓取特定數據流

2014/07/22 · IT技術 · WireShark

分享到： 18

• Android-多平臺分享
• C++遠征之模板篇
• Sass入門篇
• PHP實現微信公衆平臺開發—提高篇

原文出處： EMC中文支持論壇   歡迎分享原創到伯樂頭條

應用抓包過濾，選擇Capture | Options，擴展窗口查看到Capture Filter欄。雙擊選定的接口，以下圖所示，彈出Edit Interface Settints窗口。

下圖顯示了Edit Interface Settings窗口，這裏能夠設置抓包過濾條件。若是你確知抓包過 濾條件的語法，直接在Capture Filter區域輸入。在輸入錯誤時，Wireshark經過紅色背景區域代表沒法處理過濾條件。最有可能的狀況是，過濾條件中含有輸入錯誤，或是使用了 display filter的語法。

點擊Capture Filter按鈕查看並選擇已保存的抓包過濾條件。

更多信息

抓取指定IP地址的數據流:

若是你的抓包環境下有不少主機正在通信，能夠考慮使用所觀察主機的IP地址來進行過濾。如下爲IP地址抓包過濾示例：

• host 10.3.1.1：抓取發到/來自10.3.1.1的數據流
• host 2406:da00:ff00::6b16:f02d：抓取發到/來自IPv6地址2406:da00:ff00::6b16:f02d的數據流
• not host 10.3.1.1：抓取除了發到/來自10.3.1.1之外的全部數據流
• src host 10.3.1.1：抓取來自10.3.1.1的數據流
• dst host 10.3.1.1：抓取發到10.3.1.1的數據流
• host 10.3.1.1 or 10.3.1.2：抓取發到/來自10.3.1.1，以及與之通信的全部數據流，與10.3.1.2，以及與之通信的全部數據流
• host www.espn.com：抓取發到/來自全部解析爲www.espn.com的IP地址的數據流

抓取指定IP地址範圍的數據流:

當你須要抓取來自/發到一組地址的數據流，能夠採用CIDR(無類別域間路由，Classless Interdomain Routing)格式或使用mask參數。

• net 10.3.0.0/16：抓取網絡10.3.0.0上發到/來自全部主機的數據流(16表示長度)
• net 10.3.0.0 mask 255.255.0.0：與以前的過濾結果相同
• ip6 net 2406:da00:ff00::/64：抓取網絡2406:da00:ff00:0000(IPv6)上發到/來自全部主機的數據流
• not dst net 10.3.0.0/16：抓取除了發到以10.3開頭的IP地址之外的全部數據流
• not src net 10.3.0.0/16：抓取除了來自以10.3開頭的IP地址之外的全部數據流
• ip proto <protocol code>：抓取ip協議字段等於<protocol code>值的報文。如TCP(code 6), UDP(code 17), ICMP(code 1)。
• ip[2:2]==<number>：ip報文大小
• ip[8]==<number>：TTL(Time to Live)值
• ip[9]==<number>：協議值
• icmp[icmptype]==<identifier>: 抓取 ICMP代碼等於identifier的ICMP報文, 如icmp-echo 以及 icmp-request。

方括號中第一個數字表示從協議頭開始的偏移量，第二個數字表示須要觀察多少位。

抓取發到廣播或多播地址的數據流:

只需偵聽廣播或多播數據流，就能夠掌握網絡上主機的許多信息。

• ip broadcast：抓取廣播報文
• ip multicast：抓取多播報文
• dst host ff02::1：抓取到IPv6多播地址全部主機的數據流
• dst host ff02::2：抓取到IPv6多播地址全部路由器的數據流

小貼士：

Wireshark包含了一些默認的抓包過濾條件。點擊主工具欄的Edit Capture Filters，跳轉到已保存抓包過濾列表。你會發現一些常見抓包過濾的示例。

抓取基於MAC地址的數據流:

當你須要抓取發到/來自某一主機的IPv4或IPv6數據流，可建立基於主機MAC地址的抓包過濾條件。

應用MAC地址時，需確保與目標主機處於同一網段。

• ether host 00:08:15:00:08:15：抓取發到/來自00:08:15:00:08:15的數據流
• ether src 02:0A:42:23:41:AC：抓取來自02:0A:42:23:41:AC的數據流
• ether dst 02:0A:42:23:41:AC：抓取發到02:0A:42:23:41:AC的數據流
• not ether host 00:08:15:00:08:15：抓取除了發到/來自00:08:15:00:08:15之外的全部數據流
• ether broadcast或ether dst ff:ff:ff:ff:ff:ff：抓取廣播報文
• ether multicast：多播報文
• 抓取指定以太網類型的報文：ether proto 0800
• 抓取指定VLAN：vlan <vlan number>
• 抓取指定幾個VLAN：vlan <vlan number> and vlan <vlan number>

抓取基於指定應用的數據流:

你可能須要查看基於一個或幾個應用的數據流。抓包過濾器語法沒法識別應用名，所以須要根據端口號來定義應用。經過目標應用的TCP或UDP端口號，將不相關的報文過濾掉。

• port 53：抓取發到/來自端口53的UDP/TCP數據流（典型是DNS數據流）
• not port 53：抓取除了發到/來自端口53之外的UDP/TCP數據流
• port 80：抓取發到/來自端口80的UDP/TCP數據流（典型是HTTP數據流）
• udp port 67：抓取發到/來自端口67的UDP數據流（典型是DHCP據流）
• tcp port 21：抓取發到/來自端口21的TCP數據流（典型是FTP命令通道）
• portrange 1-80：抓取發到/來自端口1-80的全部UDP/TCP數據流
• tcp portrange 1-80：抓取發到/來自端口1-80的全部TCP數據流

抓取結合端口的數據流:

當你須要抓取多個不連續端口號的數據流，將它們經過邏輯符號鏈接起來，以下圖所示：

• port 20 or port 21：抓取發到/來自端口20或21的UDP/TCP數據流（典型是FTP數據和命令端口）
• host 10.3.1.1 and port 80：抓取發到/來自10.3.1.1端口80的數據流
• host 10.3.1.1 and not port 80：抓取發到/來自10.3.1.1除了端口80之外的數據流
• udp src port 68 and udp dst port 67：抓取從端口68到端口67的全部UDP數據流（典型是從DHCP客戶端到DHCP服務器）
• udp src port 67 and udp dst port 68：抓取從端口67到端口68的全部UDP數據流（典型是從DHCP服務器到DHCP客戶端）
• 抓取TCP鏈接的開始（SYN）和結束（FIN）報文，配置tcp[tcpflags] & (tcp-syn|tcp-fin)!=0
• 抓取全部RST(Reset)標誌位爲1的TCP報文，配置tcp[tcpflags] & (tcp-rst)!=0
• less <length>：抓取小於等於某一長度的報文，等同於len <=<length>
• greater <length>：抓取大於等於某一長度的報文，等同於len >=<length>

SYN: 簡歷鏈接的信號

FIN: 關閉鏈接的信號

ACK: 確認接收數據的信號

RST: 當即關閉鏈接的信號

PSH: 推信號，儘快將數據轉由應用處理

• tcp[13] & 0×00 = 0: No flags set (null scan)
• tcp[13] & 0×01 = 1: FIN set and ACK not set
• tcp[13] & 0×03 = 3: SYN set and FIN set
• tcp[13] & 0×05 = 5: RST set and FIN set
• tcp[13] & 0×06 = 6: SYN set and RST set
• tcp[13] & 0×08 = 8: PSH set and ACK not set

tcp[13]是從協議頭開始的偏移量，0,1,3,5,6,8是標識位

儘可能避免使用抓包過濾。即使多看幾個報文，也比漏看一個報文要好。當你抓取了大量報文的時候，用顯示過濾（過濾選項也更多）來重點查看某一數據流。

小貼士：

若是你須要查看TCP幀中的某一ASCII字符串，用Wireshark String-Matching Capture Filter Generator(http://www.wireshark.org/tools/string-cf.html)。例如，想要抓取HTTP GET報文，輸入GET並將TCP偏移量設置爲0。