服務端 TCP 連接的 TIME_WAIT 問題

1.問題描述

模擬高並發的場景，會出現批量的 TIME_WAIT 的 TCP 連接：

短時間后，所有的 TIME_WAIT 全都消失，被回收，端口包括服務，均正常。

即，在高並發的場景下，TIME_WAIT 連接存在，屬於正常現象。

線上場景中，持續的高並發場景

• 一部分 TIME_WAIT 連接被回收，但新的 TIME_WAIT 連接產生；
• 一些極端情況下，會出現大量的 TIME_WAIT 連接。

Think：

上述大量的 TIME_WAIT 狀態 TCP 連接，有什么業務上的影響嗎？

Nginx 作為反向代理時，大量的短鏈接，可能導致 Nginx 上的 TCP 連接處於 time_wait 狀態：

1. 每一個 time_wait 狀態，都會占用一個「本地端口」，上限為 65535(16 bit，2 Byte)；
2. 當大量的連接處於 time_wait 時，新建立 TCP 連接會出錯，address already in use : connect異常

統計 TCP 連接的狀態：

1. // 統計：各種連接的數量
2. $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
3. ESTABLISHED 1154
4. TIME_WAIT 1645

Tips：

TCP 本地端口數量，上限為 65535（6.5w），這是因為 TCP 頭部使用 16 bit，存儲「端口號」，因此約束上限為 65535。

2.問題分析

大量的 TIME_WAIT 狀態 TCP 連接存在，其本質原因是什么？

1. 大量的短連接存在
2. 特別是 HTTP 請求中，如果 connection 頭部取值被設置為 close 時，基本都由「服務端」發起主動關閉連接
3. 而，TCP 四次揮手關閉連接機制中，為了保證 ACK 重發和丟棄延遲數據，設置 time_wait為 2 倍的 MSL（報文最大存活時間）

TIME_WAIT 狀態：

1. TCP 連接中，主動關閉連接的一方出現的狀態；（收到 FIN 命令，進入 TIME_WAIT 狀態，並返回 ACK 命令）
2. 保持 2 個 MSL 時間，即，4 分鍾；（MSL 為 2 分鍾）

3.解決辦法

解決上述 time_wait 狀態大量存在，導致新連接創建失敗的問題，一般解決辦法：

1. 客戶端，HTTP 請求的頭部，connection 設置為 keep-alive，保持存活一段時間：現在的瀏覽器，一般都這么進行了
2. 服務器端，
   1. 允許 time_wait 狀態的 socket 被重用
   2. 縮減 time_wait 時間，設置為 1 MSL（即，2 mins）

更多細節，參考：

• https://www.cnblogs.com/yjf512/p/5327886.html

結論：幾個核心要點

1. time_wait 狀態的影響：
   1. TCP 連接中，「主動發起關閉連接」的一端，會進入 time_wait 狀態
   2. time_wait 狀態，默認會持續 2 MSL（報文的最大生存時間），一般是 2x2 mins
   3. time_wait 狀態下，TCP 連接占用的端口，無法被再次使用
   4. TCP 端口數量，上限是 6.5w（65535，16 bit）
   5. 大量 time_wait 狀態存在，會導致新建 TCP 連接會出錯，address already in use : connect異常
2. 現實場景：
   1. 服務器端，一般設置：不允許「主動關閉連接」
   2. 但 HTTP 請求中，http 頭部 connection 參數，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接
   3. 現在瀏覽器中， HTTP 請求 connection 參數，一般都設置為 keep-alive
   4. Nginx 反向代理場景中，可能出現大量短鏈接，服務器端，可能存在
3. 解決辦法：
   1. 服務器端，
      1. 允許 time_wait 狀態的 socket 被重用
      2. 縮減 time_wait 時間，設置為 1 MSL（即，2 mins）

4.附錄

幾個方面：

1. TCP 連接狀態的查詢
2. MSL 時間
3. TCP 三次握手和四次握手

附錄 A：查詢 TCP 連接狀態

Mac 下，查詢 TCP 連接狀態的具體命令：

