TCP 狀態機

下圖所示的狀態機展示了，通信雙方建立 TCP 連接之后的狀態轉換過程。

圖片來源: tcpipguide.com

通信雙方主動發起關閉連接的一端，存在 TIME_WAIT 狀態，被動接受關閉連接的一端，會進入 CLOSE_WAIT 狀態。

處于 TIME_WAIT 狀態的一端，主要浪費兩種資源:

• 端口號 (主要資源)
• 系統資源 (文件描述符、內存資源、CPU 資源、線程資源)，對于現代化硬件來說，這點資源可以忽略不計

兩個問題

這里以客戶端主動關閉連接為例，先來看下經典的 “四次揮手” 過程:

圖片來源: tcpipguide.com

• 第一次揮手: 當客戶端沒有要發送的數據時，向服務端發送 FIN 消息，客戶端進入 FIN_WAIT_1 狀態
• 第二次揮手: 服務端收到客戶端的 FIN 消息之后，進入 CLOSE_WAIT 狀態，然后向客戶端發送 ACK 消息，客戶端收到 ACK 消息之后進入 FIN_WAIT_2 狀態
• 第三次揮手: 當服務端沒有要發送的數據時，向客戶端發送 FIN 消息，然后服務端進入 LAST_ACK 狀態
• 第四次揮手: 客戶端收到服務端的 FIN 消息之后，進入 TIME_WAIT 狀態，然后向服務端發送 ACK 消息，服務端收到 ACK 消息進入 CLOSED 狀態
• 客戶端等大等待 2 個 MSL 時間后進入 CLOSED 狀態

客戶端需要維護一個 TIME_WAIT 狀態長達 2 個 MSL 時間，以 Linux 5.0 代碼為例，也就是 2 分鐘。

// https://github.com/torvalds/linux/blob/1c163f4c7b3f621efff9b28a47abb36f7378d783/include/net/tcp.h#L121

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, about 60 seconds */

為什么是 2 個 MSL 時間呢？

因為發送方要考慮數據報文 從發送方到接收方的 MSL, 反過來說，接收方也要考慮 ACK 報文從接收方到發送方的 MSL，所以一共是 2 個 MSL （通信雙方各一個）。

之所以采用這種機制，主要是為了避免發生下面兩個問題：

• 防止被動關閉連接的一端，延遲的數據被后續使用 相同四元組的 TCP 連接 接收
• 防止被動關閉連接的一端，發出的 FIN 消息沒有收到對應的 ACK 消息，而在新連接到來的時候發送 RST 消息

下面就這兩個問題來進行分析說明。

第一個問題

防止被動關閉連接的一端，延遲的數據被后續使用 相同四元組的新連接 接收。

簡單來說，就是防止舊的 TCP 連接，因為延遲到達的報文，而干擾到了復用相同四元組的新連接。

四元組客戶端客戶端端口服務端服務端端口

下面來舉例說一下什么場景下會出現這種情況。

延遲到達的報文干擾到了新連接

• 假設在客戶端在主動關閉連接前，服務端發送了一個 seq = 1001 的數據包 A，但是由于網絡原因一直沒有送達到客戶端 (也就是以說，該數據包延遲了)
• 如果客戶端沒有 TIME_WAIT 狀態，那么客戶端第四次揮手后，此時客戶端會直接進入 CLOSED 狀態
• 延遲的數據包 A 依然沒有到來
• 這時客戶端又向服務端發起新的連接，很巧的是，這個新連接和剛才 (已關閉) 的舊連接使用了同樣的端口 (復用)，于是新連接和舊連接的四元組變成了一樣的
• 新連接建立完成后，舊連接上面的延遲數據包 A 到了 (新連接)，這時就會產生嚴重的問題 ...

通過 TIME_WAIT 狀態，發起主動關閉連接的一端會等待 2 個 MSL 時間，這個時間足夠長，可以最大限度消除延遲的數據包可能對新 (復用端口) 的連接造成影響， TIME_WAIT 狀態下接收到的延遲數據包會被直接丟棄。

