wireshark抓包(wireshark抓包過濾IP地址)

wireshark怎么抓包

wireshark抓包方法如下：

操作設備：聯想筆記本電腦。

設備系統：Win10系統。

操作軟件：wireshark 2.6.5。

1、在電腦中，打開wireshark軟件。

2、點擊抓取網絡接口卡選擇按鈕，選擇需要抓取的網卡接口。

3、如果不確定是那個網絡接口，則可以看packes項數據變化最多接口，選中它然后點擊＂start"開始抓包。

4、如果需要進行特別的配置，則需要先進行抓包錢的配置操作，點擊途中的配置操作按鈕，進入到抓包配置操作界面，進行相應配置；配置完成后點擊“start”開始抓包。

5、開始抓包后，可以看到各通過該網絡接口的數據報文被抓取到，如果想要只看自己關心的數據包，則可以在＂Filter"欄中輸入過濾條件即可；過濾條件有多種，具體可以通過百度搜索＂wireshark包過濾條件＂進行查找。

6、如果沒有抓取到想要的數據包，則點擊重新抓取按鈕即可；或者抓取到個人需要的數據包之后，可以點擊紅色的停止按鈕即可。

wireshark抓包

一、  wireshark是捕獲機器上的某一塊網卡的網絡包 ，當你的機器上有多塊網卡的時候，你需要選擇一個網卡。

例如，我測試本地連接，直接選擇“本地連接”，進入如下界面

二、 WireShark 主要分為這幾個界面

1. Display Filter(顯示過濾器)，  用于過濾

2. Packet List Pane(封包列表)， 顯示捕獲到的封包， 有源地址和目標地址，端口號。 顏色不同，代表不同的協議，你也可以修改這些顯示顏色的規則，  View ->Coloring Rules.

3. Packet Details Pane(封包詳細信息), 顯示封包中的字段

        Frame:   物理層的數據幀概況

        Ethernet II: 數據鏈路層以太網幀頭部信息

        Internet Protocol Version 4: 互聯網層IP包頭部信息

        Transmission Control Protocol:  傳輸層T的數據段頭部信息，此處是TCP

        Hypertext Transfer Protocol:  應用層的信息，此處是HTTP協議

4. Disctor Pane(16進制數據)

5. Miscellanous(地址欄，雜項)

wireshark頂部顯示過濾器

使用過濾是非常重要的， 初學者使用wireshark時，將會得到大量的冗余信息，在幾千甚至幾萬條記錄中，以至于很難找到自己需要的部分。搞得暈頭轉向。

過濾器會幫助我們在大量的數據中迅速找到我們需要的信息。

過濾器有兩種，

一種是顯示過濾器，就是主界面上那個，用來在捕獲的記錄中找到所需要的記錄

一種是捕獲過濾器，用來過濾捕獲的封包，以免捕獲太多的記錄。 在Capture -> Capture Filters 中設置

保存過濾

1）設置顯示過濾器，按如下步驟進行編輯

過濾表達式的規則

表達式規則

1. 協議過濾

比如TCP，只顯示TCP協議。

2. IP 過濾

比如 ip.src ==192.168.1.102 顯示源地址為192.168.1.102，

ip.dst==192.168.1.102, 目標地址為192.168.1.102

3. 端口過濾

tcp.port ==80,  端口為80的

tcp.srcport == 80,  只顯示TCP協議的愿端口為80的。

4. Http模式過濾

http.request.method=="GET",   只顯示HTTP GET方法的。

5. 邏輯運算符為 AND/ OR

常用的過濾表達式

三、 wireshark與對應的OSI七層模型

TCP包的具體內容

從下圖可以看到wireshark捕獲到的TCP包中的每個字段。

四、實例分析TCP三次握手過程

看到這， 基本上對wireshak有了初步了解， 現在我們看一個TCP三次握手的實例

三次握手過程為

這圖我都看過很多遍了， 這次我們用wireshark實際分析下三次握手的過程。

打開wireshark, 打開瀏覽器輸入 http://www.cr173.com

在wireshark中輸入http過濾， 然后選中GET /tankxiao HTTP/1.1的那條記錄，右鍵然后點擊"Follow TCP Stream",

這樣做的目的是為了得到與瀏覽器打開網站相關的數據包，將得到如下圖