1. // Mac 下，查詢 TCP 連接狀態
2. $ netstat -nat |grep TIME_WAIT
3. ​
4. // Mac 下，查詢 TCP 連接狀態，其中 -E 表示 grep 或的匹配邏輯
5. $ netstat -nat | grep -E "TIME_WAIT|Local Address"
6. Proto Recv-Q Send-Q Local Address Foreign Address (state)
7. tcp4 0 0 127.0.0.1.1080 127.0.0.1.59061 TIME_WAIT
8. ​
9. // 統計：各種連接的數量
10. $ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
11. ESTABLISHED 1154
12. TIME_WAIT 1645

附錄 B：MSL 時間

MSL，Maximum Segment Lifetime，“報文最大生存時間”，

1. 任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。（IP 報文）
2. TCP報文 （segment）是ip數據報（datagram）的數據部分。

Tips：

RFC 793中規定MSL為2分鍾，實際應用中常用的是30秒，1分鍾和2分鍾等。

2MSL，TCP 的 TIME_WAIT 狀態，也稱為2MSL等待狀態：

1. 當TCP的一端發起主動關閉（收到 FIN 請求），在發出最后一個ACK 響應后，即第3次握 手完成后，發送了第四次握手的ACK包后，就進入了TIME_WAIT狀態。
2. 必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最后一個 ACK包對方沒收到，那么對方在超時后將重發第三次握手的FIN包，主動關閉端接到重發的FIN包后，可以再發一個ACK應答包。
3. 在 TIME_WAIT 狀態時，兩端的端口不能使用，要等到2MSL時間結束，才可繼續使用。（IP 層）
4. 當連接處於2MSL等待階段時，任何遲到的報文段都將被丟棄。

不過在實際應用中，可以通過設置 「SO_REUSEADDR選項」，達到不必等待2MSL時間結束，即可使用被占用的端口。

附錄 C：TCP 三次握手和四次握手

詳細細節，參考：

• TCP的三次握手與四次揮手（詳解+動圖）

具體示意圖：

1. 三次握手，建立連接過程
2. 四次揮手，釋放連接過程

幾個核心疑問：

1. time_wait 是「服務器端」的狀態？or 「客戶端」的狀態？
   1. RE：time_wait 是「主動關閉 TCP 連接」一方的狀態，可能是「客服端」的，也可能是「服務器端」的
   2. 一般情況下，都是「客戶端」所處的狀態；「服務器端」一般設置「不主動關閉連接」
2. 服務器在對外服務時，是「客戶端」發起的斷開連接？還是「服務器」發起的斷開連接？
   1. 正常情況下，都是「客戶端」發起的斷開連接
   2. 「服務器」一般設置為「不主動關閉連接」，服務器通常執行「被動關閉」
   3. 但 HTTP 請求中，http 頭部 connection 參數，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接

關於 Apache httpd 服務器的關聯配置，參考：https://elf8848.iteye.com/blog/1739571

關於 HTTP 請求中，設置的主動關閉 TCP 連接的機制：TIME_WAIT的是主動斷開方才會出現的，所以主動斷開方是服務端？

1. 答案是是的。在HTTP1.1協議中，有個 Connection 頭，Connection有兩個值，close和keep-alive，這個頭就相當於客戶端告訴服務端，服務端你執行完成請求之后，是關閉連接還是保持連接，保持連接就意味着在保持連接期間，只能由客戶端主動斷開連接。還有一個keep-alive的頭，設置的值就代表了服務端保持連接保持多久。
2. HTTP默認的Connection值為close，那么就意味着關閉請求的一方幾乎都會是由服務端這邊發起的。那么這個服務端產生TIME_WAIT過多的情況就很正常了。
3. 雖然HTTP默認Connection值為close，但是，現在的瀏覽器發送請求的時候一般都會設置Connection為keep-alive了。所以，也有人說，現在沒有必要通過調整參數來使TIME_WAIT降低了。

轉自http://ningg.top/computer-basic-theory-tcp-time-wait/