TCP三次握手與四次揮手（全網最易懂保姆級教程）

2025-04-30 01:06 馬哥Linux運維

TCP三次握手與四次揮手（全網最易懂保姆級教程）

一、前置知識準備

1.TCP協議特性– 面向連線：通訊前需要建立專用通道– 可靠傳輸：透過確認機制保證資料可達– 全雙工通訊：雙方可同時傳送資料– 流量控制：滑動視窗機制– 擁塞控制：慢啟動演算法
2. 關鍵概念說明
術語
說明
**SYN**
同步序列號（Synchronize），用於建立連線
**ACK**
確認標誌（Acknowledgment），用於確認收到資料
**FIN**
結束標誌（Finish），用於釋放連線
**SEQ**
序列號（32位隨機數），保證資料有序性
**ACK號**
期望收到的下一個資料包的序列號（SEQ+1）
**狀態碼**
如SYN_SENT、ESTABLISHED等，描述TCP連線狀態

二、三次握手深度解析（連線建立）

場景模擬想象你在打電話：– 你："喂，聽得到嗎？"（第一次握手）– 對方："聽得到，你那邊呢？"（第二次握手）– 你："我也能聽到"（第三次握手）
技術細節分解sequenceDiagram    participant Client    participant Server
    Client->>Server: SYN=1, SEQ=X（進入SYN_SENT狀態）    Note right of Client: 生成隨機初始序列號X    Server->>Client: SYN=1, ACK=1, SEQ=Y, ACK=X+1（進入SYN_RCVD狀態）    Note left of Server: 生成隨機初始序列號Y    Client->>Server: ACK=1, SEQ=X+1, ACK=Y+1（進入ESTABLISHED狀態）    Server->>Server: 收到ACK後進入ESTABLISHED狀態
第一次握手（SYN）
  • • 客戶端傳送SYN包：
    • • 設定SYN標誌位為1
    • • 生成隨機初始序列號X（防止歷史連線衝突）
    • • 不攜帶應用資料
  • • 客戶端狀態變為SYN_SENT
第二次握手（SYN+ACK）
  • • 服務端返回確認包：
    • • 同時設定SYN和ACK標誌位為1
    • • 生成隨機初始序列號Y
    • • 確認號為X+1（期待下次收到X+1）
  • • 服務端狀態變為SYN_RCVD
第三次握手（ACK）
  • • 客戶端傳送確認包：
    • • 設定ACK標誌位為1
    • • 序列號變為X+1（與第一次握手呼應）
    • • 確認號為Y+1（期待服務端下次傳送Y+1）
  • • 雙方進入ESTABLISHED狀態

❓ 高頻面試題：為什麼需要三次握手？

  1. 1.防止歷史連線：避免失效的SYN包突然到達導致錯誤連線
  2. 2.同步初始序列號：雙方確認對方的收發能力正常
  3. 3.避免資源浪費：二次握手時服務端會提前分配資源，可能遭受SYN攻擊

三、四次揮手深度解析（連線釋放）

場景模擬

想象結束通話：
  • • 你："我說完了，掛了啊"（第一次揮手）
  • • 對方："好的，知道了"（第二次揮手）
  • • 對方："我也說完了"（第三次揮手）
  • • 你："好的，斷開吧"（第四次揮手）

技術細節分解

sequenceDiagramparticipant Clientparticipant Server
Client->>Server: FIN=1, SEQ=U（進入FIN_WAIT_1狀態）Server->>Client: ACK=1, ACK=U+1（進入CLOSE_WAIT狀態）Server->>Client: FIN=1, SEQ=V（進入LAST_ACK狀態）Client->>Server: ACK=1, ACK=V+1（進入TIME_WAIT狀態）
第一次揮手（FIN）
  • • 主動關閉方傳送FIN包：
    • • 設定FIN標誌位為1
    • • 序列號為當前已傳輸資料的最後一個位元組序號+1（U）
  • • 進入FIN_WAIT_1狀態
