time_wait狀態產生的原因，危害，如何避免

0.請說說你對TCP連接中time_wait狀態的理解?

解答：

先上TCP的狀態變遷圖

上面這個圖片展示了TCP從連接建立到連接釋放的過程中，客戶端和服務端的狀態變化圖。如果只看連接釋放階段，四次握手

·????????客戶端先發送FIN，進入FIN_WAIT1狀態

·????????服務端收到FIN，發送ACK，進入CLOSE_WAIT狀態，客戶端收到這個ACK，進入FIN_WAIT2狀態

·????????服務端發送FIN，進入LAST_ACK狀態

·????????客戶端收到FIN，發送ACK，進入TIME_WAIT狀態，服務端收到ACK，進入CLOSE狀態

·????????客戶端TIME_WAIT持續2倍MSL時長，在linux體系中大概是60s，轉換成CLOSE狀態

當然在這個例子和上面的圖片中，使用客戶端和服務端來描述是不準確的，TCP主動斷開連接的一方可能是客戶端，也可能是服務端。所以使用主動斷開的一方，和被動斷開的一方替換上面的圖可能更為貼切。

不管怎么說，TIME_WAIT的狀態就是主動斷開的一方，發送完最后一次ACK之后進入的狀態。并且持續時間還挺長的。

0.能不能發送完ACK之后不進入TIME_WAIT就直接進入CLOSE狀態呢？

不行的，這個是為了TCP協議的可靠性，由于網絡原因，ACK可能會發送失敗，那么這個時候，被動一方會主動重新發送一次FIN，這個時候如果主動方在TIME_WAIT狀態，則還會再發送一次ACK，從而保證可靠性。那么從這個解釋來說，2MSL的時長設定是可以理解的，MSL是報文最大生存時間，如果重新發送，一個FIN＋一個ACK，再加上不定期的延遲時間，大致是在2MSL的范圍。

所以從理論上說，網上調試參數降低TIME_WAIT的持續時間的方法是一種以可靠性換取性能的一種方式。嗯，質量守恒定理還是鐵律。

?

1. time_wait狀態如何產生？?

由上面的變遷圖，首先調用close()發起主動關閉的一方，在發送最后一個ACK之后會進入time_wait的狀態，也就說該發送方會保持2MSL時間之后才會回到初始狀態。MSL的值是數據包在網絡中的最大生存時間。產生這種結果使得這個TCP連接在2MSL連接等待期間，定義這個連接的四元組（客戶端IP地址和端口，服務端IP地址和端口號）不能被使用。（IP:PORT already inuse）

2.time_wait狀態產生的原因？

1）為實現TCP全雙工連接的可靠釋放

由TCP狀態變遷圖可知，假設發起主動關閉的一方（client）最后發送的ACK在網絡中丟失，由于TCP協議的重傳機制，執行被動關閉的一方（server）將會重發其FIN，在該FIN到達client之前，client必須維護這條連接狀態，也就說這條TCP連接所對應的資源（client方的local_ip,local_port）不能被立即釋放或重新分配，直到另一方重發的FIN達到之后，client重發ACK后，經過2MSL時間周期沒有再收到另一方的FIN之后，該TCP連接才能恢復初始的CLOSED狀態。

如果主動關閉一方不維護這樣一個TIME_WAIT狀態，那么當被動關閉一方重發的FIN到達時，主動關閉一方的TCP傳輸層會用RST包響應對方，這會被對方認為是有錯誤發生，然而這事實上只是正常的關閉連接過程，并非異常。

2）為使舊的數據包在網絡因過期而消失

為說明這個問題，我們先假設TCP協議中不存在TIME_WAIT狀態的限制，再假設當前有一條TCP連接：(local_ip, local_port,remote_ip,remote_port)，因某些原因，我們先關閉，接著很快以相同的四元組建立一條新連接。本文前面介紹過，TCP連接由四元組唯一標識，因此，在我們假設的情況中，TCP協議棧是無法區分前后兩條TCP連接的不同的，在它看來，這根本就是同一條連接，中間先釋放再建立的過程對其來說是“感知”不到的。這樣就可能發生這樣的情況：

前一條TCP連接由local peer發送的數據到達remote peer后，會被該remot peer的TCP傳輸層當做當前TCP連接的正常數據接收并向上傳遞至應用層（而事實上，在我們假設的場景下，這些舊數據到達remote peer前，舊連接已斷開且一條由相同四元組構成的新TCP連接已建立，因此，這些舊數據是不應該被向上傳遞至應用層的），從而引起數據錯亂進而導致各種無法預知的詭異現象。作為一種可靠的傳輸協議，TCP必須在協議層面考慮并避免這種情況的發生，這正是TIME_WAIT狀態存在的第2個原因。

設置2MSL使得A到B的舊連接發送的包失效（因為最大存活時間MSL），同時即使B回復了A的包，那也已經失效了

3）總結?

