TCP 傳送應用資料之前，必須在連線兩端建立狀態。該設定過程就是 TCP 三向握手。它發生得如此之快，以至於大多數使用者從未注意到它，但是當網站感覺緩慢、埠似乎關閉或防火牆以奇怪的方式破壞應用程式時，握手通常就是故事的開始。
TCP 三向握手
這三個資料包是：
- 同步 來自客戶
- 同步確認 來自伺服器
- 確認 來自客戶
之後，連線建立並開始正常資料傳輸。
逐步說明
1.客戶端傳送SYN
客戶端實際上是說，“我想啟動一個連線，這是我的初始序列號。”
2. 伺服器回覆SYN-ACK
The server acknowledges the client's sequence number and sends its own starting sequence number back.
3. 客戶端傳送ACK
客戶端確認伺服器的序列號。此時雙方就可靠地交換資料所需的基本狀態達成一致。
為什麼TCP需要握手
握手不僅僅是儀式。它解決了實際的協議問題：
- 確認兩個端點都可以傳送和接收
- 協商初始序列跟蹤
- 防止舊會話的延遲資料包被誤認為當前流量
- 建立可靠交付所需的狀態
如果沒有此設定，TCP 無法提供應用程式期望的有序、可靠的流行為。
為什麼 TCP 使用三步而不是兩步
兩步交換並不能完全證明雙方已準備好傳輸並確認對方的序列號。第三個資料包確認已收到伺服器的答覆，並且連線狀態在兩個方向上都是同步的。
這就是為什麼握手是“三向”的，而不僅僅是請求-響應對。
握手失敗會發生什麼
握手失敗通常分為幾種可識別的模式。
SYN 已傳送，無回覆
可能原因：
- 目標主機宕機
- 防火牆正在默默地丟棄資料包
- IP或埠錯誤
- 路徑中的路由問題
常見症狀：
- 連線超時
- 瀏覽器旋轉一段時間，然後失敗
telnet或客戶端應用程式在放棄之前掛起
SYN 傳送，RST 返回
可能原因：
- 埠已關閉
- 服務未監聽
- 防火牆配置為拒絕而不是丟棄
常見症狀：
- 立即“連線被拒絕”
SYN 和 SYN-ACK 出現，然後會話終止
可能原因：
- 非對稱路由 續訂時
- 狀態防火牆問題
- 損壞的 NAT 裝置
- 負載均衡器配置錯誤
- 基於主機的安全產品在初始接受後產生干擾
Wireshark 中的握手是什麼樣子的
如果您在 Wireshark 中捕獲流量，健康的 TCP 啟動通常如下所示：
SYNSYN, ACKACK
如果您只看到重複重傳的 SYN 資料包，則伺服器回覆永遠不會返回。如果您看到 RST，則目標主動拒絕了連線。這種可見性就是資料包捕獲對於網路故障排除如此有用的原因。
為什麼握手對效能很重要
每個 TCP 連線在資料流開始之前至少開始一次往返。
如果延遲為 100 毫秒：
- 握手費用大約是一個來回
- TLS 之後新增了更多協商
- 短暫的連線感覺明顯變慢
這是現代效能調優關心連線重用、HTTP 保持活動行為、CDN 以及 HTTP/2 和 HTTP/3 等協議的原因之一。
TCP 握手和 TLS 不是一回事
這是一個常見的混亂來源。
- TCP 握手 建立傳輸連線。
- TLS 握手 在該連線之上協商加密和證書信任。
所以當你開啟HTTPS網站時，系統通常會執行：
- TCP 握手
- TLS 握手
- HTTP 請求和響應
如果站點“開始載入”速度很慢，則延遲可能出現在任一握手層中。
Relationship to Port Scanning
許多掃描器依賴於握手行為：
- 同步確認 通常表示埠開放
- RST 通常表示關閉
- 沒有反應 通常意味著過濾或丟棄
這使得握手不僅是網路的核心，也是列舉和安全測試的核心。
SYN 洪水攻擊
SYN 洪水透過傳送大量 SYN 資料包而不完成最終 ACK 來濫用握手。伺服器為許多半開會話分配資源，並且可能會變得不堪重負。
常見緩解措施：
- SYN cookies
- 速率限制
- 上游過濾
- 防火牆保護
- 負載均衡器調整
連線拆卸不同
啟動會話使用三向握手。關閉它通常使用涉及雙向 FIN 和 ACK 資料包的不同過程。
當除錯套接字陷入困境時，拆卸很重要 TIME_WAIT 或 CLOSE_WAIT，但它與初始連線握手是分開的。
底線
TCP 握手是可靠 TCP 通訊的三步啟動：
- 同步
- 同步確認
- 確認
這很重要，因為基於 TCP 構建的每個 Web 請求、SSH 會話、資料庫連線或 API 呼叫都依賴於它。如果連線超時、被拒絕或在任何資料移動之前感覺很慢，則握手是首先要調查的地方之一。