這里考慮一個極端的 (小概率) 問題: 經過 2 個 MSL 時間之后，延遲的數據包 A 到達了，并且其 Seq 正好位于新連接的接收窗口內，那么新連接 (TCP 傳輸層) 會直接將整個數據包轉交到上層應用嗎？

根據應用層安全 (是否加密) 程度，分為兩種情況:

• 未加密，那么就會干擾應用數據，例如源數據為 “我的頭像牛 X 嗎？”，因為延遲的數據包，在 頭 字后面插入了一個逗號，變成了 “我的頭，像牛 X 嗎？”
• 已加密 (例如使用了 HTTPS)，TLS 會校驗數據完整性，那么顯然數據包 A 是無法通過校驗的，然后被直接丟棄，HTTPS 連接就此中斷

第二個問題

防止被動關閉連接的一端，發出的 FIN 消息沒有收到對應的 ACK 消息，而在新連接到來的時候發送 RST 消息。

簡單來說，就是防止舊的 TCP 連接在第四次揮手中發出的 ACK 消息沒有被對端收到，而導致復用相同四元組的新連接在和對端建立連接時被拒絕。

下面來舉例說一下什么場景下會出現這種情況。

新連接建立時被 RST 消息拒絕

• 客戶端第四次揮手時向服務端發送 ACK 消息，但是這個 ACK 消息一直因為網絡原因一直未送達，所以服務端的狀態停留在了 LAST-ACK，而不是正常的 CLOSED 狀態
• 如果客戶端沒有 TIME_WAIT 狀態，那么客戶端第四次揮手后，此時客戶端會直接進入 CLOSED 狀態，但是此時服務端認為這條連接依然是有效的 (還未徹底斷開)
• 這時客戶端又向服務端發起新的連接，很巧的是，這個新連接和剛才 (已關閉) 的舊連接使用了同樣的端口 (復用)，于是新連接和舊連接的四元組變成了一樣的
• 服務端收到了客戶端的新鏈接建立時發送的 SYNC 消息，在服務端看來，這其實是一條舊的有效連接 (因為新連接和舊連接的四元組是一樣的)，所以會直接返回 RST 消息，拒絕新連接的建立 (連接過程到此終止)

通過 TIME_WAIT 狀態，發起主動關閉連接的一端會等待 2 個 MSL 時間，這個時間足夠長，那么服務端可能會出現兩種情況:

• 收到了客戶端的 ACK 消息，正常關閉連接，進入 CLOSE 狀態
• 沒有收到客戶端的 ACK 消息，重新發送 FIN 消息關閉連接并等待新的 ACK 消息 (重新執行第三次、四次揮手)

問題場景

分析完了 TIME_WAIT 狀態的作用之外，什么場景下會出現大量的 TIME_WAIT 狀態連接呢？

通信雙方主動發起關閉連接的一端，存在 TIME_WAIT 狀態，最經典的場景就是 并發壓力測試。

當我們在本地 (客戶端) 啟動并發壓力測試時，通常會設置成百上千的并發連接去訪問服務端接口，這些連接會快速且大量消耗 TCP 連接資源，每個連接在完成接口請求后會理解進入 TIME_WAIT 狀態。

例如，在 Linux 系統中，可以使用 netstat 命令來查看各個不同狀態的網絡連接:

$ netstat -ant | grep TIME_WAIT

# 輸出如下
tcp6       0      0 1.1.1.1:443          127.0.0.1:59490         TIME_WAIT
tcp6       0      0 1.1.1.1:443          127.0.0.1:59472         TIME_WAIT
tcp6       0      0 1.1.1.1:443          127.0.0.1:59480         TIME_WAIT
tcp6       0      0 1.1.1.1:443          127.0.0.1:59514         TIME_WAIT
tcp6       0      0 1.1.1.1:443          127.0.0.1:59484         TIME_WAIT
tcp6       0      0 1.1.1.1:443          127.0.0.1:59520         TIME_WAIT

這類問題如何解決，后面再專門寫一篇高性能網絡編程中 TCP 調優的文章 :-)。

? 思考

如果系統中出現大量的 CLOSE_WAIT 狀態連接，可能原因是什么呢？如何解決？