具體而言，local peer主動調用close后，此時的TCP連接進入TIME_WAIT狀態，處于該狀態下的TCP連接不能立即以同樣的四元組建立新連接，即發起active close的那方占用的local port在TIME_WAIT期間不能再被重新分配。由于TIME_WAIT狀態持續時間為2MSL，這樣保證了舊TCP連接雙工鏈路中的舊數據包均因過期（超過MSL）而消失，此后，就可以用相同的四元組建立一條新連接而不會發生前后兩次連接數據錯亂的情況。

?

1.防止上一次連接中的包，迷路后重新出現，影響新連接（經過2MSL，上一次連接中所有的重復包都會消失）
2. 可靠的關閉TCP連接。在主動關閉方發送的最后一個 ack(fin) ，有可能丟失，這時被動方會重新發fin, 如果這時主動方處于 CLOSED 狀態，就會響應 rst 而不是 ack。所以主動方要處于 TIME_WAIT 狀態，而不能是 CLOSED 。另外這么設計TIME_WAIT 會定時的回收資源，并不會占用很大資源的，除非短時間內接受大量請求或者受到攻擊。

4.什么情況下會出現大量的time_wait狀態?

????????由于主動關閉TCP連接的一方才會進入TIME_WAIT狀態，一般情況服務器端不會出現TIME_WAIT狀態，因為大多數情況都是客戶端主動發起連接并主動關閉連接。但是某些服務如pop/smtp、ftp卻是服務端收到客戶端的QUIT命令后主動關閉連接，這就造成這類服務器上容易出現大量的TIME_WAIT狀態的連接，而且并發量越大處于此種狀態的連接越多。另外，對于被動關閉連接的服務在主動關閉客戶端非法請求或清理長時間不活動的連接時（這種情況很可能是客戶端程序忘記關閉連接）也會出現TIME_WAIT的狀態。(簡而言之，主動關閉連接一端會出現大量的TIME_WAIT狀態)

5.什么情況下服務器會進行主動關閉的情況？

1）短連接的方式。如http服務器。

這確實是歷史包袱。原因很簡單，早先客戶端處理HTTP是單線程的、阻塞的，服務器端發送完信息后客戶端要一直等到信息處理完畢、渲染完畢，才能有處理能力來通知服務器處理完成。在當時這個過程可以長達數分鐘，而且當時服務器沒有能力去承載這么多等待響應的連接（可以用Erlang計算一下這個延遲下需要滿足%99.9的可用性需要多么恐怖的硬件）。

所以解決方案就是服務器發送完之后就關閉連接，表明數據已經發送完成。等客戶端接收到了所有信息，處理完畢，一看連接也關掉了，此時服務器早已在處理其他連接了。

另外這也是為什么有大量TIME_WAIT的原因，相比掛著連接等待客戶端關閉，服務器等待確認TCP連接狀態要快太多了。

2）已經進入了瓶頸。即連接數已經達到了極限值。

?

6.出現太多TIME_WAIT可能導致的后果？（持續的到達一定量的高并發短連接，會使服務器因端口資源不足而拒絕為一部分客戶服務）

?在高并發短連接的TCP服務器上，當服務器處理完請求后立刻按照主動正常關閉連接。這個場景下，會出現大量socket處于TIMEWAIT狀態。如果客戶端的并發量持續很高，此時部分客戶端就會顯示連接不上。
我來解釋下這個場景。主動正常關閉TCP連接，都會出現TIMEWAIT。為什么我們要關注這個高并發短連接呢？有兩個方面需要注意：

?① 高并發可以讓服務器在短時間范圍內同時占用大量端口，而端口有個0~65535的范圍，并不是很多，刨除系統和其他服務要用的，剩下的就更少了。
?②在這個場景中，短連接表示“業務處理+傳輸數據的時間 遠遠小于 TIMEWAIT超時的時間”的連接。這里有個相對長短的概念，比如，取一個web頁面，1秒鐘的http短連接處理完業務，在關閉連接之后，這個業務用過的端口會停留在TIMEWAIT狀態幾分鐘，而這幾分鐘，其他HTTP請求來臨的時候是無法占用此端口的。單用這個業務計算服務器的利用率會發現，服務器干正經事的時間和端口（資源）被掛著無法被使用的時間的比例是 1：幾百，服務器資源嚴重浪費。（說個題外話，從這個意義出發來考慮服務器性能調優的話，長連接業務的服務就不需要考慮TIMEWAIT狀態。同時，假如你對服務器業務場景非常熟悉，你會發現，在實際業務場景中，一般長連接對應的業務的并發量并不會很高）
? ? ?綜合這兩個方面，持續的到達一定量的高并發短連接，會使服務器因端口資源不足而拒絕為一部分客戶服務。

7.time_wait狀態如何避免？

首先服務器可以設置SO_REUSEADDR套接字選項來通知內核，如果端口忙，但TCP連接位于TIME_WAIT狀態時可以重用端口。在一個非常有用的場景就是，如果你的服務器程序停止后想立即重啟，而新的套接字依舊希望使用同一端口，此時SO_REUSEADDR選項就可以避免TIME_WAIT狀態。

在很多場景中，為了能夠處理更多的用戶請求，一般取消timewait狀態，用可靠性換取性能！

所以如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是：查代碼。因為問題出在服務器程序里頭啊。

總結

以上是生活随笔為你收集整理的网络：TIME-WAIT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。