TIME_WAIT是什么

生產(chǎn)環(huán)境 Nginx 后端服務(wù)大量 TIME-WAIT ， 該怎么辦？

遇到這樣的生產(chǎn)環(huán)境難題，小伙伴們非常頭疼。

更為頭疼的是，這個也是一道場景的面試題。之前有小伙伴反應(yīng)過，他面試科大訊飛的時候，遇到了這道題目：

生產(chǎn)環(huán)境 Nginx 后端服務(wù)大量 TIME-WAIT 的解決步驟

這里小編給大家做一下系統(tǒng)化、體系化的梳理，使得大家可以充分展示一下大家雄厚的 “技術(shù)肌肉”，讓面試官愛到 “不能自已、口水直流”。

基礎(chǔ)知識

TIME_WAIT是什么？

在構(gòu)建TCP客戶端服務(wù)器系統(tǒng)時，很容易犯簡單的錯誤，這些錯誤會嚴(yán)重限制可伸縮性。

其中一個錯誤是沒有考慮到狀態(tài)。

為什么TIME_WAIT存在，它可能導(dǎo)致的問題，如何解決它，以及什么時候不應(yīng)該。

TIME_WAIT是 TCP 狀態(tài)轉(zhuǎn)換圖中經(jīng)常被誤解的狀態(tài)。

這是某些套接字可以進(jìn)入并保持相對較長時間的狀態(tài)，如果您有足夠的套接字，那么您創(chuàng)建新套接字連接的能力可能會受到影響，這可能會影響客戶端服務(wù)器系統(tǒng)的可伸縮性。

關(guān)于套接字如何以及為什么首先進(jìn)入TIME_WAIT，經(jīng)常存在一些誤解，不應(yīng)該有，這并不神奇。從下面的TCP狀態(tài)轉(zhuǎn)換圖中可以看出TIME_WAIT，是TCP客戶端通常最終處于的最終狀態(tài)。

雖然狀態(tài)轉(zhuǎn)換圖顯示TIME_WAIT為客戶端的最終狀態(tài)，但它不一定是客戶端TIME_WAIT。事實上，最終狀態(tài)是啟動“主動關(guān)閉”的對等端最終進(jìn)入，這可以是客戶端或服務(wù)器。那么，發(fā)布“主動關(guān)閉”是什么意思？

如果TCP對等方是第一個呼叫Close()連接的對等方，則TCP對等方會啟動“主動關(guān)閉” 。

在許多協(xié)議和客戶端/服務(wù)器設(shè)計中，這是客戶端。

在HTTP和FTP服務(wù)器中，這通常是服務(wù)器。

導(dǎo)致同伴結(jié)束的事件的實際順序TIME_WAIT如下。

現(xiàn)在我們知道套接字是如何結(jié)束TIME_WAIT的，理解為什么這個狀態(tài)存在以及它為什么會成為一個潛在的問題是有用的。

TIME_WAIT通常也被稱為2MSL等待狀態(tài)。

這是因為轉(zhuǎn)換到的套接字在此期間的持續(xù)時間TIME_WAIT為2 x最大段壽命。

MSL是任何段的最大時間量，對于構(gòu)成TCP協(xié)議一部分的數(shù)據(jù)報的所有意圖和目的而言，在丟棄之前，網(wǎng)絡(luò)可以在網(wǎng)絡(luò)上保持有效。這個時間限制最終以用于傳輸TCP段的IP數(shù)據(jù)報中的TTL字段為界。

不同的實現(xiàn)為MSL選擇不同的值，常用值為30秒，1分鐘或2分鐘。

RFC 793指定MSL為2分鐘，Windows系統(tǒng)默認(rèn)為此值，但可以使用TcpTimedWaitDelay注冊表設(shè)置進(jìn)行調(diào)整。

TIME_WAIT可能影響系統(tǒng)可伸縮性 的原因是，TCP連接中一個完全關(guān)閉的套接字將保持TIME_WAIT約4分鐘的狀態(tài)。

如果許多連接正在快速打開和關(guān)閉，那么套接字TIME_WAIT可能會開始累積在系統(tǒng)上; 您可以TIME_WAIT使用netstat查看套接字。一次可以建立有限數(shù)量的套接字連接，限制此數(shù)量的其中一個因素是可用本地端口的數(shù)量。

