面試官問：大量的 TIME_WAIT 狀態(tài) TCP 連接，對業(yè)務有什么影響？怎么處理？

幾個方面：

1. 問題描述：什么現(xiàn)象？什么影響？
2. 問題分析
3. 解決方案
4. 底層原理

1.問題描述

模擬高并發(fā)的場景，會出現(xiàn)批量的?TIME_WAIT?的 TCP 連接：

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

即，在高并發(fā)的場景下，TIME_WAIT?連接存在，屬于正常現(xiàn)象。

線上場景中，持續(xù)的高并發(fā)場景

• 一部分?TIME_WAIT?連接被回收，但新的?TIME_WAIT?連接產(chǎn)生；
• 一些極端情況下，會出現(xiàn)大量的?TIME_WAIT?連接。

Think：

上述大量的?TIME_WAIT?狀態(tài) TCP 連接，有什么業(yè)務上的影響嗎？

Nginx 作為反向代理時，大量的短鏈接，可能導致 Nginx 上的 TCP 連接處于?time_wait?狀態(tài)：

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

統(tǒng)計 TCP 連接的狀態(tài)：

1. ?`//?統(tǒng)計：各種連接的數(shù)量`
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 本地端口數(shù)量，上限為?65535（6.5w），這是因為 TCP 頭部使用?16 bit，存儲「端口號」，因此約束上限為?65535。

2.問題分析

大量的?TIME_WAIT?狀態(tài) TCP 連接存在，其本質原因是什么？

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

TIME_WAIT 狀態(tài)：

• TCP 連接中，主動關閉連接的一方出現(xiàn)的狀態(tài)；（收到 FIN 命令，進入 TIME_WAIT 狀態(tài)，并返回 ACK 命令）
• 保持 2 個?MSL?時間，即，4 分鐘；（MSL 為 2 分鐘）

3.解決辦法

解決上述?time_wait?狀態(tài)大量存在，導致新連接創(chuàng)建失敗的問題，一般解決辦法：

1、客戶端，HTTP 請求的頭部，connection 設置為 keep-alive，保持存活一段時間：現(xiàn)在的瀏覽器，一般都這么進行了 2、服務器端，

• 允許?time_wait?狀態(tài)的 socket 被重用
• 縮減?time_wait?時間，設置為?1 MSL（即，2 mins）

更多細節(jié)，參考：

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

結論：幾個核心要點

1、?time_wait 狀態(tài)的影響：

• TCP 連接中，「主動發(fā)起關閉連接」的一端，會進入 time_wait 狀態(tài)
• time_wait 狀態(tài)，默認會持續(xù)?2 MSL（報文的最大生存時間），一般是 2x2 mins
• time_wait 狀態(tài)下，TCP 連接占用的端口，無法被再次使用
• TCP 端口數(shù)量，上限是 6.5w（65535，16 bit）
• 大量 time_wait 狀態(tài)存在，會導致新建 TCP 連接會出錯，address already in use : connect?異常

2、?現(xiàn)實場景：

• 服務器端，一般設置：不允許「主動關閉連接」
• 但 HTTP 請求中，http 頭部 connection 參數(shù)，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接
• 現(xiàn)在瀏覽器中， HTTP 請求?connection?參數(shù)，一般都設置為?keep-alive
• Nginx 反向代理場景中，可能出現(xiàn)大量短鏈接，服務器端，可能存在

3、?解決辦法：服務器端，

• 允許?time_wait?狀態(tài)的 socket 被重用
• 縮減?time_wait?時間，設置為?1 MSL（即，2 mins）

4.附錄

幾個方面：

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

附錄 A：查詢 TCP 連接狀態(tài)

Mac 下，查詢 TCP 連接狀態(tài)的具體命令：

1.??`//?Mac?下，查詢?TCP?連接狀態(tài)`
2.??`$?netstat?-nat?|grep?TIME_WAIT`
3.??``
4.??`//?Mac?下，查詢?TCP?連接狀態(tài)，其中?-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. ?`//?統(tǒng)計：各種連接的數(shù)量`
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. 任何報文在網(wǎng)絡上存在的最長時間，超過這個時間報文將被丟棄。（IP 報文）
2. TCP報文 （segment）是ip數(shù)據(jù)報（datagram）的數(shù)據(jù)部分。

Tips：

RFC 793中規(guī)定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。

2MSL，TCP 的?TIME_WAIT?狀態(tài)，也稱為2MSL等待狀態(tài)：

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

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

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

詳細細節(jié)，參考：

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

具體示意圖：

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

幾個核心疑問：

1、 time_wait 是「服務器端」的狀態(tài)？or 「客戶端」的狀態(tài)？

• RE：time_wait 是「主動關閉 TCP 連接」一方的狀態(tài)，可能是「客服端」的，也可能是「服務器端」的
• 一般情況下，都是「客戶端」所處的狀態(tài)；「服務器端」一般設置「不主動關閉連接」

2、 服務器在對外服務時，是「客戶端」發(fā)起的斷開連接？還是「服務器」發(fā)起的斷開連接？

• 正常情況下，都是「客戶端」發(fā)起的斷開連接
• 「服務器」一般設置為「不主動關閉連接」，服務器通常執(zhí)行「被動關閉」
• 但 HTTP 請求中，http 頭部 connection 參數(shù)，可能設置為 close，則，服務端處理完請求會主動關閉 TCP 連接

關于 Apache httpd 服務器的關聯(lián)配置，參考：https://elf8848.iteye.com/blog/1739571

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

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

關于?time_wait：

1、TCP 連接建立后，「主動關閉連接」的一端，收到對方的 FIN 請求后，發(fā)送 ACK 響應，會處于 time_wait 狀態(tài)；

2、 time_wait 狀態(tài)，存在的必要性：

• 可靠的實現(xiàn) TCP 全雙工連接的終止：四次揮手關閉 TCP 連接過程中，最后的 ACK 是由「主動關閉連接」的一端發(fā)出的，如果這個 ACK 丟失，則，對方會重發(fā) FIN 請求，因此，在「主動關閉連接」的一段，需要維護一個 time_wait 狀態(tài)，處理對方重發(fā)的 FIN 請求；
• 處理延遲到達的報文：由于路由器可能抖動，TCP 報文會延遲到達，為了避免「延遲到達的 TCP 報文」被誤認為是「新 TCP 連接」的數(shù)據(jù)，則，需要在允許新創(chuàng)建 TCP 連接之前，保持一個不可用的狀態(tài)，等待所有延遲報文的消失，一般設置為 2 倍的 MSL（報文的最大生存時間），解決「延遲達到的 TCP 報文」問題；