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

程序員的成長之路

互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享?

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

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

1.問題描述

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

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

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

//?統(tǒng)計(jì)：各種連接的數(shù)量
$?netstat?-n?|?awk?'/^tcp/?{++S[$NF]}?END?{for(a?in?S)?print?a,?S[a]}'
ESTABLISHED?1154
TIME_WAIT?1645

TCP 本地端口數(shù)量，上限為?65535（6.5w），這是因?yàn)?TCP 頭部使用?16 bit，存儲(chǔ)「端口號(hào)」，因此約束上限為?65535。另外，TCP 系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺(tái)發(fā)送：面試，可以在線閱讀。

2.問題分析

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

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

3.解決辦法

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

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

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

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

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

4.附錄

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

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

//?Mac?下，查詢?TCP?連接狀態(tài)
$?netstat?-nat?|grep?TIME_WAIT

//?Mac?下，查詢?TCP?連接狀態(tài)，其中?-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

//?統(tǒng)計(jì)：各種連接的數(shù)量
`$?netstat?-n?|?awk?'/^tcp/?{++S[$NF]}?END?{for(a?in?S)?print?a,?S[a]}'
`ESTABLISHED?1154
`TIME_WAIT?1645

附錄 B：MSL 時(shí)間

1. 任何報(bào)文在網(wǎng)絡(luò)上存在的最長時(shí)間，超過這個(gè)時(shí)間報(bào)文將被丟棄。（IP 報(bào)文）
2. TCP報(bào)文 （segment）是ip數(shù)據(jù)報(bào)（datagram）的數(shù)據(jù)部分。

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

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

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

• TCP的三次握手與四次揮手（詳解+動(dòng)圖）

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

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

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

https://elf8848.iteye.com/blog/1739571

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

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

推薦閱讀：

浙大讀博八年現(xiàn)靠送外賣賺錢，本人：進(jìn)組以來博士無一人按時(shí)畢業(yè)

為什么數(shù)據(jù)庫連接很消耗資源？

內(nèi)容包含Java基礎(chǔ)、JavaWeb、MySQL性能優(yōu)化、JVM、鎖、百萬并發(fā)、消息隊(duì)列、高性能緩存、反射、Spring全家桶原理、微服務(wù)、Zookeeper......等技術(shù)棧！

?戳閱讀原文領(lǐng)取！? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??朕已閱?