圖中可以看到wireshark截獲到了三次握手的三個數據包。第四個包才是HTTP的， 這說明HTTP的確是使用TCP建立連接的。

第一次握手數據包

客戶端發送一個TCP，標志位為SYN，序列號為0， 代表客戶端請求建立連接。 如下圖

第二次握手的數據包

服務器發回確認包, 標志位為 SYN,ACK. 將確認序號(Acknowledgement Number)設置為客戶的I S N加1以.即0+1=1, 如下圖

第三次握手的數據包

客戶端再次發送確認包(ACK) SYN標志位為0,ACK標志位為1.并且把服務器發來ACK的序號字段+1,放在確定字段中發送給對方.并且在數據段放寫ISN的+1, 如下圖:

就這樣通過了TCP三次握手，建立了連接

抓包工具——wireshark的使用

wireshark工具的標志是鯊魚標志的圖標，點開軟件，選擇某一網關之后可以自動抓包。

Wireshark 窗口介紹

如圖所示，在filter中輸入過濾條件可以過濾出符合條件的日志過程，這樣特別適合看網絡的幾次握手過程，對于從整體上分析網絡交互過程比較實用，可以方便的看出是在哪次網絡交互的過程中出了問題。

Wireshark抓包參數詳解

Frame： 物理層 的數據幀概況。

Ethernet II： 數據鏈路層 以太網幀頭部信息。

以太網

Internet Protocol Version 4： 互聯網層 IP包頭部信息。

互聯網 協議 版本

Transmission Control Protocol： 傳輸層 的數據段頭部信息，此處是TCP協議。

傳輸 控制 協議

Hypertext Transfer Protocol： 應用層 的信息，此處是HTTP協議。

超文本 傳送

1）物理層的數據幀概況

Frame 5: 268 bytes on wire (2144 bits), 268 bytes captured (2144 bits) on interface 0 #5號幀，線路268字節，實際捕獲268字節

Interface id: 0         #接口id

Encapsulation type: Ethernet (1)     #封裝類型

Arrival Time: Jun 11, 2015 05:12:18.469086000 中國標準時間 #捕獲日期和時間

[Time shift for this packet: 0.000000000 conds]

Epoch Time: 1402449138.469086000 conds

[Time delta from previous captured frame: 0.025257000 conds] #此包與前一包的時間間隔

[Time since reference or first frame: 0.537138000 conds] #此包與第一幀的時間間隔

Frame Number: 5 #幀序號

Frame Length: 268 bytes (2144 bits) #幀長度

Capture Length: 268 bytes (2144 bits) #捕獲長度

[Frame is marked: Fal] #此幀是否做了標記：否

[Frame is ignored: Fal] #此幀是否被忽略：否

[Protocols in frame: eth:ip:tcp:http] #幀內封裝的協議層次結構

[Number of per-protocol-data: 2] #

[Hypertext Transfer Protocol, key 0]

[Transmission Control Protocol, key 0]

[Coloring Rule Name: HTTP] #著色標記的協議名稱

[Coloring Rule String: http || tcp.port == 80] #著色規則顯示的字符串

（2）數據鏈路層以太網幀頭部信息

Ethernet II, Src: Giga-Byt_c8:4c:89 (1c:6f:65:c8:4c:89), Dst: Tp-LinkT_f9:3c:c0 (6c:e8:73:f9:3c:c0)

Destination: Tp-LinkT_f9:3c:c0 (6c:e8:73:f9:3c:c0) #目標MAC地址

Source: Giga-Byt_c8:4c:89 (1c:6f:65:c8:4c:89) #源MAC地址

Type: IP (0x0800)

（3）互聯網層IP包頭部信息

Internet Protocol Version 4, Src: 192.168.0.104 (192.168.0.104), Dst: 61.182.140.146 (61.182.140.146)

Version: 4 #互聯網協議IPv4

Header length: 20 bytes #IP包頭部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #差分服務字段

Total Length: 254 #IP包的總長度

Identification: 0x5bb5 (23477) #標志字段

