乾貨分享！服務端 TCP 鏈接的 TIME_WAIT 問題分析與解決

做者：NingG
ningg.top/computer-basic-theory-tcp-time-wait/

寫在開頭，大概 4 年前，聽到運維同窗提到 TIME_WAIT 狀態的 TCP 鏈接過多的問題，可是當時沒有去細琢磨；最近又聽人提及，是一個新手進行壓測過程當中，遇到的問題，所以，花點時間，細深究一下。

問題描述

模擬高併發的場景，會出現批量的 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 鏈接的狀態：

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

Tips：TCP 本地端口數量，上限爲 65535（6.5w），這是由於 TCP 頭部使用 16 bit，存儲「端口號」，所以約束上限爲 65535。

問題分析

大量的 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 分鐘）

解決辦法

解決上述 time_wait 狀態大量存在，致使新鏈接建立失敗的問題，通常解決辦法：

1.客戶端，HTTP 請求的頭部，connection 設置爲 keep-alive，保持存活一段時間：如今的瀏覽器，通常都這麼進行了

2.服務器端

容許 time_wait 狀態的 socket 被重用

縮減 time_wait 時間，設置爲 1 MSL（即，2 mins）

結論：幾個核心要點

1.time_wait 狀態的影響：

• TCP 鏈接中，「主動發起關閉鏈接」的一端，會進入 time_wait 狀態
• time_wait 狀態，默認會持續 2 MSL（報文的最大生存時間），通常是 2x2 mins
• time_wait 狀態下，TCP 鏈接佔用的端口，沒法被再次使用
• TCP 端口數量，上限是 6.5w（65535，16 bit）
• 大量 time_wait 狀態存在，會致使新建 TCP 鏈接會出錯，address already in use : connect 異常

2.現實場景：

• 服務器端，通常設置：不容許「主動關閉鏈接」
• 但 HTTP 請求中，http 頭部 connection 參數，可能設置爲 close，則，服務端處理完請求會主動關閉 TCP 鏈接
• 如今瀏覽器中， HTTP 請求 connection 參數，通常都設置爲 keep-alive
• Nginx 反向代理場景中，可能出現大量短連接，服務器端，可能存在

3.解決辦法：

• 服務器端容許 time_wait 狀態的 socket 被重用
• 縮減 time_wait 時間，設置爲 1 MSL（即，2 mins）

附錄

幾個方面：

1.TCP 鏈接狀態的查詢

2.MSL 時間

3.TCP 三次握手和四次握手

附錄 A：查詢 TCP 鏈接狀態

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

// Mac 下，查詢 TCP 鏈接狀態
$ netstat -nat |grep TIME_WAIT

// Mac 下，查詢 TCP 鏈接狀態，其中 -E 表示 grep 或的匹配邏輯
$ netstat -nat | grep -E "TIME_WAIT|Local Address"
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 127.0.0.1.1080 127.0.0.1.59061 TIME_WAIT

// 統計：各類鏈接的數量
$ netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 1154
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等待狀態：

• 當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 三次握手和四次握手

具體示意圖：

1.三次握手，創建鏈接過程

2.四次揮手，釋放鏈接過程

幾個核心疑問：

1.time_wait 是「服務器端」的狀態？or 「客戶端」的狀態？

• RE：time_wait 是「主動關閉 TCP 鏈接」一方的狀態，多是「客服端」的，也多是「服務器端」的
• 通常狀況下，都是「客戶端」所處的狀態；「服務器端」通常設置「不主動關閉鏈接」

2.服務器在對外服務時，是「客戶端」發起的斷開鏈接？仍是「服務器」發起的斷開鏈接？

• 正常狀況下，都是「客戶端」發起的斷開鏈接
• 「服務器」通常設置爲「不主動關閉鏈接」，服務器一般執行「被動關閉」
• 但 HTTP 請求中，http 頭部 connection 參數，可能設置爲 close，則，服務端處理完請求會主動關閉 TCP 鏈接

關於 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下降了。

關於 time_wait：

1.TCP 鏈接創建後，「主動關閉鏈接」的一端，收到對方的 FIN 請求後，發送 ACK 響應，會處於 time_wait 狀態；

2.time_wait 狀態，存在的必要性：

a、可靠的實現 TCP 全雙工鏈接的終止：四次揮手關閉 TCP 鏈接過程當中，最後的 ACK 是由「主動關閉鏈接」的一端發出的，若是這個 ACK 丟失，則，對方會重發 FIN 請求，所以，在「主動關閉鏈接」的一段，須要維護一個 time_wait 狀態，處理對方重發的 FIN 請求；

b、處理延遲到達的報文：因爲路由器可能抖動，TCP 報文會延遲到達，爲了不「延遲到達的 TCP 報文」被誤認爲是「新 TCP 鏈接」的數據，則，須要在容許新建立 TCP 鏈接以前，保持一個不可用的狀態，等待全部延遲報文的消失，通常設置爲 2 倍的 MSL（報文的最大生存時間），解決「延遲達到的 TCP 報文」問題；

若有錯誤或其它問題，歡迎小夥伴留言評論、指正。若有幫助，歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號：民工哥技術之路