為什么 TCP 需要 TIME_WAIT，你知道嗎 ?
TCP 狀態(tài)機
下圖所示的狀態(tài)機展示了，通信雙方建立 TCP 連接之后的狀態(tài)轉(zhuǎn)換過程。
圖片來源: tcpipguide.com
通信雙方主動發(fā)起關閉連接的一端，存在 TIME_WAIT 狀態(tài)，被動接受關閉連接的一端，會進入 CLOSE_WAIT 狀態(tài)。
處于 TIME_WAIT 狀態(tài)的一端，主要浪費兩種資源:
- 端口號 (主要資源)
- 系統(tǒng)資源 (文件描述符、內(nèi)存資源、CPU 資源、線程資源)，對于現(xiàn)代化硬件來說，這點資源可以忽略不計
兩個問題
這里以客戶端主動關閉連接為例，先來看下經(jīng)典的 “四次揮手” 過程:
圖片來源: tcpipguide.com
- 第一次揮手: 當客戶端沒有要發(fā)送的數(shù)據(jù)時，向服務端發(fā)送 FIN 消息，客戶端進入 FIN_WAIT_1 狀態(tài)
- 第二次揮手: 服務端收到客戶端的 FIN 消息之后，進入 CLOSE_WAIT 狀態(tài)，然后向客戶端發(fā)送 ACK 消息，客戶端收到 ACK 消息之后進入 FIN_WAIT_2 狀態(tài)
- 第三次揮手: 當服務端沒有要發(fā)送的數(shù)據(jù)時，向客戶端發(fā)送 FIN 消息，然后服務端進入 LAST_ACK 狀態(tài)
- 第四次揮手: 客戶端收到服務端的 FIN 消息之后，進入 TIME_WAIT 狀態(tài)，然后向服務端發(fā)送 ACK 消息，服務端收到 ACK 消息進入 CLOSED 狀態(tài)
- 客戶端等大等待 2 個 MSL 時間后進入 CLOSED 狀態(tài)
客戶端需要維護一個 TIME_WAIT 狀態(tài)長達 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 時間呢？
因為發(fā)送方要考慮數(shù)據(jù)報文 從發(fā)送方到接收方的 MSL, 反過來說，接收方也要考慮 ACK 報文從接收方到發(fā)送方的 MSL，所以一共是 2 個 MSL （通信雙方各一個）。
之所以采用這種機制，主要是為了避免發(fā)生下面兩個問題：
- 防止被動關閉連接的一端，延遲的數(shù)據(jù)被后續(xù)使用 相同四元組的 TCP 連接 接收
- 防止被動關閉連接的一端，發(fā)出的 FIN 消息沒有收到對應的 ACK 消息，而在新連接到來的時候發(fā)送 RST 消息
下面就這兩個問題來進行分析說明。
第一個問題
防止被動關閉連接的一端，延遲的數(shù)據(jù)被后續(xù)使用 相同四元組的新連接 接收。
簡單來說，就是防止舊的 TCP 連接，因為延遲到達的報文，而干擾到了復用相同四元組的新連接。
四元組客戶端客戶端端口服務端服務端端口
下面來舉例說一下什么場景下會出現(xiàn)這種情況。
延遲到達的報文干擾到了新連接
- 假設在客戶端在主動關閉連接前，服務端發(fā)送了一個 seq = 1001 的數(shù)據(jù)包 A，但是由于網(wǎng)絡原因一直沒有送達到客戶端 (也就是以說，該數(shù)據(jù)包延遲了)
- 如果客戶端沒有 TIME_WAIT 狀態(tài)，那么客戶端第四次揮手后，此時客戶端會直接進入 CLOSED 狀態(tài)
- 延遲的數(shù)據(jù)包 A 依然沒有到來
- 這時客戶端又向服務端發(fā)起新的連接，很巧的是，這個新連接和剛才 (已關閉) 的舊連接使用了同樣的端口 (復用)，于是新連接和舊連接的四元組變成了一樣的
- 新連接建立完成后，舊連接上面的延遲數(shù)據(jù)包 A 到了 (新連接)，這時就會產(chǎn)生嚴重的問題 ...
通過 TIME_WAIT 狀態(tài)，發(fā)起主動關閉連接的一端會等待 2 個 MSL 時間，這個時間足夠長，可以最大限度消除延遲的數(shù)據(jù)包可能對新 (復用端口) 的連接造成影響， TIME_WAIT 狀態(tài)下接收到的延遲數(shù)據(jù)包會被直接丟棄。
這里考慮一個極端的 (小概率) 問題: 經(jīng)過 2 個 MSL 時間之后，延遲的數(shù)據(jù)包 A 到達了，并且其 Seq 正好位于新連接的接收窗口內(nèi)，那么新連接 (TCP 傳輸層) 會直接將整個數(shù)據(jù)包轉(zhuǎn)交到上層應用嗎？
根據(jù)應用層安全 (是否加密) 程度，分為兩種情況:
- 未加密，那么就會干擾應用數(shù)據(jù)，例如源數(shù)據(jù)為 “我的頭像牛 X 嗎？”，因為延遲的數(shù)據(jù)包，在 頭 字后面插入了一個逗號，變成了 “我的頭，像牛 X 嗎？”
- 已加密 (例如使用了 HTTPS)，TLS 會校驗數(shù)據(jù)完整性，那么顯然數(shù)據(jù)包 A 是無法通過校驗的，然后被直接丟棄，HTTPS 連接就此中斷
第二個問題
防止被動關閉連接的一端，發(fā)出的 FIN 消息沒有收到對應的 ACK 消息，而在新連接到來的時候發(fā)送 RST 消息。
簡單來說，就是防止舊的 TCP 連接在第四次揮手中發(fā)出的 ACK 消息沒有被對端收到，而導致復用相同四元組的新連接在和對端建立連接時被拒絕。
下面來舉例說一下什么場景下會出現(xiàn)這種情況。
新連接建立時被 RST 消息拒絕
- 客戶端第四次揮手時向服務端發(fā)送 ACK 消息，但是這個 ACK 消息一直因為網(wǎng)絡原因一直未送達，所以服務端的狀態(tài)停留在了 LAST-ACK，而不是正常的 CLOSED 狀態(tài)
- 如果客戶端沒有 TIME_WAIT 狀態(tài)，那么客戶端第四次揮手后，此時客戶端會直接進入 CLOSED 狀態(tài)，但是此時服務端認為這條連接依然是有效的 (還未徹底斷開)
- 這時客戶端又向服務端發(fā)起新的連接，很巧的是，這個新連接和剛才 (已關閉) 的舊連接使用了同樣的端口 (復用)，于是新連接和舊連接的四元組變成了一樣的
- 服務端收到了客戶端的新鏈接建立時發(fā)送的 SYNC 消息，在服務端看來，這其實是一條舊的有效連接 (因為新連接和舊連接的四元組是一樣的)，所以會直接返回 RST 消息，拒絕新連接的建立 (連接過程到此終止)
通過 TIME_WAIT 狀態(tài)，發(fā)起主動關閉連接的一端會等待 2 個 MSL 時間，這個時間足夠長，那么服務端可能會出現(xiàn)兩種情況:
- 收到了客戶端的 ACK 消息，正常關閉連接，進入 CLOSE 狀態(tài)
- 沒有收到客戶端的 ACK 消息，重新發(fā)送 FIN 消息關閉連接并等待新的 ACK 消息 (重新執(zhí)行第三次、四次揮手)
問題場景
分析完了 TIME_WAIT 狀態(tài)的作用之外，什么場景下會出現(xiàn)大量的 TIME_WAIT 狀態(tài)連接呢？
通信雙方主動發(fā)起關閉連接的一端，存在 TIME_WAIT 狀態(tài)，最經(jīng)典的場景就是 并發(fā)壓力測試。
當我們在本地 (客戶端) 啟動并發(fā)壓力測試時，通常會設置成百上千的并發(fā)連接去訪問服務端接口，這些連接會快速且大量消耗 TCP 連接資源，每個連接在完成接口請求后會理解進入 TIME_WAIT 狀態(tài)。
例如，在 Linux 系統(tǒng)中，可以使用 netstat 命令來查看各個不同狀態(tài)的網(wǎng)絡連接:
$ 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這類問題如何解決，后面再專門寫一篇高性能網(wǎng)絡編程中 TCP 調(diào)優(yōu)的文章 :-)。
? 思考
如果系統(tǒng)中出現(xiàn)大量的 CLOSE_WAIT 狀態(tài)連接，可能原因是什么呢？如何解決？