Flags: 0x02 (Don't Fragment) #標記字段

Fragment offt: 0 #分的偏移量

Time to live: 64 #生存期TTL

Protocol: TCP (6) #此包內封裝的上層協議為TCP

Header checksum: 0x52ec [validation disabled] #頭部數據的校驗和

Source: 192.168.0.104 (192.168.0.104) #源IP地址

Destination: 61.182.140.146 (61.182.140.146) #目標IP地址

（4）傳輸層TCP數據段頭部信息

Transmission Control Protocol, Src Port: 51833 (51833), Dst Port: http (80), Seq: 1, Ack: 1, Len: 214

Source port: 51833 (51833) #源端口號

Destination port: http (80) #目標端口號

Sequence number: 1 (relative quence number) #序列號（相對序列號）

[Next quence number: 215 (relative quence number)] #下一個序列號

Acknowledgment number: 1 (relative ack number) #確認序列號

Header length: 20 bytes #頭部長度

Flags: 0x018 (PSH, ACK) #TCP標記字段

Window size value: 64800 #流量控制的窗口大小

Checksum: 0x677e [validation disabled] #TCP數據段的校驗和

如何使用Wireshark抓包

Wireshark是一個抓取網絡數據包的工具，這對分析網絡問題是很重要的，下文將會簡單的介紹下如何使用Wireshark來抓包。
1、在如下鏈接下載“Wireshark”并在電腦上安裝。
2、如果之前沒有安裝過“Winpcap”請在下面把安裝“Winpcap”的勾選上。
3、打開安裝好的Wireshark程序，會看到如下圖所示界面：
主界面，打開“Capture”－＞“Options”
在最上面的Interface中選擇電腦真實的網卡（默認下可能會選中回環網卡），選中網卡后，下面會顯示網卡的IP地址，如圖中是172.31.30.41，如果IP正確，說明網卡已經正確選擇。
Capture
Filter這一欄是抓包過濾，一般情況下可以不理會，留為空。
Display
options就按照我們勾選的來做就行。好，點擊Start。
選擇好保存路徑和文件名（請不要中文）后，點擊保存。

Wireshark 抓包理解 HTTPS 請求流程

目錄

我的操作是這樣的，讓手機和電腦在同一個局域網內（比如連接同一個 wifi），接著在手機的wifi上設置代理，電腦使用 Charles 做代理，IP 為電腦在局域網 IP，我這邊的環境，手機 IP 為 172.17.32.117，電腦 IP 為 172.17.32.19。再設置代理端口為 8888。設置代理后，接下來手機的請求都會通過電腦的網卡代理請求發送出去。

其實可以不用這么繞。我之所以多設了一個代理，是因為自己電腦創建的 wifi 熱點，手機接收不到。為了讓手機的包能經過電腦網絡嗅探到才這么處理的。

最便捷的方式，就是電腦放個 wifi 熱點給手機連接完事。

創建后代理連接后，然后使用 Wireshark 嗅探網卡，比如我這里使用的是 etho0 網卡去訪問網絡的。這時候玩玩手機，打開幾個請求，Wireshark 上面就會出現捕捉的大量的包，各種各樣的協議都有，有 ARP 尋人啟事（尋找 IP 對應的物理地址），有 TCP 連接包，有 HTTP 請求包。

這里我設置了一下過濾規則，把對網易的一個 https://nex.163.com 的一個的請求過濾出來如下：

整個完整的 HTTPS 請求的過程如下：

接下來把手機稱為 A（172.17.32.211），電腦稱為 B（172.17.32.19），對完整的過程進行簡要分析。

作為整個過程的第一個 TCP 包，這里對它做一個詳細的剖析，理解一下 TCP 報文的格式和內容。TCP 是傳輸層協議，負責可靠的數據通信，它在整個體系結構的位置如下：

作為傳輸層協議，主要為上層協議提供三個功能：

TCP 協議為 HTTP 和 SSL 協議提供了基礎的通信功能。所以 SSL 協議是基于 TCP 的。

三次握手的內容有：

對每個包進行詳細的分析：

A 發出一個帶 SYN 同步位的包，通知服務端要建立連接 。

第一次握手，發出的 TCP 包的數據和 Wireshark 解析的結果如下：

灰色部分就是 TCP 報文的數據內容，第一個兩個字節 0x8c85 = 35973 表示源端口。

TCP 報文的格式如下，對應的如上圖的灰色部分。非灰色部分分別為 IP 首部和數據幀首部。

參考謝希仁版本的 《計算機網絡》一書，對照著整個報文格式表，把整個 TCP 報文的二進制信息和相關意義做些說明：

到這里的話，TCP 數據報首部固定部分結束，固定部分一共有 20 字節。也就是 TCP 首部，至少要有 20 字節。

固定首部后，就是可長度可以變化的選項了：

整個所以 TCP 數據包的大小可以這樣表示：

我們 Wireshark 后面的一長串的信息就指出了該 TCP 報文的一些主要信息：

從上面的分析可以看出，這個 SYN 包并沒有攜帶數據，但是按協議這里要消耗一個序號。

在發出 SYN 包后，A 端進入 SYN-SENT 狀態。

B 收到 SYN 包，發出 SYN + ACK 確認包 。

這個包，既是確認收到了第一次握手的包，也是一個由 B 端發出的同步包，表示自己準備好了，可以開始傳數據了。

TCP 報文包相對于第一次握手的包可以窺見一些變化：

可以看到，這個包的應答時間戳剛好是第一次握手的發送時間戳。從這里也可以理解到，這個包就是在響應第一次握手的包

所以，接收方 A 可以利用這個值來計算這一次 RTT ，收到第二次握手的包后，計算當前時間戳減去該包的應答時間戳就是一個 RTT 的延時了。

這雖然是 ACK 包，但也是 SYN 包，所以也要消耗一個序號。

在發出這個包后，B 端進入 SYN-REVD 狀態。

A 收到后，再發出一個 ACK 確認包

發出的包如下：

這里我們產生一個疑問，這里發送端 A 發連接請求信息、接收端 B 發確認信息，又互相同步了序號，是不是已經可以傳輸數據了？但實際上 A 還要再發一個 ACK 確認報文，如圖所示，確認收到了 B 第二次握手發出的包，這個時候，在這個 ACK 包后 A 和 B 才正式進入 ESTABLISHED 狀態。這就是第三次握手。

這是為什么呢？

假設我們用兩次握手，然后在第一次握手期間，A 發了第一次握手包后出現了這樣的場景：一直沒有得到響應而進行超時重傳，又發了一次包，然后我們稱上一次包為失效包。

然后我們可以看到：

所以，只有接收端 B 在發送端 A 發出了第三次握手包后，才認為連接已經建立，開始等待發送端 A 發送的數據，才不會因為失效的連接請求報文導致接收端異常。

TCP 三次握手的時序圖如下：

三次握手，有幾個重要的任務，一個是 同步序號 ，接收端和發送端都發出同步包來通知對方初始序號，這樣子后面接收的包就可以根據序號來保證可靠傳輸；另一個是讓發送端和接收都 做好準備 。然后就開始傳數據了。

整個過程都發生在 HTTP 報文發出之前。HTTP 協議就是依靠著 TCP 協議來做傳輸的管理。TCP 可以認為是它的管家，管理著傳輸的大大小小的事務，比如要不要保證包順序一致？什么時候發包？要不要收包？TCP 是很嚴格的。

三次握手在 Java API 層面，對應的就是 Socket 的連接的創建（最終調用的是 native 層的 socket 創建）：

這里的 connectTimeout 對應的是三次握手的總時長，如果超時了就會被認為連接失敗。

比如一個場景，客戶端發出一個 SYN 報文后，遲遲沒有收到服務端的 SYN + ACK。這時候客戶端觸發重傳機制，每次重傳的間隔時間加倍，同樣沒有收到包。然后如果這段時間超出了連接超時時間的設置，那么建立連接超時就發生了。

所以，如果三次握手要花的時間，總是大于這里的 connectTimeout 時間，這個 Socket 就無法建立連接。

我們這一次請求的三次握手時間在 180ms 左右。

像在 OkHttp 中，如果是三次握手階段的連接超時，是會有重試機制的。也就是重新建聯，重新發出 SYN 報文發起 TCP 連接。重新建聯的時候會更換連接的路由，如果已經沒有可選擇路由的話，那么這個就真的失敗了。

在 OkHttp 3.9.0 的默認配置中，連接超時的時間為 10000ms = 10s。在 OkHttpClient.Builder 中。

實際應用的時候，根據業務場景來調整。

這次請求，為了讓 Wireshark 抓到手機的包，我使用了電腦作為代理。

其實就是客戶端 A 使用 HTTP 協議和代理服務器 B 建立連接。和普通的 HTTP 請求一樣，需要攜帶 IP + 端口號，如果有身份驗證的時候還會帶上授權信息，代理服務器 B 會使用授權信息進行驗證。然后代理服務器會去連接遠程主機，連接成功后返回 200。

Wireshark 抓到的包有這樣兩條信息，就是在創建代理：

請求報文：

響應報文：

HTTP CONNECT 是在 HTTP1.1 新增的命令，用于支撐 https 加密。

因為我采用代理的方式抓包才有這一個步驟。如果是直接抓 PC 機上瀏覽器發出的 HTTPS 包，不會有這個過程。

然后我們思考一下，為什么代理服務器需要這些信息，要連接的主機名和端口號？

這是因為后面進行 SSL 加密 HTTP協議，因為代理服務器拿不到加密密鑰，是無法獲取到 HTTP 首部的，進而無法這個請求是要發到哪個主機的。所以，這里先使用 CONNECT 方法，把主機名和對應的端口號通知代理服務器。

這個也被稱為 HTTPS SSL 隧道協議。建立這個 SSL 隧道后，這個特殊代理就會對數據進行盲轉發。

SSL 整個協議實際上分兩層，SSL 記錄協議和其他子協議（SSL握手協議，SSL改變密碼協議，SSL警告協議）：

這兩層協議的關系，其實就是數據封裝的關系，SSL 握手封裝協議封裝其他上層協議。

封裝握手協議：

封裝應用數據協議，比如 HTTP：

封裝交換密碼協議：

封裝警報協議：

所以 SSL 記錄協議其實就是一個其他協議的載體，只是提供了一個封裝的功能。它的格式為：

MAC 就是消息驗證碼，用來驗證數據的完整性，保證中途沒有篡改。這個消息驗證碼比數字簽名弱一些，使用的是對稱密鑰加密摘要。數字簽名使用的是非對稱密鑰加密，有區分公鑰私鑰。

記錄協議的主要目的有這幾個，為其他 SSL 子協議提供了以下服務：

TCP 三次握手結束并且和代理服務器成功連接后，建聯成功，客戶端 A 就開始發起 SSL 連接，首先會進入 SSL 握手階段。

SSL 握手階段的主要目的有這么幾個：

SSL 握手的流程并不是一成不變的，根據實際的應用場景來。主要有三種：

SSL 握手的完整的交互過程如下，這里是驗證服務端又驗證了客戶端的情況：

我們的請求只驗證服務端，所以 7,8,9 是不存在的。

現在具體分析每一個階段的內容。

Client Hello

作為 SSL 握手的第一個握手包，我們詳細分析和理解一下包的內容。

下面是 Wireshark 解析好的這個 SSL 協議的數據包：

這個包如何解讀，按照之前對 SSL 協議的分析，其實分成兩個部分：

因為是握手過程，密鑰還沒協商，這里還是使用明文傳輸，記錄協議的數據載體就是明文的 SSL 握手協議。

SSL 握手協議的格式為：

我們可以從握手協議的數據包中得到這些信息：

密碼套件隨著密碼學的發展而發展，而且根據現實應用中，可能會有某些密碼被破解，從而導致密碼套件可能會導致安全問題，所以一般都會使用當前最新最安全的密碼套件。

在 Android 系統中，一般情況下，使用 SSLSocket進行連接的時候，會帶上系統默認的支持的密碼套件。但是這個有個缺點，比如某些密碼套件的加密算法被破解或者出現安全漏洞，而且要跟著系統升級反應緩慢。OkHttp 在進行 SSL 握手的時候，會使用 ConnectionSpec 類中帶上提供了一系列最新的密碼套件。可以從注釋上看，這些密碼套件在 Chrome 51 和 Android 7.0 以上得到了完全支持。

然后，再把這些密碼套件和 Android 系統支持的密碼套件取交集，提交給服務端。這樣，萬一哪個密碼套件有問題，OkHttp 官方會下降支持。網絡庫 OkHttp 庫會隨著版本的迭代，不斷地去提供比較新的密碼套件，并且放棄那些不安全的密碼套件。接入應用即時更新 OkHttp，就不用等待緩慢的系統更新了。

如果提供的所有密碼套件服務端都不支持，OkHttp 有回退機制，退而求其次，選比較舊的套件。

Server Hello

服務端收到了客戶端的 Hello，通過客戶端的配置信息，結合服務端的自身情況，給出了最終的配置信息。

Wireshark 解析后的內容如下：

具體內容如下：

Certificate

上面的 Server Hello 已經制定了接下來的非對稱加密算法

服務端下發證書，客戶端驗證服務端的身份，并且取出證書攜帶的公鑰，這個公鑰是交換加密算法的公鑰。也就是在 Server Hello 階段指定的 ECDHE （EC Diffie-Hellman）算法，也是通常說的 DH 加密。

這個 Certificate 消息下發了從攜帶自己公鑰的數字證書和 CA 證書的證書鏈，在 Certificates 字段中：

CA 是 PKI 體系的重要組成部分，稱為認證機構。

那什么是 CA 證書？就是用來 CA 中心發布的，認證該服務單證書的合法性，可以確保該證書來源可靠而不是被中間人替換了。但是 CA 證書也可能被中間人攔截造假？那就再用一個證書來認證它。看起來好像沒完沒了。實際上到最后有一個根 CA 證書，這個證書存儲再瀏覽器或者操作系統中，是系統直接信任的。

服務端證書需要 CA 證書做認證。使用的還是數字簽名方式，從數據中摘要一段信息，用 CA 證書的加密。然后驗證的時候時候，用 CA 證書的公鑰解密，用同樣的摘要算法摘要數據部分和解密好的信息進行比較。

客戶端在驗證服務端證書的有效性有這樣的一個過程。首先會找到該證書的認證證書，也就是中級 CA 證書。然后找中級 CA 證書的認證證書，可以是另一個中級 CA 證書，也可能是根 CA 證書。這樣直到根 CA 證書。

接著從根 CA 證書開始往下去驗證數字簽名。比如有這樣的證書鏈：根 CA 證書-> 中級 CA 證書 -> 服務端證書。用 CA 證書的公鑰去驗證中級證書的數字簽名，再用中級證書的公鑰去驗證服務器證書的數字簽名。任何一個環節驗證失敗，就可以認為證書不合法。

這就是整個證書鏈的認證過程：

查看抓到的包的數據，發現只有兩個證書。為服務端證書和中級 CA 證書。根 CA 證書呢？順藤摸瓜找到它。

首先看服務端證書。它內容如下：

從這個證書中我們可以窺見這些信息：

首先是 signedCertificate 字段的內容，即數字證書的數據：

然后是證書頒發機構的簽名信息：

從上面的 issuer 可以了解到，認證該服務器證書的 CA 證書為 GeoTrust SSL CA - G3 ，我們從 Certificates 找到對應的中級證書的內容如下（中級證書可以有好幾級，我們這兒只有一級）：

可以得到中級證書名為 GeoTrust SSL CA - G3 ，證書組織為 GeoTrust Inc. 。

認證該 CA 證書的證書呢？還是看 issue 字段，認證證書名為 GeoTrust Global CA ，組織同樣是 GeoTrust Inc. 。

其實這個就是根 CA 證書。在這個請求中沒有找到，但在瀏覽器或者操作系統可以找到。一般的瀏覽器和系統都會內置該 CA 證書。所以根證書是受瀏覽器或者操作系統信任的，無需其他證書做擔保。

如果想要自己的系統再信任某些非通用的權威機構的根 CA 證書，那么就去安裝它。

比如我的 Windows 系統就安裝了 GeoTrust Global CA 證書：

像我們平時使用 Charles 抓 HTTPS 就是這個原理，把 Charles 的 CA 證書安裝在手機中，成為受信任的根 CA 證書。

基本原理就是，Charles 代理作為 SSL 隧道，并沒有透明傳輸，而是作為一個中間人，攔截了 SSL 握手信息，修改里面的 CA 證書。仿冒手機端和真實服務端建立連接獲取主密鑰，然后又仿冒服務端和手機客戶端建立 SSL 連接，修改服務端證書的 CA 和數字簽名，這樣 Charles 就可以解析到加密的 HTTP 內容了。

修改后的服務端證書如下，可以看到 issuer 被替換成了 Charles 的證書。