利用 Wireshark 目睹 TCP 請求過程

一、WireShark 簡介

WireShark 是一款開源的抓包工具，功能非常強大。與 Fiddler 和 Charlse 相比，它能更加直觀地去展示 HTTP 發送請求的時候內部具體做了些什麼事情，在客戶端開發尤其是服務端開發過程中佔據着不可小覷的地位。

官網下載地址：https://www.wireshark.org/#download

二、簡單使用

下面以 Mac 版 Wireshark 爲例介紹下如何去用它抓取網絡請求的。

由於 Mac 電腦上存在多個網卡，如果要抓包的話就需要在指定的網卡上去監控數據流量。所以，此次我們以 Wi-Fi 網卡口爲例去模擬網絡請求監控。

從上圖可以看出 Wi-Fi 網卡口的編號爲 en0，我們可以在終端使用 ifconfig 命令來查詢本機的網卡信息。

在 inet 後面那個 IP 就是本地的 IP 地址了，先拷貝出來後續要用到。

上面是 Wireshark 在抓包界面上具體的功能區域介紹，以便於我們在數據流過來的時候能夠知道怎麼去查看。

三、接口篩選

在上面的圖片中有一個輸入框可以填寫需要篩選具體的那個 IP 上來的請求數據，過濾內容的填寫需要遵循 Wireshark 的過濾語法。一般有兩種過濾方式：

下面採用顯示過濾方式來過濾 name.tgs-dev.tap4fun.com 這個域名下的網絡請求。

首先需要進行域名解析成 IP 地址，可以在終端上使用 nsloopup 命令來查詢：

nslookup name.tgs-dev.tap4fun.com

從上圖來看，解析的 IP 地址爲 172.20.90.129，接下來就要在 Wireshark 抓包界面裏輸入過濾語句：

ip.addr == 172.20.90.129

此時 Wireshark 處理監聽狀態等待 172.20.90.129 這個服務器上下行的數據，然後打開 postman 發送一條 Post 請求，此過程可以用下面的動圖來展示。

四、TCP 的 3 次握手

通過上述的步驟可以完整的記錄一個請求發送後，客戶端和服務端之間的交互過程。

首先就是和服務器建立連接，建立連接的過程可以抽象爲 TCP 的 3 次握手，具體過程下面就拿某一個接口下的報文列表來舉例說明：

第一次握手：

Source：172.20.171.18（這個是我自己本機的 IP），Destination：172.20.90.129（這個目標服務器的 IP），表明這個 TCP 協議是由客戶端向服務端發起的。此時因爲客戶端剛開始發起連接請求，所以 Seq=0（表示之前沒有發送過數據包），並且將標識位設置爲 [SYN]；

第二次握手：

Source：172.20.90.129，Destination：172.20.171.18，表示這個 TCP 協議是由服務端向客戶端發起的。此時因爲客戶端在第一次握手的時候已經發過來了請求，所以這個時候服務端需要給出一個迴應表示同意建立連接，故而 Ack=1 標誌位設置爲 [SYN, ACK]。同時，因爲此時服務端之前也沒有發送過數據所以 Seq 也等於 0；

第三次握手：

Source：172.20.171.18，Destination：172.20.90.129，表明這個 TCP 協議是由客戶端向服務端發起的。此時客戶端再次發起一個請求表示已經收到記錄，標誌位位 [ACK]，Seq 在上次服務端發起的基礎上 +1， Ack=1 表示已經接收到了上次服務端回過來的數據包。

整個 TCP 建立連接的 3 次握手過程大概就是上面所說的樣子。

五、TLS 協商過程

TLS 介紹：

TLS 全稱 Transport Layer Security，傳輸層安全的縮寫，是網絡傳輸協議中的一種（加密的）。

通過下面的報文列表中我們可以看到一個 TLS 建立起來需要經歷如下幾個步驟：

Client Hello：

這個過程是由客戶端發起的，裏面包含了 TLS 協議的版本號，一個隨機數（用於生成會話密鑰），以及客戶端這邊所支持的加密算法。

Server Hello：

這個過程是由服務端發起的，將服務端使用的 TLS 協議版本、生成的一組隨機數以及確認要使用的加密算法一起發送給客戶端。

Certificate：

這個時候服務端要把證書發給客戶端，用於驗證服務端的身份。並且在 Server Key Exchange 中，規定了服務端和瀏覽器是通過 Diffie-Hellman 算法來生成 pubKey 的，這個 pubKey 後續和客戶端交換要用到。

Client Key Exchange：

當客戶端這邊收到上一步服務端發來的 Certificate 後，並且運行服務端發來的 Diffie-Hellman 算法生成了一個公鑰 pubKey。

Change Cipher Spec Message：

這一步是客戶端將上面生成的 pubKey 和服務端進行交換。

Encripted Handshake Message：

這一步是將交換過來的 pubKey 生成一個 sessionKey，這個 sessionKey 是保證通信安全的。

Change Cipher Spec，Encrypted Handshake Message：

其實完成上述的步驟後，TLS 已經建立起來了的。這一步我覺得應該是每隔一段時間就需要變更一次加密方式，以保證安全傳輸。（具體是不是這個原因我還不太確定）

最後前後端建立了安全連接後就可以發送數據了，也就是後續的 Application Data 數據包了。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/WYNbDD-1zrsyejV_uZ336A

猜你喜歡