wait 詳解和解決方案

產生原因

TCP 連接關閉時，會有 4 次通訊（四次揮手），來確認雙方都停止收發數據了。如上圖，主動關閉方，最後發送 ACK 時，會進入 TIME_WAIT 狀態，要等 2MSL 時間後，這條連接才真正消失。

為什麼要進入 TIME_WAIT 狀態？

TCP 的可靠傳輸機制要求，被動關閉方（簡稱 S）要確保最後發送的 FIN K 對方能收到。比如網絡中的某個路由器出現異常，主動關閉方（簡稱 C）回覆的 ACK K+1 沒有及時到達，S 就會重發 FIN K 給 C。如果此時 C 不進入 TIME_WAIT 狀態，立馬關閉連接，會有 2 種情況：

1. C 機器上，有可能新起的連接會重用舊連接的端口，此時新連接就會收到 S 端重發的 FIN K 消息，導致新連接傳輸出現錯誤。
2. C 機器上，並沒有用舊連接端口，此時會回覆給 S 端一個 RST 類型的消息，應用程序報 connect reset by peer 異常。

為避免上面情況， TCP 會等待 2 MSL 時間，讓 S 發的 FIN K 和 C 回覆的 ACK K+1 在網絡上消失，才真正清除掉連接。

為什麼等待 2 MSL 時間？

MSL是 Maximum Segment Lifetime的英文縮寫，可譯為“最長報文段壽命”，是 TCP 協議規定報文段在網絡中最長生存時間，超出後報文段就會被丟棄。RFC793 定義 MSL 為 2 分鐘，一般 Linux 會默認設置個更小的值 30 秒。

MSL 時間，是從 C 回覆 ACK 後開始 TIME_WAIT 計時，如果這期間收到 S 重發的 FIN 在回覆 ACK 後，重新開始計時。這塊代碼是 Linux tcp_timewait_state_process 函數處理的。

而 2 MSL 是為了確保 C 和 S 兩端發送的數據都在網絡中消失，不會影響後續的新連接，該如何理解？

假設 C 回覆 ACK ，S 經過 t 時間後收到，則有 0 < t <= MSL，因為 C 並不知道 S 多久收到，所以 C 至少要維持 MSL 時間的 TIME_WAIT 狀態，才確保回覆的 ACK 從網絡中消失。 如果 S 在 MSL 時間收到 ACK， 而收到前一瞬間， 因為超時又重傳一個 FIN ，這個包又要 MSL 時間才會從網絡中消失。

回覆需要 MSL 消失 + 發送需要 MSL 消失 = 2 MSL。

導致問題

從前面的分析來看，出現 TIME_WAIT 屬於正常行為。但在實際生產環境中，大量的 TIME_WAIT 會導致系統異常。

假設前面的 C 是 Client，S 是 Server，如果 C 或 出現大量的 TIME_WAIT，會導致新連接無端口可以用，出現

Cannot assign requested address 錯誤。這是因為端口被佔完了，Linux 一般默認端口範圍是：32768-61000，可以通過 cat /proc/sys/net/ipv4/ip_local_port_range 來查看。根據 TCP 連接四元組計算，C 連接 S 最多有 28232 可以用，也就是說最多同時有 28232 個連接保持。

看著挺多，但如果用短連接的話很快就會出現上面錯誤，因為每個連接關閉後，需要保持 2 MSL 時間，也就是 4分鐘。這意味著 4 分鐘內最多建立 28232 個連接，每秒鐘 117 個，在高併發系統下一般不夠用的。

Nginx

連接主動關閉方會進入 TIME_WAIT，如果 C 先關閉，C 會出現上面錯誤。如果是客戶端時真正的客戶（瀏覽器），一般不會觸發上面的錯誤。

如果 C 是應用程序或代理，比如 Nginx，此時鏈路是：瀏覽器 -> Nginx -> 應用。 因為 Nginx 是轉發請求，自身也是客戶端，所以如果 Nginx 到應用是短連接，每次轉發完請求都主動關閉連接，那很快會觸發到端口不夠用的錯誤。

