一站式学习Wireshark（转载）
一站式學習Wireshark（一）：Wireshark基本用法
分享到：- 與《YII框架》不得不說的故事—擴展篇
- sass進階篇
- IOS基礎教程之界面初體驗
- Spring事務管理
按照國際慣例，從最基本的說起。
抓取報文:
下載和安裝好Wireshark之后，啟動Wireshark并且在接口列表中選擇接口名，然后開始在此接口上抓包。例如，如果想要在無線網絡上抓取流量，點擊無線接口。點擊Capture Options可以配置高級屬性，但現在無此必要。
點擊接口名稱之后，就可以看到實時接收的報文。Wireshark會捕捉系統發(fā)送和接收的每一個報文。如果抓取的接口是無線并且選項選取的是混合模式，那么也會看到網絡上其他報文。
上端面板每一行對應一個網絡報文，默認顯示報文接收時間（相對開始抓取的時間點），源和目標IP地址，使用協議和報文相關信息。點擊某一行可以在下 面兩個窗口看到更多信息。“+”圖標顯示報文里面每一層的詳細信息。底端窗口同時以十六進制和ASCII碼的方式列出報文內容。
需要停止抓取報文的時候，點擊左上角的停止按鍵。
色彩標識:
進行到這里已經看到報文以綠色，藍色，黑色顯示出來。Wireshark通過顏色讓各種流量的報文一目了然。比如默認綠色是TCP報文，深藍色是DNS，淺藍是UDP，黑色標識出有問題的TCP報文——比如亂序報文。
報文樣本:
比如說你在家安裝了Wireshark，但家用LAN環(huán)境下沒有感興趣的報文可供觀察，那么可以去Wireshark wiki下載報文樣本文件。
打開一個抓取文件相當簡單，在主界面上點擊Open并瀏覽文件即可。也可以在Wireshark里保存自己的抓包文件并稍后打開。
過濾報文:
如果正在嘗試分析問題，比如打電話的時候某一程序發(fā)送的報文，可以關閉所有其他使用網絡的應用來減少流量。但還是可能有大批報文需要篩選，這時要用到Wireshark過濾器。
最基本的方式就是在窗口頂端過濾欄輸入并點擊Apply（或按下回車）。例如，輸入“dns”就會只看到DNS報文。輸入的時候，Wireshark會幫助自動完成過濾條件。
也可以點擊Analyze菜單并選擇Display Filters來創(chuàng)建新的過濾條件。
另一件很有趣的事情是你可以右鍵報文并選擇Follow TCP Stream。
你會看到在服務器和目標端之間的全部會話。
關閉窗口之后，你會發(fā)現過濾條件自動被引用了——Wireshark顯示構成會話的報文。
檢查報文:
選中一個報文之后，就可以深入挖掘它的內容了。
也可以在這里創(chuàng)建過濾條件——只需右鍵細節(jié)并使用Apply as Filter子菜單，就可以根據此細節(jié)創(chuàng)建過濾條件。
Wireshark是一個非常之強大的工具，第一節(jié)只介紹它的最基本用法。網絡專家用它來debug網絡協議實現細節(jié)，檢查安全問題，網絡協議內部構件等等。
?
一站式學習Wireshark（二）：應用Wireshark觀察基本網絡協議
分享到：- CSS3圖片動態(tài)提示效果
- Python操作MySQL數據庫
- C++遠征之多態(tài)篇
- python進階
TCP:
TCP/IP通過三次握手建立一個連接。這一過程中的三種報文是：SYN，SYN/ACK，ACK。
第一步是找到PC發(fā)送到網絡服務器的第一個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。這就創(chuàng)建了一個只顯示TCP會話報文的自動過濾條件。
這一步驟會彈出一個會話顯示窗口，默認情況下包含TCP會話的ASCII代碼，客戶端報文用紅色表示服務器報文則為藍色。
窗口類似下圖所示，對于讀取協議有效載荷非常有幫助，比如HTTP，SMTP，FTP。
更改為十六進制Dump模式查看載荷的十六進制代碼，如下圖所示：
關閉彈出窗口，Wireshark就只顯示所選TCP報文流。現在可以輕松分辨出3次握手信號。
注意：這里Wireshark自動為此TCP會話創(chuàng)建了一個顯示過濾。本例中：(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號報文是從客戶端發(fā)送至服務器端的SYN報文，此報文用于與服務器建立同步，確保客戶端和服務器端的通信按次序傳輸。SYN報文的頭部有一個32 bit序列號。底端對話框顯示了報文一些有用信息如報文類型，序列號。
SYN/ACK報文：
7號報文是服務器的響應。一旦服務器接收到客戶端的SYN報文，就讀取報文的序列號并且使用此編號作為響應，也就是說它告知客戶機，服務器接收到了SYN報文，通過對原SYN報文序列號加一并且作為響應編號來實現，之后客戶端就知道服務器能夠接收通信。
ACK報文：
8號報文是客戶端對服務器發(fā)送的確認報文，告訴服務器客戶端接收到了SYN/ACK報文，并且與前一步一樣客戶端也將序列號加一，此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手。
ARP & ICMP：
開啟Wireshark抓包。打開Windows控制臺窗口，使用ping命令行工具查看與相鄰機器的連接狀況。
停止抓包之后，Wireshark如下圖所示。
ARP和ICMP報文相對較難辨認，創(chuàng)建只顯示ARP或ICMP的過濾條件。
ARP報文：
地址解析協議，即ARP（Address Resolution Protocol），是根據IP地址獲取物理地址的一個TCP/IP協議。其功能是：主機將ARP請求廣播到網絡上的所有主機，并接收返回消息，確定目標IP地址的物理地址，同時將IP地址和硬件地址存入本機ARP緩存中，下次請求時直接查詢ARP緩存。
最初從PC發(fā)出的ARP請求確定IP地址192.168.1.1的MAC地址，并從相鄰系統收到ARP回復。ARP請求之后，會看到ICMP報文。
ICMP報文：
網絡控制消息協定（Internet Control Message Protocol，ICMP）用于TCP/IP網絡中發(fā)送控制消息，提供可能發(fā)生在通信環(huán)境中的各種問題反饋，通過這些信息，令管理者可以對所發(fā)生的問題作出診斷，然后采取適當的措施解決。
PC發(fā)送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方式，實現容易，軟件開發(fā)部署也簡單，無需額外的客戶端，使用瀏覽器即可使用。這一過程開始于請求服務器傳送網絡文件。
從上圖可見報文中包括一個GET命令，當HTTP發(fā)送初始GET命令之后，TCP繼續(xù)數據傳輸過程，接下來的鏈接過程中HTTP會從服務器請求數據 并使用TCP將數據傳回客戶端。傳送數據之前，服務器通過發(fā)送HTTP OK消息告知客戶端請求有效。如果服務器沒有將目標發(fā)送給客戶端的許可，將會返回403 Forbidden。如果服務器找不到客戶端所請求的目標，會返回404。
如果沒有更多數據，連接可被終止，類似于TCP三次握手信號的SYN和ACK報文，這里發(fā)送的是FIN和ACK報文。當服務器結束傳送數據，就發(fā)送 FIN/ACK給客戶端，此報文表示結束連接。接下來客戶端返回ACK報文并且對FIN/ACK中的序列號加1。這就從服務器端終止了通信。要結束這一過 程客戶端必須重新對服務器端發(fā)起這一過程。必須在客戶端和服務器端都發(fā)起并確認FIN/ACK過程。
?
一站式學習Wireshark（三）：應用Wireshark IO圖形工具分析數據流
分享到：- Struts2攔截器淺析
- 使用Struts2+Hibernate開發(fā)學生信息管理功能
- C#開發(fā)輕松入門
- 神奇的JpGraph類庫
基本IO Graphs:
IO graphs是一個非常好用的工具。基本的Wireshark IO graph會顯示抓包文件中的整體流量情況，通常是以每秒為單位（報文數或字節(jié)數）。默認X軸時間間隔是1秒，Y軸是每一時間間隔的報文數。如果想要查看 每秒bit數或byte數，點擊“Unit”，在“Y Axis”下拉列表中選擇想要查看的內容。這是一種基本的應用，對于查看流量中的波峰/波谷很有幫助。要進一步查看，點擊圖形中的任意點就會看到報文的細 節(jié)。
為了講解方便，點擊示例報文包，或用自己的wireshark點擊Statistics – IO Graphs。這個抓包是HTTP下載遇到報文丟失的情況。
注意：過濾條件為空，此圖形顯示所有流量。
這個默認條件下的顯示在大多數troubleshooting中并不是非常有用。將Y軸改為bits/tick這樣就可以看到每秒的流量。從這張圖 可以看到峰值速率是300kbps左右。如果你看到有些地方流量下降為零，那可能是一個出問題的點。這個問題在圖上很好發(fā)現，但在看報文列表時可能不那么 明顯。
過濾：
每一個圖形都可以應用一個過濾條件。這里創(chuàng)建兩個不同的graph，一個HTTP一個ICMP。可以看到過濾條件中Graph 1使用“http”Graph 2使用“icmp”。圖中可以看到紅色ICMP流量中有些間隙，進一步分析。
創(chuàng)建兩個圖形，一個顯示ICMP Echo（Type=8）一個顯示ICMP Reply（Type=0）。正常情況下對于每一個echo請求會有一個連續(xù)的reply。這里的情況是：
可以看到紅色脈沖線(icmp type==0 – ICMP Reply)中間有間隙，而整張圖中ICMP請求保持連續(xù)。這意味著有些reply沒有接收到。這是由于報文丟失導致的reply drop。CLI中看到的ping信息如下：
常用排錯過濾條件:
對于排查網絡延時/應用問題有一些過濾條件是非常有用的：
tcp.analysis.lost_segment：表明已經在抓包中看到不連續(xù)的序列號。報文丟失會造成重復的ACK，這會導致重傳。
tcp.analysis.duplicate_ack：顯示被確認過不止一次的報文。大涼的重復ACK是TCP端點之間高延時的跡象。
tcp.analysis.retransmission：顯示抓包中的所有重傳。如果重傳次數不多的話還是正常的，過多重傳可能有問題。這通常意味著應用性能緩慢和/或用戶報文丟失。
tcp.analysis.window_update：將傳輸過程中的TCP window大小圖形化。如果看到窗口大小下降為零，這意味著發(fā)送方已經退出了，并等待接收方確認所有已傳送數據。這可能表明接收端已經不堪重負了。
tcp.analysis.bytes_in_flight：某一時間點網絡上未確認字節(jié)數。未確認字節(jié)數不能超過你的TCP窗口大小（定義于最初3此TCP握手），為了最大化吞吐量你想要獲得盡可能接近TCP窗口大小。如果看到連續(xù)低于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。從這張圖中，可以看到這些事件發(fā)生的時間點，以及在整體流量中所占的比例。
函數:
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個報文。如果你看見幀之間平均延時相對較低但突然某一點延時很長，可點擊這一幀，看看這一時間點究竟發(fā)生了什么。
Count( )???????
此函數計算時間間隔內事件發(fā)生的次數，在查看TCP分析標識符時很有用，例如重傳。例圖如下：
Sum( )?????????
該函數統計事件的累加值。有兩種常見的用例是看在捕獲TCP數據量，以及檢查TCP序列號。讓我們看看第一個TCP長度的例子。創(chuàng)建兩個圖，一個使 用客戶端IP 192.168.1.4為源，另一個使用客戶端IP作為一個目的地址。每個圖我們將sum()功能結合tcp.len過濾條件。拆分成兩個不同的圖我們就 可以看到在一個單一的方向移動的數據量。
從圖表中我們可以看到，發(fā)送到客戶端的數據量（IP.DST = = 192.168.1.4過濾條件）比來自客戶端的數據量要高。在圖中紅色表示。黑條顯示從客戶端到服務器的數據，相對數據量很小。這是有道理的，因為客戶 只是請求文件和收到之后發(fā)送確認數據，而服務器發(fā)送大文件。很重要的一點是，如果你交換了圖的順序，把客戶端的IP作為圖1的目標地址，并且客戶端IP作 為圖2的源地址，采用了FBAR的時候可能看不到正確的數據顯示。因為圖編號越低表示在前臺顯示，可能會覆蓋較高圖號。
現在讓我們看一下同一個數據包丟失和延遲的TCP序列號。
可以在圖中看到若干峰值和下降，表示TCP傳輸有問題。與正常TCP報文比較：
這張圖可以看到TCP序列號相當穩(wěn)定地增加，表示傳輸平穩(wěn)，沒有過多重傳或丟包。
?
一站式學習Wireshark（四）：網絡性能排查之TCP重傳與重復ACK
分享到：- 側欄工具條開發(fā)
- PHP入門篇
- C++遠征之繼承篇
- 觀察者模式
作為網絡管理員，很多時間必然會耗費在修復慢速服務器和其他終端。但用戶感到網絡運行緩慢并不意味著就是網絡問題。
解決網絡性能問題，首先從TCP錯誤恢復功能（TCP重傳與重復ACK）和流控功能說起。之后闡述如何發(fā)現網絡慢速之源。最后，對網絡各組成部分上的數據流進行概況分析。這幾張內容將會幫助讀者識別，診斷，以及排查慢速網絡。
更多信息
接下來的內容，較多是黑白圖片了。雖然看起來有點不爽，但還是很值得一看。
TCP錯誤恢復功能：
TCP的錯誤恢復功能是定位，診斷及修復網絡延時的最佳工具。延時可以在單程也可以往返方向測量。高延時是網絡管理員的頭號大敵。本節(jié)我們討論TCP高延時是如何導致序列號和確認號亂序的。
TCP重傳：
主機報文重傳是TCP最基本的錯誤恢復功能，它的目的是防止報文丟失。
報文丟失的可能因素有很多種，包括應用故障，路由設備過載，或暫時的服務宕機。報文級別速度是很高的，而通常報文丟失是暫時的，因此TCP能夠發(fā)現和恢復報文丟失顯得尤為重要。
決定報文是否有必要重傳的主要機制是重傳計時器（retransmission timer），它的主要功能是維護重傳超時（RTO）值。當報文使用TCP傳輸時，重傳計時器啟動，收到ACK時計時器停止。報文發(fā)送至接收到ACK的時 間稱為往返時間（RTT）。對若干次時間取平均值，該值用于確定最終RTO值。在最終RTO值確定之前，確定每一次報文傳輸是否有丟包發(fā)生使用重傳計時 器，下圖說明了TCP重傳過程。
當報文發(fā)送之后，但接收方尚未發(fā)送TCP ACK報文，發(fā)送方假設源報文丟失并將其重傳。重傳之后，RTO值加倍；如果在2倍RTO值到達之前還是沒有收到ACK報文，就再次重傳。如果仍然沒有收 到ACK，那么RTO值再次加倍。如此持續(xù)下去，每次重傳RTO都翻倍，直到收到ACK報文或發(fā)送方達到配置的最大重傳次數。
最大重傳次數取決于發(fā)送操作系統的配置值。默認情況下，Windows主機默認重傳5次。大多數Linux系統默認最大15次。兩種操作系統都可配置。
示例如下圖：
TCP重傳過程發(fā)送的第一個報文如下圖所示（圖片不很清楚，已經盡力了）：
這是一個TCP PSH/ACK報文①，包含648字節(jié)數據②，從10.3.30.1發(fā)送至10.3.71.7。這是一個典型的數據報文。
在通常情況下，第一個報文發(fā)送之后很快會收到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是指在接收方收到亂序報文時，所發(fā)出的一類TCP報文。TCP使用報文頭的序列號和確認號以有效保證數據按照發(fā)送的順序接收和重組。
當TCP連接建立以后，握手過程中交換的一個最重要的信息是初始序列號（ISN）。一旦連接雙方設定了ISN之后，接下來發(fā)送的報文所包含的序列號增加一個數據載荷值。
假設有個主機ISN是5000，發(fā)送500字節(jié)報文至接收方。一旦報文接收之后，接收端回復一個ACK號為5500的TCP ACK報文，基于以下公式：
Sequence Number In + Bytes of Data Received = Acknowledgment Number Out
按照上述計算結果，返回發(fā)送端的確認編號實際上是接收端希望收到的序列號。示例如下圖：
數據接收方通過序列號來檢查報文丟失。接收方通過追蹤接收到的序列號，能夠確認序列號是否亂序。當接收方收到一個不正常的序列號，它會假設傳輸過程中有報 文丟失。為了正確重傳數據，接收方必須擁有丟失報文，所以它發(fā)送包含有丟失報文正確序列號的ACK報文，以便發(fā)送方重傳此報文。
當重傳主機從發(fā)送端接收到3個重復ACK時，它會假設此報文確實在傳送中丟失，并且立即發(fā)送一個快速重傳。一旦觸發(fā)了快速重傳，所有正在傳輸的其他報文都被放入隊列中，直到快速重傳報文發(fā)送為止。過程如下圖所示：
承接上文的彩圖：
本例中第一個報文如下圖：
這是一個TCP ACK報文，從數據接收端（172.31.136.85）發(fā)給發(fā)送端（195.81.202.68）①，確認前一個報文所發(fā)送的數據。
此報文中的確認編號是1310973186②，應當是下一個接收報文的序列號，如下圖所示：
不幸的是接收端的序列號是1310984130①，并不是所期望的值。這意味著報文在傳送中丟失。接收端注意到報文亂序，并且在第三個報文中發(fā)送重復ACK，如下圖所示：
可以通過以下兩種方式之一來確認這是一個重復ACK：
在Packet Detaisl面板中的Info欄。報文呈現黑色背景紅色字體。
SEQ/ACK Analysis下的Packet Deatails面板。擴展這一欄會發(fā)現報文顯示為duplicate ACK。接下來幾個報文重復此過程。如下圖所示：
此文件中的第四個報文是發(fā)送端所發(fā)出具有錯誤序列號①的另一個數據塊。因此，接收端發(fā)送第二個重復ACK②。接收端又收到一個亂序報文③。從而觸發(fā)了第三以及最后一個重復ACK④.
一旦發(fā)送方接收到接收方所發(fā)來的第三個重復ACK，它就會暫停所有傳輸報文并且重傳丟失報文，下圖顯示了快速重傳過程：
重傳報文同樣可以通過Packet List面板的Info欄觀察到。報文呈現黑色背景紅色字體。這個報文的SEQ/ACK Analysis截面告訴我們這可能是一個快速重傳幀。（標識報文為快速重傳的信息不是報文本身所包含的內容，而是Wireshark的功能）。最后一個 報文是接收到快速重傳的ACK。
?
一站式學習Wireshark（五）：TCP窗口與擁塞處理
分享到：- 前端開發(fā)工具技巧介紹—Sublime篇
- 瀑布流布局
- SEO在網頁制作中的應用
- MySQL開發(fā)技巧（三）
TCP通過滑動窗口機制檢測丟包，并在丟包發(fā)生時調整數據傳輸速率。滑動窗口機制利用數據接收端的接收窗口來控制數據流。
接收窗口值由數據接收端指定，以字節(jié)數形式存儲于TCP報文頭，并告知傳輸設備有多少數據將會存儲在TCP緩沖區(qū)。緩沖區(qū)就是數據暫時放置的地方， 直至傳遞至應用層協議等待處理。因此，發(fā)送端每次只能發(fā)送Window Size字段指定的數據量。為了使發(fā)送端繼續(xù)傳送數據，接收端必須發(fā)送確認信息：之前的數據接收到了。同時必須對占用緩沖區(qū)的數據進行處理以釋放緩存空 間。下圖顯示了接收窗口是如何工作的：
上圖中，客戶端向服務器發(fā)送數據，服務器接收窗口是5000字節(jié)。客戶端發(fā)送了2500字節(jié)，服務器緩沖區(qū)還剩2500字節(jié)，之后又發(fā)送了2000 字節(jié)，從而緩沖區(qū)只剩500字節(jié)。服務器發(fā)送確認信息。對緩存中數據進行處理并清空緩存。此過程重復進行，客戶端又發(fā)送3000字節(jié)和1000字節(jié)，服務 器緩存減少至1000字節(jié)，客戶端再次確認數據并處理緩存中內容。
更多信息
調整窗口大小：
當TCP堆 棧接收到數據的時候，生成一個確認信息并以回復的方式發(fā)送，但是放置在接收端緩存中的數據并不總是立即被處理。當服務器忙于處理從多個客戶端接收的報文， 服務器很有可能因為清理緩存而變得緩慢，無法騰出空間接收新的數據，如果沒有流控，則可能會造成丟包和數據損壞。好在，接收窗口所設定的速率無法使服務器 正常處理數據時，能夠調整接收窗口大小。通過減小返回給發(fā)送端的ACK報文的TCP頭窗口大小值來實現。如下圖所示：
上圖中，服務器初始窗口大小為5000字節(jié)。客戶端發(fā)送2000字節(jié)，之后又發(fā)送了2000字節(jié)，緩沖區(qū)中只有1000字節(jié)可用。服務器意識到緩沖 區(qū)正在快速填滿，它知道如果數據繼續(xù)以此速率傳輸，很快會有報文丟失。為了防止報文丟失，服務器發(fā)送確認信息給客戶端，更新窗口大小為1000字節(jié)。結 果，客戶端減少數據發(fā)送，服務器以可以接受的速率處理緩存內容，即保持數據流以穩(wěn)定的速率傳輸。
調整窗口大小在兩個方向都是可行的。當服務器能夠更加快速的處理報文時，它會發(fā)送一個較大窗口的ACK報文。
零窗口暫停數據流：
某些情況下，服務器無法再處理從客戶端發(fā)送的數據。可能是由于內存不足，處理能力不夠，或其他原因。這可能會造成數據被丟棄以及傳輸暫停，但接收窗口能夠幫助減小負面影響。
當上述情況發(fā)生時，服務器會發(fā)送窗口為0的報文。當客戶端接收到此報文時，它會暫停所有數據傳輸，但會保持與服務器的連接以傳輸探測（keep- alive）報文。探測報文在客戶端以穩(wěn)定間隙發(fā)送，以查看服務器接收窗口狀態(tài)。一旦服務器能夠再次處理數據，將會返回非零值窗口大小，傳輸會恢復。下圖 示例了零窗口通知過程。
服務器初始接收數據窗口為5000字節(jié)大小。從客戶端接收4000字節(jié)數據之后，服務器負載變得非常繁重，無法繼續(xù)處理客戶端任何數據。服務器于是 發(fā)送窗口大小值為0的報文。客戶端暫停數據傳輸并發(fā)送一個探測報文。探測報文之后，服務器回復以告知客戶端現在可以接收數據的報文，以及窗口大小為 1000字節(jié)。客戶端恢復傳送數據。
TCP滑動窗口實戰(zhàn)：
本例中，開始從192.168.0.20發(fā)送至192.168.0.30。我們關心的是窗口大小字段，可以從Packet List面板的Info欄以及Packet Details的TCP報文頭看到。前三個報文后，可看到該值立刻減小，如下圖所示：
窗口大小值從第一個報文的8760字節(jié)變成第二個報文的5840字節(jié)到第三個報文的2920字節(jié)①。窗口大小值的減小是主機延時的典型標志。在時間 欄注意到這一過程發(fā)生的非常迅速②。當窗口大小迅速減小的時候，通常就有可能下降為零。這就是第四個報文所發(fā)生的，如下圖所示：
第四個報文從192.168.0.20發(fā)送至192.168.0.30，目的是告訴192.168.0.30它不再接收任何數據。0值見于TCP報 文頭①，Wireshark的Packet List面板Info欄，以及TCP報文頭的SEQ/ACK Analysis字段②也告訴我們這是一個0窗口報文。
一旦發(fā)送了零窗口報文，192.168.0.30的設備不會再發(fā)送任何數據，直到收到從192.168.0.20的窗口更新，告知窗口大小已經增加了。本例中導致零窗口的問題是暫時的，所以在下一個報文中發(fā)送了窗口更新信息，如下圖所示。
本例中，窗口大小增加到一個非常健康的數值64，240字節(jié)①。Wireshark再次在SEQ/ACK Analysis告訴我們這是一個窗口更新。
一旦收到更新報文，192.168.0.30的主機就再次開始發(fā)送數據，在報文6和報文7中。這一過程發(fā)生很快。如果它持續(xù)時間再長一點，就可能會導致網絡的潛在中斷，引起數據傳輸減慢或失敗。
下一個關于滑動窗口的例子，第一個報文是正常HTTP，從195.81.202.68至172.31.136.85。此報文之后立刻跟隨一個從172.31.136.85發(fā)送的零窗口報文，如下圖所示：
這與上一個例子中的零窗口報文十分類似，但結果顯著不同，172.31.136.85主機不是發(fā)送一個窗口更新并回復通訊，而是一個探測報文，如下圖所示：
此報文被Wireshark標注為探測報文①。時間欄告訴我們這一報文發(fā)生于最后一個接收到的報文3.4秒之后。這一過程持續(xù)若干次，一端發(fā)送零窗口報文另一端發(fā)送探測報文，如下圖所示：
探測報文發(fā)送間隙為3.4，6.8，13.5秒。這一過程可能會持續(xù)相當長一段時間，取決于通訊設備的操作系統。該情況下，把時間欄的值加起來，通訊暫停了25秒。
TCP差錯控制和流控排查總結：
重傳報文
重 傳的發(fā)生是由于客戶端檢測到服務器沒有接收到它所發(fā)送的數據。因此，取決于你所分析的是通訊的哪一端，有可能是看不見重傳的。如果從服務器端抓取數據，并 且它確實沒有接收到客戶端所發(fā)送的和重傳報文，可能會一無所獲因為無法看見重傳報文。如果懷疑并不是服務器端導致的報文丟失，可以考慮在客戶端嘗試抓取報 文，以查看實際是否有重傳發(fā)生。
重復ACK
可以將重復ACK看作重傳的“所謂相反面”，因為它是在服務器檢測到客戶端發(fā)送報文丟失的時候產生的。大多數情況下，在通訊兩端抓取流量時都可以看 到重復ACK。需記住當接收報文亂序時會觸發(fā)重復ACK。例如，如果服務器之接收到發(fā)送的第一個和第三個報文，就會導致發(fā)送重復ACK引起客戶端對第二個 報文的快速重傳，因為你已經收到了第一個和第三個報文，因此不管導致第二個報文丟棄的原因是什么，都很有可能是暫時的，因此大多數情況下重復ACK都會成 功發(fā)送和接收。當然，這種情形并不一定永遠會發(fā)生，因此當你懷疑在服務器端丟失報文而又看不到任何重復ACK，考慮從通訊的客戶端抓取報文。
零窗口和探測報文
滑動窗口直接與服務器無法接收和處理報文有關，任何窗口大小的縮小以及零值都是服務器問題的直接結果。所以如果你在哪里看到這兩者之一發(fā)生，就應該在那里深入研究。通常應當在網絡通訊兩端一直主機窗口更新報文。
?
一站式學習Wireshark（六）：狙擊網絡高延時點
分享到：- 與《YII框架》不得不說的故事—擴展篇
- sass進階篇
- IOS基礎教程之界面初體驗
- Spring事務管理
在某些情況下，丟包可能并不是造成延時的原因。你可能會發(fā)現盡管兩臺主機之間通訊速度很慢，但這種慢速并沒有伴隨著TCP重傳或是重復ACK的征兆。在這種情況下，需要使用另一種方式來定位高延時點。
查找高延時點最有效的方法之一是檢查最初的握手信號以及跟隨其后的幾個報文。例如，一個簡單的客戶端與網絡服務器的連接，客戶端嘗試通過瀏覽器訪問 網絡服務器的站點。我們只關心這一通信序列的前六個報文，包括TCP握手過程，首次HTTP GET請求，對此GET請求的確認，以及從服務器發(fā)至客戶端的第一個數據報文。
更多信息
正常通訊:
在討論高延時狀況之前，找一個正常的通訊作為參照。在第二節(jié)已經介紹過TCP握手過程以及HTTP通訊，這里不再贅述。在下面這張圖里，我們關心的部分只有Time列：
這一通訊序列是非常快速的，整個過程耗時不到0.1秒。
接下來幾個抓包文件包含同樣的traffic模式，但是在報文時序上有所不同。
慢速通訊——線路延時：
讓我們看看下面這個報文。注意到所有報文都是相同的，除了報文2和5的時間延時較長：
逐一分析這六個報文，立刻就會看到第一次延時。客戶端（172.16.16.128）發(fā)送首次SYN報文以開始TCP握手，在服務器 （74.125.95.104）返回SYN/ACK之前，有0.87秒的延時。這是線路延時的第一個信號，這是由客戶端和服務器之間的設備引起的。
我們判斷這是線路延時的依據是所傳送的報文類型特征。當服務器接收到一個SYN報文，只需花費很少的處理過程就可發(fā)送回復，因為這一工作負載并不包 含任何傳輸層之上的處理。即使服務器工作負載非常繁重，它通常也會快速地以SYN/ACK來回復SYN報文。這就排除了服務器是高延時的潛在原因。
客戶端也被排除的原因在于，它除了接收SYN/ACK報文之外，沒有進行任何處理。
這一抓包的前兩個報文幫我們排除了客戶端和服務器，并指出了潛在原因。
繼續(xù)分析，我們發(fā)現結束三步握手信號的ACK報文快速出現，客戶端發(fā)送的HTTP GET請求也是如此。產生這兩個報文的所有處理在本地客戶端接收到SYN/ACK之后進行，因此在客戶端沒有繁重的負載需要處理的情況下，這兩個報文預計會很快傳送。
到了報文5，我們看到另一個延時高得離譜的報文。出現在最初的HTTP GET請求發(fā)送過后，從服務器返回的ACK報文花費了1.15秒才收到。接收到HTTP GET請求之后，服務器在開始發(fā)送數據之前首先發(fā)送了一個TCP ACK，同樣只需占用服務器很少的處理。這是另一個線路延時的信號。
不管何時你經歷著線路延時，你幾乎總是會看到：在最初的握手信號期間的SYN/ACK報文，以及整個通訊過程的ACK報文中，存在著高延時。即使這 一信息并沒有告訴你網絡上延時的確切原因，至少讓你明白客戶端和服務器都不是延時點所在，因此延時發(fā)生在兩者之間的設備。這時，你應當開始檢查受影響主機 之間的各種防火墻，路由器，以及代理，以定位罪魁禍首。
慢速通訊——客戶端延時：
下一個延時場景的抓包如下圖所示：
這一抓包開始時很正常，TCP握手非常迅速，沒有任何延時的跡象。正常狀態(tài)持續(xù)至第四個報文：握手信號結束之后接收到一個HTTP GET請求。這個報文距離前一個接收到的報文有1.34秒的延時。
要確認網絡的延時點，需要檢查第3和第4個報文之間發(fā)生了什么。報文3是客戶端發(fā)送到服務器的TCP握手信號中的最后一個ACK，報文4是從客戶端 發(fā)送至服務器的GET請求。這兩個報文的共同之處在于都是由客戶端發(fā)送，并且獨立于服務器。由于所有這些操作都集中在客戶端上，GET請求應當在發(fā)送了 ACK之后快速傳送。
不幸的是對于終端用戶，從ACK到GET的傳送并沒有快速發(fā)生。GET報文的創(chuàng)建與傳輸取決于應用層的處理，這一過程中的延時意味著客戶端無法及時的執(zhí)行這一功能。這表示客戶端最終為通訊中的高延時負責。
慢速通訊——服務器延時：
最后一個延時場景的抓包如下圖所示：
在這一抓包中，兩個主機之間的TCP握手過程完成得干脆利落，因此開始時并無問題。接下來幾個報文也很順利，首個GET請求及回復ACK報文也在快速交付。直到最后一個報文，我們看到了高延時的信號。
第六個報文是服務器響應客戶端GET請求的第一個HTTP數據報文，但是在服務器發(fā)送GET請求的TCP ACK 0.98秒之后才到達。報文5和6的傳送過程與我們在前一個場景所見ACK和GTE請求的傳送類似。但是，在這一情況下，服務器是我們關注的焦點。
報文5是服務器對從客戶端接收GET請求的回應。只要該報文被發(fā)送，服務器就應當立即發(fā)送數據。這一讀取，封裝，傳送的過程是由HTTP協議完成 的，由于這是應用層協議，需要服務器參與處理過程。這一報文的延遲接收表明服務器無法在合理的時間內處理數據，最終指向服務器是延時點。
延時定位思路：
通過六個報文，我們能夠定位服務器與客戶端之間的網絡高延時點。這些場景可能看起來有點復雜，但是下圖能使你的定位延時過程變得簡單快捷。這一原則幾乎能應用于任何基于TCP的通訊。
?
一站式學習Wireshark（七）：Statistics統計工具功能詳解與應用
分享到：- jQuery源碼解析（架構與依賴模塊）
- Android高級特效-3D畫廊
- 從D2到D2(大話游戲開發(fā)實戰(zhàn)技巧)
- 與《YII框架》不得不說的故事—高效篇
Wireshark 一個強大的功能在于它的統計工具。使用Wireshark的時候，我們有各種類型的工具可供選擇，從簡單的如顯示終端節(jié)點和會話到復雜的如Flow和IO 圖表。本文將介紹基本網絡統計工具。包括：捕捉文件摘要（Summary）,捕捉包的層次結構（Protocol Hirarchy）,?會話（Conversations）,?終端節(jié)點（Endpoints）, HTTP。
更多信息
Summary:
從statistics菜單，選擇Summary：
如下圖的截屏所示，你會看到：
File：
捕捉文件的一般信息，如文件名和路徑，長度，等等
Time：
第一個包和最后一個包的時間戳，以及抓包過程持續(xù)時間
Capture：
顯示文件捕捉于哪一個接口，以及評論窗口
在窗口的較低部分是Display窗口，展示抓包文件統計信息的摘要，包括：
捕捉報文的總數與百分比
顯示報文的數量（加上過濾條件之后）
標記報文的數量
何時使用：
這一菜單簡單收集所有抓包數據，在定義了過濾條件的時候，將呈現過濾后的數據。當想要知道每秒的平均報文數或是字節(jié)數時，可以使用此工具。
Protocol Hierarchy:
這一部分闡述如何確知網絡運行數據。從statistics菜單，選擇Protocol Hierarchy。
這個窗口現實的是捕捉文件包含的所有協議的樹狀分支。如下圖所示：
Protocol Hierarchy窗口有如下字段：
Protocol：
協議名稱
% Packets：
含有該協議的包數目在捕捉文件所有包所占的比例
Packets：
含有該協議的包的數目
Bytes：
含有該協議的字節(jié)數
Mbit/s：
抓包時間內的協議帶寬
End Packets：
該協議中的包的數目（作為文件中的最高協議層）
End Bytes：
該協議中的字節(jié)數（作為文件中的最高協議層）
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中，查找以下問題：
- 查看收發(fā)大量數據流的IP地址。如果是你知道的服務器（你記得服務器的地址或地址范圍），那問題就解決了；但也有可能只是某臺設備正在掃描網絡，或僅是一臺產生過多數據的PC。
- 查看掃描模式（scan pattern）。這可能是一次正常的掃描，如SNMP軟件發(fā)送ping報文以查找網絡，但通常掃描都不是好事情。
- 一次典型的掃描模式如下圖所示：
本例中的掃描模式，一個IP地址，192.168.110.58，發(fā)送ICMP報文至192.170.3.44, 192.170.3.45, 192.170.3.46, 192.170.3.47,等等（上圖僅顯示掃描的很小一部分）。這種情況下我們有一個蠕蟲病毒感染了網絡上的所有PC，在它感染PC的時候，它就開始產 生ICMP請求并將它們發(fā)送至網絡。這些窄帶連接（例如：WAN連接）可以很容易地被封鎖。
TCP/UDP會話統計
- 查看帶有太多TCP連接的設備。每一個PC合理的連接數是10到20個，上百個則是不正常的。
- 嘗試查找無法辨識的端口號。它可能是正常的，但也可能是有問題的。下圖顯示了一次典型的TCP掃描：
Endpoints:
1.?從statistics菜單，選擇Endpoints：
2.?出現以下窗口：
3.?此窗口中，能夠看到第2,3,4層的endpoints，也就是以太網，IP, TCP或UDP。
使用要點：
這一工具列出了Wireshark發(fā)現的所有endpoints上的統計信息。可以是以下任意一種情況：
- 少量以太網endpoints（MAC地址）與大量IP終端節(jié)點（IP地址）：可能的情況例如，一個路由器從很多遠端設備收發(fā)報文，我們會看見路由器的MAC地址及很多IP地址經由此處。
- 少量IP終端節(jié)點與大量TCP終端節(jié)點：可能的情況是每一臺主機有很多個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按鈕，會看到以下窗口：
如果要查看某一特定節(jié)點的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發(fā)送請求。本例中，我們打開的其中一個網頁是www.cnn.com，并將我們導向edition.cnn.com。我們發(fā)送了若干個請求：到root URL，到breaking_news URL，以及主頁上兩個其他位置。
?
一站式學習Wireshark（八）：應用Wireshark過濾條件抓取特定數據流
分享到：- Android-多平臺分享
- C++遠征之模板篇
- Sass入門篇
- PHP實現微信公眾平臺開發(fā)—提升篇
應用抓包過濾，選擇Capture | Options，擴展窗口查看到Capture Filter欄。雙擊選定的接口，如下圖所示，彈出Edit Interface Settints窗口。
下圖顯示了Edit Interface Settings窗口，這里可以設置抓包過濾條件。如果你確知抓包過 濾條件的語法，直接在Capture Filter區(qū)域輸入。在輸入錯誤時，Wireshark通過紅色背景區(qū)域表明無法處理過濾條件。最有可能的情況是，過濾條件中含有輸入錯誤，或是使用了 display filter的語法。
點擊Capture Filter按鈕查看并選擇已保存的抓包過濾條件。
更多信息
抓取指定IP地址的數據流:
如果你的抓包環(huán)境下有很多主機正在通訊，可以考慮使用所觀察主機的IP地址來進行過濾。以下為IP地址抓包過濾示例：
- host 10.3.1.1：抓取發(fā)到/來自10.3.1.1的數據流
- host 2406:da00:ff00::6b16:f02d：抓取發(fā)到/來自IPv6地址2406:da00:ff00::6b16:f02d的數據流
- not host 10.3.1.1：抓取除了發(fā)到/來自10.3.1.1以外的所有數據流
- src host 10.3.1.1：抓取來自10.3.1.1的數據流
- dst host 10.3.1.1：抓取發(fā)到10.3.1.1的數據流
- host 10.3.1.1 or 10.3.1.2：抓取發(fā)到/來自10.3.1.1，以及與之通訊的所有數據流，與10.3.1.2，以及與之通訊的所有數據流
- host?www.espn.com：抓取發(fā)到/來自所有解析為www.espn.com的IP地址的數據流
抓取指定IP地址范圍的數據流:
當你需要抓取來自/發(fā)到一組地址的數據流，可以采用CIDR(無類別域間路由，Classless Interdomain Routing)格式或使用mask參數。
- net 10.3.0.0/16：抓取網絡10.3.0.0上發(fā)到/來自所有主機的數據流(16表示長度)
- net 10.3.0.0 mask 255.255.0.0：與之前的過濾結果相同
- ip6 net 2406:da00:ff00::/64：抓取網絡2406:da00:ff00:0000(IPv6)上發(fā)到/來自所有主機的數據流
- not dst net 10.3.0.0/16：抓取除了發(fā)到以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。
方括號中第一個數字表示從協議頭開始的偏移量，第二個數字表示需要觀察多少位。
抓取發(fā)到廣播或多播地址的數據流:
只需偵聽廣播或多播數據流，就可以掌握網絡上主機的許多信息。
- ip broadcast：抓取廣播報文
- ip multicast：抓取多播報文
- dst host ff02::1：抓取到IPv6多播地址所有主機的數據流
- dst host ff02::2：抓取到IPv6多播地址所有路由器的數據流
小貼士：
Wireshark包含了一些默認的抓包過濾條件。點擊主工具欄的Edit Capture Filters，跳轉到已保存抓包過濾列表。你會發(fā)現一些常見抓包過濾的示例。
抓取基于MAC地址的數據流:
當你需要抓取發(fā)到/來自某一主機的IPv4或IPv6數據流，可創(chuàng)建基于主機MAC地址的抓包過濾條件。
應用MAC地址時，需確保與目標主機處于同一網段。
- ether host 00:08:15:00:08:15：抓取發(fā)到/來自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：抓取發(fā)到02:0A:42:23:41:AC的數據流
- not ether host?00:08:15:00:08:15：抓取除了發(fā)到/來自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：抓取發(fā)到/來自端口53的UDP/TCP數據流（典型是DNS數據流）
- not?port 53：抓取除了發(fā)到/來自端口53以外的UDP/TCP數據流
- port 80：抓取發(fā)到/來自端口80的UDP/TCP數據流（典型是HTTP數據流）
- udp port 67：抓取發(fā)到/來自端口67的UDP數據流（典型是DHCP據流）
- tcp port 21：抓取發(fā)到/來自端口21的TCP數據流（典型是FTP命令通道）
- portrange 1-80：抓取發(fā)到/來自端口1-80的所有UDP/TCP數據流
- tcp portrange 1-80：抓取發(fā)到/來自端口1-80的所有TCP數據流
抓取結合端口的數據流:
當你需要抓取多個不連續(xù)端口號的數據流，將它們通過邏輯符號連接起來，如下圖所示：
- port 20 or port 21：抓取發(fā)到/來自端口20或21的UDP/TCP數據流（典型是FTP數據和命令端口）
- host 10.3.1.1 and port 80：抓取發(fā)到/來自10.3.1.1端口80的數據流
- host 10.3.1.1 and not port 80：抓取發(fā)到/來自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。
總結
以上是生活随笔為你收集整理的一站式学习Wireshark（转载）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 用c语言打印自定义的乘法口诀表。例如：
- 下一篇： Databricks：2015 Spar