前言

大家好，我是田螺。

有位朋友去美團面試，問了這么一道面試題：TCP的第三次握手沒有回復，會有什么問題？服務器會出現什么現象？

對于這道題，我們如何去回答，才更好呢？如果是我，我會按照這幾個維度：

• TCP的三次握手過程
• 第三次握手沒有回復，連接建立不了，講解為什么需要三次握手
• 第三次握手沒有回復，服務器會出現什么現象？超時重傳機制
• 第三次握手沒有回復，講解半連接隊列（SYN隊列）和SYN Flood 攻擊
• TCP 握手，在后端思想的一些相似應用

1. TCP的三次握手過程

圖片

開始客戶端和服務器都處于CLOSED狀態，然后服務端開始監聽某個端口，進入LISTEN狀態

• 第一次握手(SYN=1, seq=x)，發送完畢后，客戶端進入SYN_SEND狀態
• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 發送完畢后，服務器端進入 SYN_RCVD 狀態。
• 第三次握手(ACK=1，ACKnum=y+1)，發送完畢后，客戶端進入 ESTABLISHED 狀態，當服務器端接收到這個包時,也進入 ESTABLISHED 狀態，TCP 握手，即可以開始數據傳輸。

2. 第三次握手沒有回復，連接建立不了.

上個小節，我們梳理完TCP三次握手流程，也就是TCP需要三次握手，才能真正建立連接。

如果服務器沒有收到客戶端發送的第三次握手的ACK確認包，那么從服務器的角度看，這個連接仍處于未完全建立的狀態，不能正式用于數據傳輸。

也就是如果沒有第三次握手回復，只有兩次握手，那是不行的。TCP連接，為什么需要三次握手，為什么兩次不行，為什么四次不行？

為了方便理解，我們以談戀愛為例子：兩個人能走到一起，最重要的事情就是相愛，就是我愛你，并且我知道，你也愛我，接下來我們以此來模擬三次握手的過程：

圖片

為什么握手不能是兩次呢？

如果只有兩次握手，女孩子可能就不知道，她的那句我也愛你，男孩子是否收到，戀愛關系就不能愉快展開。

為什么握手不能是四次呢？

因為握手不能是四次呢？因為三次已經夠了，三次已經能讓雙方都知道：你愛我，我也愛你。而四次就多余了。

3. 第三次握手沒有回復，服務器會出現什么現象？

TCP三次握手：

服務器在收到客戶端的 SYN 報文后，會發送一個 SYN-ACK 報文并進入 SYN-RECEIVED 狀態。此時，它正在等待客戶端發送的 ACK 報文。如果客戶端的 ACK 報文沒有到達服務器，服務器會在 SYN-RECEIVED 狀態中停留一段時間（通常稱為超時重傳時間）。

也就是說，第三次握手沒有ACK回復，服務器會在 SYN-RECEIVED 狀態中停留一段時間。然后超時重傳。

然后如果沒有收到客戶端的 ACK 報文，它會重新發送 SYN-ACK 報文。

當然，重試肯定有次數限制的，如果在重傳了多次之后，服務器仍然沒有收到客戶端的 ACK 報文，服務器會認為連接失敗，并放棄這次連接。此時，服務器會進入 CLOSED 狀態，釋放資源。

超時重傳

TCP 為了實現可靠傳輸，實現了重傳機制。最基本的重傳機制，就是超時重傳，即在發送數據報文時，設定一個定時器，每間隔一段時間，沒有收到對方的ACK確認應答報文，就會重發該報文。

這個間隔時間，一般設置為多少呢？我們先來看下什么叫RTT（Round-Trip Time，往返時間）。

圖片

RTT就是，一個數據包從發出去到回來的時間，即數據包的一次往返時間。超時重傳時間，就是Retransmission Timeout ，簡稱RTO。

RTO設置多久呢？

• 如果RTO比較小，那很可能數據都沒有丟失，就重發了，這會導致網絡阻塞，會導致更多的超時出現。
• 如果RTO比較大，等到花兒都謝了還是沒有重發，那效果就不好了。

一般情況下，RTO略大于RTT，效果是最好的。一些小伙伴會問，超時時間有沒有計算公式呢?有的！有個標準方法算RTO的公式，也叫Jacobson / Karels 算法。我們一起來看下計算RTO的公式

1. 先計算SRTT（計算平滑的RTT）

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加權平均

2. 再計算RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //計算 SRTT 與真實值的差距

3. 最終的RTO

RTO = μ * SRTT + ? * RTTVAR  =  SRTT + 4·RTTVAR

其中，α = 0.125，β = 0.25， μ = 1，? = 4，這些參數都是大量結果得出的最優參數。

4. 半連接隊列和SYN Flood 攻擊

在TCP的三次握手中，服務器發送SYN+ACK包之后，會等待客戶端的ACK。如果ACK沒有按時到達，可能是因為網絡丟包或是惡意攻擊（如SYN Flood攻擊）

如果是網絡不穩定，導致的網絡丟包，一般我們重試都會成功的。還有個可能的原因，就是SYN Flood攻擊。

SYN Flood是一種典型的DoS (Denial of Service，拒絕服務) 攻擊，它在短時間內，偽造不存在的IP地址,向服務器大量發起SYN報文。當服務器回復SYN+ACK報文后，不會收到ACK回應報文，導致服務器上建立大量的半連接隊列,半連接隊列滿了，這就無法處理正常的TCP請求啦。

5. TCP 三次握手的一些后端思想應用

TCP三次握手，背后蘊含的一些思想是可以應用到后端系統設計中的。

5.1 狀態確認思想

比如，TCP三次握手確保雙方都知道對方準備好進行通信，并且雙方都能確認自己的消息被對方收到。這個機制本質上是一種狀態同步和確認機制。

這種機制可以應用于分布式系統的節點間通信或客戶端與服務端的連接建立。例如，在微服務之間的通信中，可以在建立連接前，進行雙方的狀態確認或健康檢查，確保后續的通信是可靠的。

5.2 超時重試機制

再比如，TCP三次握手中，服務端會等待客戶端的ACK確認包，如果沒有收到，會根據一定策略進行重試，這背后是重試與超時的機制。

在后端服務中，重試機制和超時處理也非常重要。例如在調用第三方API時，如果網絡波動導致請求失敗，系統可以通過配置合理的重試策略（如指數退避、限流等）來提高成功率，同時避免過載。實例：HTTP請求的重試機制、消息隊列的重發策略等。