Nginx 默認配置連接到後端是 HTTP/1.0 不支持 HTTP keep-alive，所以每次後端應用都會主動關閉連接，這樣後端出現 TIME_WAIT，而 Nginx 不會出現。

後端出現大量的 TIME_WAIT 一般問題不明顯，但需要注意的點是：

查看服務器上 /var/log/messages 有沒有 TCP: time wait bucket table overflow 的日誌，有的話是超出最大 TIME_WAIT 的數量了，超出後系統會把多餘的 TIME_WAIT 刪除掉，會導致前面章節介紹的 2 種情況。

這個錯誤可以調大內核參數 /etc/sysctl.conf 中 tcp_max_tw_buckets 來解決。

長連接

另外個解決方案是 Nginx 與後端調用，啟用 HTTP/1.1 開啟 keep-alive ，保持長連接。配置如下：

<code>http{
    upstream www{
        keepalive 500;  # 與後端最多保持的長連接數量
    }
    proxy_set_header X-Real-IP $remote_addr; ## 不會生效
    server {
        location / {
        proxy_http_version 1.1;  # 啟用 HTTP/1.1
        proxy_set_header Connection "";   
        }
    }
}/<code>

proxy_set_header Connection ""; 這個配置是設置 Nginx 請求後端的 Connection header 的值為空。目的是防止客戶端傳值 close 給 Nginx，Nginx 又轉發給後端，導致無法保持長連接。

在 Nginx 配置中有個注意的點是：當前配置 location 中如果定義了 proxy_set_header ，則不會從上級繼承 proxy_set_header 了，如上面配置的 proxy_set_header X-Real-IP $remote_addr 則不會生效。

沒有顯示定義的 header，Nginx 默認只帶下面 2 個 header：

<code>proxy_set_header Host $proxy_host;
proxy_set_header Connection close;/<code>

解決方案

除保持長連接外，調整系統參數也可以解決大量 TIME_WAIT 的問題。

加快回收

tcp_tw_timeout = 30：表示連接在 TIME_WAIT 狀態下的過期時間。這裡配置 30 秒後回收，如前面計算調整後 28232 / 30 = 936， 每秒鐘可建立連接 936 個。

增加端口數量

ip_local_port_range = 1024 65535: 調整後最大端口數量 64511，64511 / 30 = 2150，每秒鐘可建立連接 2150 個。

複用 TIME_WAIT 連接

tcp_tw_reuse = 1： 1 表示開啟複用 TIME_WAIT 狀態的連接，這個參數在 Linux tcp_twsk_unique 函數中讀取的。

<code>int reuse = sock_net(sk)->ipv4.sysctl_tcp_tw_reuse;
\t// tcptw->tw_ts_recent_stamp 為 1 表示舊的 TIME_WAIT 連接是攜帶時間戳的，需要開啟 tcp_timestamps (已默認開啟)。
    // tcp_tw_reuse  reuse 開啟複用
   // time_after32 表示舊的 TIME_WAIT 連接，最後收到數據已超過 1 秒。
\tif (tcptw->tw_ts_recent_stamp &&
\t    (!twp || (reuse && time_after32(ktime_get_seconds(),
\t\t\t\t\t    tcptw->tw_ts_recent_stamp)))) {
\t\tif (likely(!tp->repair)) {
\t\t\tu32 seq = tcptw->tw_snd_nxt + 65535 + 2;

\t\t\tif (!seq)
\t\t\t\tseq = 1;
\t\t\tWRITE_ONCE(tp->write_seq, seq);
\t\t\ttp->rx_opt.ts_recent\t   = tcptw->tw_ts_recent;
\t\t\ttp->rx_opt.ts_recent_stamp = tcptw->tw_ts_recent_stamp;
\t\t}
\t\tsock_hold(sktw);
\t\treturn 1;
\t}/<code>

其他

tcp_tw_recycle 也有效果，但不建議調整，Linux 4.12 後已經移除這個參數了，這裡不做介紹了。

調整命令：

<code>// 臨時生效
sysctl -w net.ipv4.tcp_tw_reuse = 1
sysctl -p

// 長久生效
vi /etc/sysctl.conf/<code>

閱讀更多 sandag 的文章

關鍵字: Nginx 0verflow 瀏覽器