如果TIME_WAIT插入太多的套接字，您會發(fā)現(xiàn)很難建立新的出站連接，因為缺少可用于新連接的本地端口。

但為什么TIME_WAIT存在呢？有兩個原因需要TIME_WAIT。

首先是防止一個連接的延遲段被誤解為后續(xù)連接的一部分。丟棄在連接處于2MSL等待狀態(tài)時到達(dá)的任何段。

在上圖中，我們有兩個從終點(diǎn)1到終點(diǎn)2的連接。每個終點(diǎn)的地址和端口在每個連接中都是相同的。第一個連接終止于由端點(diǎn)2啟動的主動關(guān)閉。如果端點(diǎn)2沒有保持TIME_WAIT足夠長的時間以確保來自先前連接的所有分段已經(jīng)失效，則延遲的分段（具有適當(dāng)?shù)男蛄刑枺┛梢允钦`認(rèn)為是第二個連接的一部分...

請注意，延遲片段很可能會導(dǎo)致這樣的問題。首先，每個端點(diǎn)的地址和端口需要相同; 這通常不太可能，因為操作系統(tǒng)通常從短暫端口范圍為您選擇客戶端端口，從而在連接之間進(jìn)行更改。其次，延遲段的序列號需要在新連接中有效，這也是不太可能的。但是，如果出現(xiàn)這兩種情況，TIME_WAIT則會阻止新連接的數(shù)據(jù)被破壞。

需要TIME_WAIT第二個原因是可靠地實施TCP的全雙工連接終端。

如果ACK從終點(diǎn)2開始的終點(diǎn)被丟棄，則終點(diǎn)1將重新發(fā)送終點(diǎn)FIN。如果連接已經(jīng)過渡到CLOSED終點(diǎn)2，那么唯一可能的應(yīng)答是發(fā)送一個，RST因為重發(fā)FIN是意外的。即使所有數(shù)據(jù)傳輸正確，這也會導(dǎo)致終點(diǎn)1接收到錯誤。

不幸的是，一些操作系統(tǒng)實現(xiàn)的方式TIME_WAIT似乎有點(diǎn)幼稚。

只有TIME_WAIT通過阻塞才能提供保護(hù)的連接與需要的socket完全匹配TIME_WAIT。這意味著由客戶端地址，客戶端端口，服務(wù)器地址和服務(wù)器端口標(biāo)識的連接。但是，某些操作系統(tǒng)會施加更嚴(yán)格的限制，并且阻止本地端口號被重新使用，而該端口號包含在連接中TIME_WAIT。如果有足夠的套接字結(jié)束，TIME_WAIT則不能建立新的出站連接，因為沒有剩余本地端口分配給新連接。

Windows不會執(zhí)行此操作，只會阻止與其中的連接完全匹配的出站連接TIME_WAIT。

入站連接受影響較小TIME_WAIT。

雖然由服務(wù)器主動關(guān)閉的TIME_WAIT連接與客戶端連接完全一樣，但是服務(wù)器正在偵聽的本地端口不會阻止其成為新的入站連接的一部分。在Windows上，服務(wù)器正在監(jiān)聽的眾所周知的端口可以構(gòu)成隨后接受的連接的一部分，并且如果從遠(yuǎn)程地址和端口建立了新的連接，該連接當(dāng)前構(gòu)成TIME_WAIT該本地地址和端口的連接的一部分，則只要新序列號大于當(dāng)前連接的最終序列號，就允許連接TIME_WAIT。然而，TIME_WAIT在服務(wù)器上累積可能會影響性能和資源使用，因為TIME_WAIT最終需要超時的連接需要進(jìn)行一些工作，直到TIME_WAIT狀態(tài)結(jié)束，連接仍占用（少量）服務(wù)器資源。

鑒于TIME_WAIT由于本地端口號耗盡而影響出站連接的建立，并且這些連接通常使用由臨時端口范圍由操作系統(tǒng)自動分配的本地端口，因此您可以做的第一件事情是確保你正在使用一個體面的短暫端口范圍。在Windows上，您可以通過調(diào)整MaxUserPort注冊表設(shè)置來完成此操作。請注意，默認(rèn)情況下，許多Windows系統(tǒng)的臨時端口范圍大約為4000，這對于許多客戶端服務(wù)器系統(tǒng)來說可能太低。

雖然有可能縮短套接字在TIME_WAIT這方面的花費(fèi)時間通常不會有幫助。鑒于TIME_WAIT當(dāng)許多連接建立并且主動關(guān)閉時，這只是一個問題，調(diào)整2MSL等待周期通常會導(dǎo)致在給定時間內(nèi)建立和關(guān)閉更多連接的情況，因此必須不斷調(diào)整2MSL直到由于延遲片段似乎是后來連接的一部分，因此它可能會開始出現(xiàn)問題; 如果您連接到相同的遠(yuǎn)程地址和端口，并且非?？焖俚厥褂盟斜镜囟丝诜秶?，或者如果連接到相同的遠(yuǎn)程地址和端口并將本地端口綁定到固定值，這種情況才會變得可能。

更改2MSL延遲通常是機(jī)器范圍內(nèi)的配置更改。您可以嘗試TIME_WAIT使用SO_REUSEADDR套接字選項解決套接字級別問題。這允許在具有相同地址和端口的現(xiàn)有套接字已經(jīng)存在的同時創(chuàng)建套接字。新的套接字基本上劫持了舊的套接字。您可以使用它SO_REUSEADDR來允許創(chuàng)建套接字，同時具有相同端口的套接字已經(jīng)在其中，TIME_WAIT但這也會導(dǎo)致諸如拒絕服務(wù)攻擊或數(shù)據(jù)竊取等問題。在Windows平臺上另一套接字選項，SO_EXCLUSIVEADDRUSE可以幫助防止某些缺點(diǎn)的SO_REUSEADDR，，但在我看來，最好避免這些嘗試在各地工作TIME_WAIT，而是設(shè)計系統(tǒng)，使TIME_WAIT 不是問題。

上面的TCP狀態(tài)轉(zhuǎn)換圖都顯示有序的連接終止。還有另一種方法來終止TCP連接，這是通過中止連接并發(fā)送一個RST而不是一個FIN。這通常通過將SO_LINGER套接字選項設(shè)置為0 來實現(xiàn)。這會導(dǎo)致掛起的數(shù)據(jù)被丟棄，并且連接將被中止，RST而不是等待傳輸?shù)臄?shù)據(jù)，并且使用a清除干凈的連接FIN。重要的是要認(rèn)識到，當(dāng)連接被中止時，可能在對等體之間流動的任何數(shù)據(jù)將被丟棄，RST直接送達(dá); 通常作為表示“連接已被同級重置”的事實的錯誤。遠(yuǎn)程節(jié)點(diǎn)知道連接被中止，并且兩個節(jié)點(diǎn)都沒有進(jìn)入TIME_WAIT。

當(dāng)然，已經(jīng)中止使用的連接的新化身RST可能成為TIME_WAIT阻礙的延遲段問題的受害者，但是成為問題所需的條件是不太可能的，無論如何，參見上面的更多細(xì)節(jié)。為了防止已經(jīng)中止的連接導(dǎo)致延遲段問題，兩個對等端都必須轉(zhuǎn)換到TIME_WAIT連接關(guān)閉可能由諸如路由器之類的中介引起。但是，這不會發(fā)生，連接的兩端都會關(guān)閉。

有幾件事你可以做，以避免TIME_WAIT成為你的問題。其中一些假定您有能力更改您的客戶端和服務(wù)器之間所說的協(xié)議，但是對于自定義服務(wù)器設(shè)計，您通常會這樣做。

對于永遠(yuǎn)不會建立自己的出站連接的服務(wù)器，除了維護(hù)連接的資源和性能意義之外TIME_WAIT，您不必過分擔(dān)心。

對于確實建立出站連接并接受入站連接的服務(wù)器，黃金法則是始終確保如果TIME_WAIT需要發(fā)生這種情況，則它會在另一個對等而不是服務(wù)器上結(jié)束。做到這一點(diǎn)的最佳方式是永遠(yuǎn)不要從服務(wù)器發(fā)起主動關(guān)閉，無論原因是什么。如果您的對等方超時，則以中止連接RST而不是關(guān)閉連接。如果你的對方發(fā)送無效數(shù)據(jù)，中止連接等等。

這個想法是，如果你的服務(wù)器永遠(yuǎn)不會啟動一個主動關(guān)閉，它永遠(yuǎn)不會累積TIME_WAIT套接字，因此永遠(yuǎn)不會受到它們導(dǎo)致的可伸縮性問題的困擾。雖然在出現(xiàn)錯誤情況時很容易看到如何中止連接，但正常連接終止的情況如何？理想情況下，您應(yīng)該為協(xié)議設(shè)計一種方式，讓服務(wù)器告訴客戶端它應(yīng)該斷開連接，而不是簡單地讓服務(wù)器發(fā)起主動關(guān)閉。因此，如果服務(wù)器需要終止連接，服務(wù)器會發(fā)送一個應(yīng)用程序級別“我們已經(jīng)完成”的消息，客戶將此消息作為關(guān)閉連接的原因。如果客戶端未能在合理的時間內(nèi)關(guān)閉連接，則服務(wù)器會中止連接。

在客戶端上，事情稍微復(fù)雜一些，畢竟，有人必須發(fā)起一個主動關(guān)閉來干凈地終止TCP連接，并且如果它是客戶端，那么這就是TIME_WAIT最終會結(jié)束的地方。然而，TIME_WAIT最終在客戶端有幾個優(yōu)點(diǎn)。

首先，如果由于某種原因，客戶端由于套接字在TIME_WAIT一個客戶端中的積累而最終導(dǎo)致連接問題。其他客戶不會受到影響。

其次，快速打開和關(guān)閉TCP連接到同一臺服務(wù)器是沒有效率的，因此超出了問題的意義TIME_WAIT嘗試維持更長時間的連接而不是更短的時間。不要設(shè)計一個協(xié)議，客戶端每分鐘連接一次，并打開一個新的連接。而是使用持久連接設(shè)計，并且只有在連接失敗時才重新連接，如果中間路由器拒絕在沒有數(shù)據(jù)流的情況下保持連接處于打開狀態(tài)，則可以實現(xiàn)應(yīng)用程序級別ping，使用TCP保持活動狀態(tài)或僅接受路由器重置連接; 好處是你沒有積累TIME_WAIT插座。如果你在連接上做的工作自然是短暫的，那么考慮某種形式的“連接池”設(shè)計，從而保持連接的開放性和重用性。

最后，如果您絕對必須快速地從客戶端打開和關(guān)閉連接到同一臺服務(wù)器，那么也許您可以設(shè)計一個可以使用的應(yīng)用程序級別關(guān)閉順序，然后按照此順序關(guān)閉。您的客戶可能會發(fā)送“我完成了”消息，您的服務(wù)器可能會發(fā)送“再見”消息，然后客戶端可能會中止連接。

TIME_WAIT存在原因并通過縮短2MSL周期或允許地址重用來解決這個問題SO_REUSEADDR并不總是一個好主意。

如果你能夠設(shè)計你的協(xié)議TIME_WAIT避免在腦海中，那么你通?？梢酝耆苊膺@個問題。

TIME_WAIT的4種查詢方式

1、netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

2、ss -s

3、netstat -nat |awk '{print $6}'|sort|uniq -c|sort -rn

4、 統(tǒng)計 TIME_WAIT 連接的本地地址

netstat -an | grep TIME_WAIT | awk '{print $4}' | sort | uniq -c | sort -n -k1

嘗試抓取 tcp 包

系統(tǒng)參數(shù)優(yōu)化

處理方法：需要修改內(nèi)核參數(shù)開啟重啟：

具體操作方法如下：

sysctl -p;

nginx 配置優(yōu)化

當(dāng)使用nginx作為反向代理時，為了支持長連接，需要做到兩點(diǎn)：

1. 從client到nginx的連接是長連接
2. 從nginx到server的連接是長連接

保持和client的長連接：

keepalive_timeout設(shè)置

語法

第一個參數(shù)：設(shè)置keep-alive客戶端(瀏覽器)連接在服務(wù)器端(nginx端)保持開啟的超時值（默認(rèn)75s）；值為0會禁用keep-alive客戶端連接；

第二個參數(shù)：可選、在響應(yīng)的header域中設(shè)置一個值“Keep-Alive: timeout=time”；通?？梢圆挥迷O(shè)置；

這個keepalive_timeout針對的是瀏覽器和nginx建立的一個tcp通道，沒有數(shù)據(jù)傳輸時最長等待該時候后就關(guān)閉.

nginx和upstream中的keepalive_timeout則受到tomcat連接器的控制，tomcat中也有一個類似的keepalive_timeout參數(shù)

keepalive_requests理解設(shè)置

keepalive_requests指令用于設(shè)置一個keep-alive連接上可以服務(wù)的請求的最大數(shù)量，當(dāng)最大請求數(shù)量達(dá)到時，連接被關(guān)閉。默認(rèn)是100。

這個參數(shù)的真實含義，是指一個keep alive建立之后，nginx就會為這個連接設(shè)置一個計數(shù)器，記錄這個keep alive的長連接上已經(jīng)接收并處理的客戶端請求的數(shù)量。如果達(dá)到這個參數(shù)設(shè)置的最大值時，則nginx會強(qiáng)行關(guān)閉這個長連接，逼迫客戶端不得不重新建立新的長連接。

保持和server的長連接

為了讓nginx和后端server（nginx稱為upstream）之間保持長連接，典型設(shè)置如下：（默認(rèn)nginx訪問后端都是用的短連接(HTTP1.0)，一個請求來了，Nginx 新開一個端口和后端建立連接，后端執(zhí)行完畢后主動關(guān)閉該鏈接）

HTTP協(xié)議中對長連接的支持是從1.1版本之后才有的，因此最好通過proxy_http_version指令設(shè)置為”1.1”；

從client過來的http header，因為即使是client和nginx之間是短連接，nginx和upstream之間也是可以開啟長連接的。

keepalive理解設(shè)置

此處keepalive的含義不是開啟、關(guān)閉長連接的開關(guān)；也不是用來設(shè)置超時的timeout；更不是設(shè)置長連接池最大連接數(shù)。官方解釋：

1. The connections parameter sets the maximum number of idle keepalive connections to upstream servers connections（設(shè)置到upstream服務(wù)器的空閑keepalive連接的最大數(shù)量）
2. When this number is exceeded, the least recently used connections are closed. （當(dāng)這個數(shù)量被突破時，最近使用最少的連接將被關(guān)閉）
3. It should be particularly noted that the keepalive directive does not limit the total number of connections to upstream servers that an nginx worker process can open.（特別提醒：keepalive指令不會限制一個nginx worker進(jìn)程到upstream服務(wù)器連接的總數(shù)量）

總結(jié)：

keepalive 這個參數(shù)一定要小心設(shè)置，尤其對于QPS比較高的場景，推薦先做一下估算，根據(jù)QPS和平均響應(yīng)時間大體能計算出需要的長連接的數(shù)量。

比如前面10000 QPS和100毫秒響應(yīng)時間就可以推算出需要的長連接數(shù)量大概是1000. 然后將keepalive設(shè)置為這個長連接數(shù)量的10%到30%。比較懶的同學(xué)，可以直接設(shè)置為keepalive=1000之類的，一般都OK的了。

綜上，出現(xiàn)大量TIME_WAIT的情況

1）導(dǎo)致 nginx端出現(xiàn)大量TIME_WAIT的情況有兩種：

keepalive_requests設(shè)置比較小，高并發(fā)下超過此值后nginx會強(qiáng)制關(guān)閉和客戶端保持的keepalive長連接；（主動關(guān)閉連接后導(dǎo)致nginx出現(xiàn)TIME_WAIT）

keepalive設(shè)置的比較?。臻e數(shù)太?。?，導(dǎo)致高并發(fā)下nginx會頻繁出現(xiàn)連接數(shù)震蕩（超過該值會關(guān)閉連接），不停的關(guān)閉、開啟和后端server保持的keepalive長連接；

2）導(dǎo)致后端server端出現(xiàn)大量TIME_WAIT的情況：

nginx沒有打開和后端的長連接，即：沒有設(shè)置proxy_http_version 1.1;和proxy_set_header Connection “”;從而導(dǎo)致后端server每次關(guān)閉連接，高并發(fā)下就會出現(xiàn)server端出現(xiàn)大量TIME_WAIT