第二次揮手（ACK）
  • • 被動關閉方返回ACK包：
    • • 確認號設定為U+1
    • • 仍可以繼續傳送未傳輸完的資料
  • • 進入CLOSE_WAIT狀態（半關閉狀態）
  • • 主動方收到後進入FIN_WAIT_2狀態
第三次揮手（FIN）
  • • 被動關閉方傳送FIN包：
    • • 當資料全部發送完畢後傳送FIN
    • • 序列號為V（基於自己的資料傳輸進度）
  • • 進入LAST_ACK狀態
第四次揮手（ACK）
  • • 主動關閉方傳送ACK包：
    • • 確認號設定為V+1
    • • 進入TIME_WAIT狀態（等待2MSL）
  • • 被動關閉方收到後關閉連線

❓ 高頻面試題：為什麼需要四次揮手？

  1. 1.半關閉特性：收到FIN僅表示對方不再發送資料，己方可能仍需傳送剩餘資料
  2. 2.ACK延遲：將FIN和ACK分開發送，避免因延遲導致狀態混亂
  3. 3.確保可靠終止：TIME_WAIT狀態處理延遲到達的資料包（等待2MSL）

四、關鍵補充知識

1. TIME_WAIT狀態詳解

  • •持續時間：2倍MSL（Maximum Segment Lifetime）
    • • Linux預設MSL=60秒，因此TIME_WAIT=120秒
  • •核心作用：
    • • 確保最後一個ACK到達
    • • 讓舊連線的重複分節在網路中失效

2. 異常情況處理

場景
處理機制
握手丟包
超時重傳（SYN重試次數由/proc/sys/net/ipv4/tcp_syn_retries控制）
FIN丟失
重傳FIN包直到收到ACK或超時
服務端程序崩潰
客戶端傳送資料會觸發RST復位響應
網路中斷
心跳包檢測機制（TCP Keepalive）

五、實戰抓包分析（Wireshark演示）

三次握手過程No. Time Source Destination Protocol Info1 0.0000 192.168.1.2 192.168.1.3 TCP [SYN] Seq=02 0.0008 192.168.1.3 192.168.1.2 TCP [SYN, ACK] Seq=0 Ack=13 0.0010 192.168.1.2 192.168.1.3 TCP [ACK] Seq=1 Ack=1
四次揮手過程4 5.1234 192.168.1.2 192.168.1.3 TCP [FIN, ACK] Seq=1 Ack=15 5.1235 192.168.1.3 192.168.1.2 TCP [ACK] Seq=1 Ack=26 5.2345 192.168.1.3 192.168.1.2 TCP [FIN, ACK] Seq=1 Ack=27 5.2346 192.168.1.2 192.168.1.3 TCP [ACK] Seq=2 Ack=2

六、常見問題彙總

Q1：SYN洪水攻擊原理？

攻擊者偽造大量SYN包耗盡服務端資源，服務端維護半連線佇列導致正常請求無法處理

Q2：為什麼不能三次揮手？

因為TCP是全雙工的，必須保證兩個方向的連線都正確關閉

Q3：CLOSE_WAIT狀態過多怎麼辦？

通常是應用程式未正確呼叫close()，需要檢查程式碼是否正確關閉socket

Q4：TIME_WAIT狀態最佳化方案？

  • • 修改核心引數：net.ipv4.tcp_tw_reuse
  • • 使用SO_REUSEADDR選項
  • • 改用長連線
連結：https://blog.csdn.net/qq_56323274/article/details/146460099?spm=1001.2014.3001.5502
（版權歸原作者所有，侵刪）
文末福利
就目前來說，傳統運維衝擊年薪30W+的轉型方向就是SRE&DevOps崗位。
為了幫助大家早日擺脫繁瑣的基層運維工作，給大家整理了一套高階運維工程師必備技能資料包，內容有多詳實豐富看下圖！
共有 20 個模組
1.38張最全工程師技能圖譜
2.面試大禮包
3.Linux書籍
4.go書籍
······
6.自動化運維工具
18.訊息佇列合集
 以上所有資料獲取請掃碼
備註：最新運維資料
100%免費領取
（後臺不再回復，掃碼一鍵領取）


相關文章