寫在開頭,大概 4 年前,聽到運(yùn)維同學(xué)提到 TIME_WAIT 狀態(tài)的 TCP 連接過多的問題,但是當(dāng)時沒有去細(xì)琢磨;最近又聽人說起,是一個新手進(jìn)行壓測過程中,遇到的問題,因此,花點(diǎn)時間,細(xì)深究一下。
從這幾個方面著手:
問題描述:什么現(xiàn)象?什么影響?
問題分析
解決方案
底層原理
1、問題描述
模擬高并發(fā)的場景,會出現(xiàn)批量的 TIME_WAIT 的 TCP 連接:
短時間后,所有的 TIME_WAIT 全都消失,被回收,端口包括服務(wù),均正常。即,在高并發(fā)的場景下,TIME_WAIT 連接存在,屬于正?,F(xiàn)象。
線上場景中,持續(xù)的高并發(fā)場景:
一部分 TIME_WAIT 連接被回收,但新的 TIME_WAIT 連接產(chǎn)生;
一些極端情況下,會出現(xiàn)大量的 TIME_WAIT 連接。
Think:上述大量的 TIME_WAIT 狀態(tài) TCP 連接,有什么業(yè)務(wù)上的影響嗎?
Nginx 作為反向代理時,大量的短鏈接,可能導(dǎo)致 Nginx 上的 TCP 連接處于 time_wait 狀態(tài):
1.每一個 time_wait 狀態(tài),都會占用一個「本地端口」,上限為 65535(16 bit,2 Byte);
2.當(dāng)大量的連接處于 time_wait 時,新建立 TCP 連接會出錯,address already in use : connect 異常
統(tǒng)計(jì) TCP 連接的狀態(tài):
//統(tǒng)計(jì):各種連接的數(shù)量
$netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'
ESTABLISHED1154
TIME_WAIT1645
Tips:TCP 本地端口數(shù)量,上限為 65535(6.5w),這是因?yàn)?TCP 頭部使用 16 bit,存儲「端口號」,因此約束上限為 65535。
2、問題分析
大量的 TIME_WAIT 狀態(tài) TCP 連接存在,其本質(zhì)原因是什么?
1.大量的短連接存在
2.特別是 HTTP 請求中,如果 connection 頭部取值被設(shè)置為 close 時,基本都由「服務(wù)端」發(fā)起主動關(guān)閉連接
3.而,TCP 四次揮手關(guān)閉連接機(jī)制中,為了保證 ACK 重發(fā)和丟棄延遲數(shù)據(jù),設(shè)置 time_wait 為 2 倍的 MSL(報文最大存活時間)
TIME_WAIT 狀態(tài):
1.TCP 連接中,主動關(guān)閉連接的一方出現(xiàn)的狀態(tài);(收到 FIN 命令,進(jìn)入 TIME_WAIT 狀態(tài),并返回 ACK 命令)
2.保持 2 個 MSL 時間,即,4 分鐘;(MSL 為 2 分鐘)
3、解決辦法
解決上述 time_wait 狀態(tài)大量存在,導(dǎo)致新連接創(chuàng)建失敗的問題,一般解決辦法:
1.客戶端,HTTP 請求的頭部,connection 設(shè)置為 keep-alive,保持存活一段時間:現(xiàn)在的瀏覽器,一般都這么進(jìn)行了
2.服務(wù)器端允許 time_wait 狀態(tài)的 socket 被重用縮減 time_wait 時間,設(shè)置為 1 MSL(即,2 mins)
結(jié)論:幾個核心要點(diǎn)
1.time_wait 狀態(tài)的影響:
TCP 連接中,「主動發(fā)起關(guān)閉連接」的一端,會進(jìn)入 time_wait 狀態(tài)
time_wait 狀態(tài),默認(rèn)會持續(xù) 2 MSL(報文的最大生存時間),一般是 2x2 mins
time_wait 狀態(tài)下,TCP 連接占用的端口,無法被再次使用
TCP 端口數(shù)量,上限是 6.5w(65535,16 bit)
大量 time_wait 狀態(tài)存在,會導(dǎo)致新建 TCP 連接會出錯,address already in use : connect 異常
2.現(xiàn)實(shí)場景:
服務(wù)器端,一般設(shè)置:不允許「主動關(guān)閉連接」
但 HTTP 請求中,http 頭部 connection 參數(shù),可能設(shè)置為 close,則,服務(wù)端處理完請求會主動關(guān)閉 TCP 連接
現(xiàn)在瀏覽器中, HTTP 請求 connection 參數(shù),一般都設(shè)置為 keep-alive
Nginx 反向代理場景中,可能出現(xiàn)大量短鏈接,服務(wù)器端,可能存在
3.解決辦法:
服務(wù)器端允許 time_wait 狀態(tài)的 socket 被重用
縮減 time_wait 時間,設(shè)置為 1 MSL(即,2 mins)
4、附錄 - 底層原理
幾個方面:
1.TCP 連接狀態(tài)的查詢
2.MSL 時間
3.TCP 三次握手和四次握手
附錄 A:查詢 TCP 連接狀態(tài)
Mac 下,查詢 TCP 連接狀態(tài)的具體命令:
//Mac下,查詢TCP連接狀態(tài)
$netstat-nat|grepTIME_WAIT
//Mac下,查詢TCP連接狀態(tài),其中-E表示grep或的匹配邏輯
$netstat-nat|grep-E"TIME_WAIT|LocalAddress"
ProtoRecv-QSend-QLocalAddressForeignAddress(state)
tcp400127.0.0.1.1080127.0.0.1.59061TIME_WAIT
//統(tǒng)計(jì):各種連接的數(shù)量
$netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'
ESTABLISHED1154
TIME_WAIT1645
附錄 B:MSL 時間MSL,Maximum Segment Lifetime,“報文最大生存時間”
1.任何報文在網(wǎng)絡(luò)上存在的最長時間,超過這個時間報文將被丟棄。(IP 報文)
2.TCP報文 (segment)是ip數(shù)據(jù)報(datagram)的數(shù)據(jù)部分。
Tips:RFC 793中規(guī)定MSL為2分鐘,實(shí)際應(yīng)用中常用的是30秒,1分鐘和2分鐘等。
2MSL,TCP 的 TIME_WAIT 狀態(tài),也稱為2MSL等待狀態(tài):
1.當(dāng)TCP的一端發(fā)起主動關(guān)閉(收到 FIN 請求),在發(fā)出最后一個ACK 響應(yīng)后,即第3次握 手完成后,發(fā)送了第四次握手的ACK包后,就進(jìn)入了TIME_WAIT狀態(tài)。
2.必須在此狀態(tài)上停留兩倍的MSL時間,等待2MSL時間主要目的是怕最后一個 ACK包對方?jīng)]收到,那么對方在超時后將重發(fā)第三次握手的FIN包,主動關(guān)閉端接到重發(fā)的FIN包后,可以再發(fā)一個ACK應(yīng)答包。
3.在 TIME_WAIT 狀態(tài)時,兩端的端口不能使用,要等到2MSL時間結(jié)束,才可繼續(xù)使用。(IP 層)
4.當(dāng)連接處于2MSL等待階段時,任何遲到的報文段都將被丟棄。
不過在實(shí)際應(yīng)用中,可以通過設(shè)置 「SO_REUSEADDR選項(xiàng)」,達(dá)到不必等待2MSL時間結(jié)束,即可使用被占用的端口。
附錄 C:TCP 三次握手和四次握手
具體示意圖:
1.三次握手,建立連接過程
2.四次揮手,釋放連接過程
幾個核心疑問:
1.time_wait 是「服務(wù)器端」的狀態(tài)?or 「客戶端」的狀態(tài)?
RE:time_wait 是「主動關(guān)閉 TCP 連接」一方的狀態(tài),可能是「客服端」的,也可能是「服務(wù)器端」的;
一般情況下,都是「客戶端」所處的狀態(tài);「服務(wù)器端」一般設(shè)置「不主動關(guān)閉連接」。
2.服務(wù)器在對外服務(wù)時,是「客戶端」發(fā)起的斷開連接?還是「服務(wù)器」發(fā)起的斷開連接?
正常情況下,都是「客戶端」發(fā)起的斷開連接;
「服務(wù)器」一般設(shè)置為「不主動關(guān)閉連接」,服務(wù)器通常執(zhí)行「被動關(guān)閉」;
但 HTTP 請求中,http 頭部 connection 參數(shù),可能設(shè)置為 close,則,服務(wù)端處理完請求會主動關(guān)閉 TCP 連接,
關(guān)于 HTTP 請求中,設(shè)置的主動關(guān)閉 TCP 連接的機(jī)制:TIME_WAIT的是主動斷開方才會出現(xiàn)的,所以主動斷開方是服務(wù)端?
1.答案是是的。在HTTP1.1協(xié)議中,有個 Connection 頭,Connection有兩個值,close和keep-alive,這個頭就相當(dāng)于客戶端告訴服務(wù)端,服務(wù)端你執(zhí)行完成請求之后,是關(guān)閉連接還是保持連接,保持連接就意味著在保持連接期間,只能由客戶端主動斷開連接。還有一個keep-alive的頭,設(shè)置的值就代表了服務(wù)端保持連接保持多久。
2.HTTP默認(rèn)的Connection值為close,那么就意味著關(guān)閉請求的一方幾乎都會是由服務(wù)端這邊發(fā)起的。那么這個服務(wù)端產(chǎn)生TIME_WAIT過多的情況就很正常了。
3.雖然HTTP默認(rèn)Connection值為close,但是,現(xiàn)在的瀏覽器發(fā)送請求的時候一般都會設(shè)置Connection為keep-alive了。所以,也有人說,現(xiàn)在沒有必要通過調(diào)整參數(shù)來使TIME_WAIT降低了。
關(guān)于 time_wait:
1.TCP 連接建立后,「主動關(guān)閉連接」的一端,收到對方的 FIN 請求后,發(fā)送 ACK 響應(yīng),會處于 time_wait 狀態(tài);
2.time_wait 狀態(tài),存在的必要性:
a、 可靠的實(shí)現(xiàn) TCP 全雙工連接的終止:四次揮手關(guān)閉 TCP 連接過程中,最后的 ACK 是由「主動關(guān)閉連接」的一端發(fā)出的,如果這個 ACK 丟失,則,對方會重發(fā) FIN 請求,因此,在「主動關(guān)閉連接」的一段,需要維護(hù)一個 time_wait 狀態(tài),處理對方重發(fā)的 FIN 請求;
b、 處理延遲到達(dá)的報文:由于路由器可能抖動,TCP 報文會延遲到達(dá),為了避免「延遲到達(dá)的 TCP 報文」被誤認(rèn)為是「新 TCP 連接」的數(shù)據(jù),則,需要在允許新創(chuàng)建 TCP 連接之前,保持一個不可用的狀態(tài),等待所有延遲報文的消失,一般設(shè)置為 2 倍的 MSL(報文的最大生存時間),解決「延遲達(dá)到的 TCP 報文」問題。
-
服務(wù)器
+關(guān)注
關(guān)注
12文章
8701瀏覽量
84568 -
HTTP
+關(guān)注
關(guān)注
0文章
478瀏覽量
30770 -
TCP
+關(guān)注
關(guān)注
8文章
1324瀏覽量
78759
原文標(biāo)題:終于搞懂了服務(wù)器為啥產(chǎn)生大量的TIME_WAIT!
文章出處:【微信號:magedu-Linux,微信公眾號:馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論