上一章：wireshark分析tcp協議（一）三次握手【理論 + 實操】

在完成對三次握手的抓包后，間隔了一段時間，來進行四次揮手的抓包。

知識背景

問題一：為什么要四次揮手呢？

在上一章的三次揮手中，我們說tcp協議是

• 面向連接
• 可靠的
• 基于字節流的傳輸層協議

而且在三次握手時有對這些特點進行體現。

在理解過程中，我們可以簡單的將

tcp的通信過程，理解為為兩個陌生的小朋友的行為

• 三次握手：兩個小朋友在相互認識
• 發送數據：兩個小朋友在愉快的玩耍，有來有回的
• 而四次揮手則是兩個小朋友中有一個小朋友要回家了

小朋友A突然被媽媽叫回家了，于是和小朋友B說我要回家了，但是他沒有走，還想聽小朋友B說說話。

小朋友B不舍的說知道了，然后再把之前沒說完的話繼續說完，然后小朋友B也說到，好吧，那你走吧。

小朋友A聽完小朋友B的話之后，愉快的分開了，期待下次的相遇~

四次揮手操作步驟

1.建立連接

此步驟為三次握手的全部過程，詳情見wireshark分析tcp協議（一）三次握手【理論 + 實操】

2.關閉網站

在建立起連接后，我們關閉網站，等待FIN ACK包的出現

但是我們發現這里只有三次揮手出現，而且等待了很久也沒有第四次的出現，為什么呢？

注意：

這里雖然顯示的是三次揮手，但是實際上的 步驟沒有變

只是將第二次和第三次合并了

為什么第二次會沒了呢？

服務器其實在之前就早已經發送完數據了，一直等著你發消息呢！但是你有一直不發，

這時候你說“好了”，服務器收到之后，心里想“好家伙，老子早就不想干了”——客戶端的FIN ACK

于是它快速的返回了“我這邊也完了，快散伙吧，我還要去找其他人玩呢”——服務端的FIN ACK

客戶端接受后，同意了結束請求

為什么服務器在發完數據后不主動結束呢？

因為開啟了TCP延遲確認機制（默認開啟）

3.第一次揮手——請求中斷（FIN,ACK)

在第一次揮手時，我們主動的向服務端發送結束連接請求

我們查看第一條報文

• 源端口：9277，目的端口：80

查看當前的Flags

此時fin和ack都為1，是一個客戶端發送連接請求

• 客戶端序號seq = 3747946131
• 確認序號 seq = 1890243776

4.第二次揮手——服務器請求中斷

• 源端口：80，目的端口：9277
• 服務器序號 = 1890243776
• 服務器確認序號 = （客戶端發送序號）+ 1= 3747946131 + 1

與客戶端發送完成請求一致，不過為 服務端發送請求

5.第三次揮手——客戶端同意結束

• 源端口：9277，目的端口：80
• 客戶端序列號 = 3747946131 + 1 = 3747946132
• 客戶端確認序號 = 服務器端序號 + 1 = 1890243776

自此，中斷連接。

異常情況：RST終止

在研究這四次揮手的時候，我貌似發現了一個不得了的東西

首先，我很正常的等待終止連接

第一個令我疑惑的點出現了：服務器提出終止連接請求

原本，我以為正常情況下，只有客戶端才能主動終止請求的

但是了解下來，發現 TCP中斷，雙方都有權利主動終止請求
因為TCP是全雙工通信，兩者通信地位相等

在服務器主動發送終止指令后，客戶端被動響應終止。

然后客戶端主動提出keep-alive不斷開連接，服務器響應

再一次客戶端提出keep-alive的時候，服務器RST終止了異常的連接。

甚至，我還想到了一個離譜的卑微愛情故事：

服務器首先對客戶端提出了分手，客戶端通過ack猶豫的答應了，但是客戶端發現他還有很多話沒有對服務器說，然后就提出了keep-alive承諾，保持一段時間的交流好嗎？我還有一些話要對你說。
服務器看到keep-alive承諾的情況下，發送ack不耐煩的答應了他。
但是客戶端覺得不放心，又發送了一次，你真的愿意交流一段時間嗎？
最后，服務器直接通過RST關閉了這異常的鏈接……

總結

以上是生活随笔為你收集整理的wireshark分析tcp协议（二）四次挥手（异常情况）【理论 + 实操】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。