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

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

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

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

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

基礎(chǔ)知識(shí)

TIME_WAIT是什么？

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

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

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

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

這是某些套接字可以進(jìn)入并保持相對(duì)較長(zhǎng)時(shí)間的狀態(tài)，如果您有足夠的套接字，那么您創(chuàng)建新套接字連接的能力可能會(huì)受到影響，這可能會(huì)影響客戶端服務(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。事實(shí)上，最終狀態(tài)是啟動(dòng)“主動(dòng)關(guān)閉”的對(duì)等端最終進(jìn)入，這可以是客戶端或服務(wù)器。那么，發(fā)布“主動(dòng)關(guān)閉”是什么意思？

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

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

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

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

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

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

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

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

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

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

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

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

如果TIME_WAIT插入太多的套接字，您會(huì)發(fā)現(xiàn)很難建立新的出站連接，因?yàn)槿鄙倏捎糜谛逻B接的本地端口。

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

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

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

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

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

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

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

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

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

入站連接受影響較小TIME_WAIT。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你能夠設(shè)計(jì)你的協(xié)議TIME_WAIT避免在腦海中，那么你通常可以完全避免這個(gè)問題。

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)計(jì) 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作為反向代理時(shí)，為了支持長(zhǎng)連接，需要做到兩點(diǎn)：

1. 從client到nginx的連接是長(zhǎng)連接
2. 從nginx到server的連接是長(zhǎng)連接

保持和client的長(zhǎng)連接：

keepalive_timeout設(shè)置

語法

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

第二個(gè)參數(shù)：可選、在響應(yīng)的header域中設(shè)置一個(gè)值“Keep-Alive: timeout=time”；通常可以不用設(shè)置；

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

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

keepalive_requests理解設(shè)置

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

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

保持和server的長(zhǎng)連接

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

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

從client過來的http header，因?yàn)榧词故莄lient和nginx之間是短連接，nginx和upstream之間也是可以開啟長(zhǎng)連接的。

keepalive理解設(shè)置

此處keepalive的含義不是開啟、關(guān)閉長(zhǎng)連接的開關(guān)；也不是用來設(shè)置超時(shí)的timeout；更不是設(shè)置長(zhǎng)連接池最大連接數(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)這個(gè)數(shù)量被突破時(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指令不會(huì)限制一個(gè)nginx worker進(jìn)程到upstream服務(wù)器連接的總數(shù)量）

總結(jié)：

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

比如前面10000 QPS和100毫秒響應(yīng)時(shí)間就可以推算出需要的長(zhǎng)連接數(shù)量大概是1000. 然后將keepalive設(shè)置為這個(gè)長(zhǎng)連接數(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會(huì)強(qiáng)制關(guān)閉和客戶端保持的keepalive長(zhǎng)連接；（主動(dòng)關(guān)閉連接后導(dǎo)致nginx出現(xiàn)TIME_WAIT）

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

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

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