轉自http://elf8848.iteye.com/blog/1739571java
TIME_WAIT狀態原理nginx
----------------------------後端
通訊雙方創建TCP鏈接後，主動關閉鏈接的一方就會進入TIME_WAIT狀態。安全
客戶端主動關閉鏈接時，會發送最後一個ack後，而後會進入TIME_WAIT狀態，再停留2個MSL時間(後有MSL的解釋)，進入CLOSED狀態。服務器
下圖是以客戶端主動關閉鏈接爲例，說明這一過程的。網絡
TIME_WAIT狀態存在的理由app
----------------------------socket
TCP/IP協議就是這樣設計的，是不可避免的。主要有兩個緣由:tcp
1）可靠地實現TCP全雙工鏈接的終止post
TCP協議在關閉鏈接的四次握手過程當中，最終的ACK是由主動關閉鏈接的一端（後面統稱A端）發出的，若是這個ACK丟失，對方（後面統稱B端）將重發出最終的FIN，所以A端必須維護狀態信息（TIME_WAIT）容許它重發最終的ACK。若是A端不維持TIME_WAIT狀態，而是處於CLOSED 狀態，那麼A端將響應RST分節，B端收到後將此分節解釋成一個錯誤（在java中會拋出connection reset的SocketException)。
於是，要實現TCP全雙工鏈接的正常終止，必須處理終止過程當中四個分節任何一個分節的丟失狀況，主動關閉鏈接的A端必須維持TIME_WAIT狀態 。
2）容許老的重複分節在網絡中消逝
TCP分節可能因爲路由器異常而「迷途」，在迷途期間，TCP發送端可能因確認超時而重發這個分節，迷途的分節在路由器修復後也會被送到最終目的地，這個遲到的迷途分節到達時可能會引發問題。在關閉「前一個鏈接」以後，立刻又從新創建起一個相同的IP和端口之間的「新鏈接」，「前一個鏈接」的迷途重複分組在「前一個鏈接」終止後到達，而被「新鏈接」收到了。爲了不這個狀況，TCP協議不容許處於TIME_WAIT狀態的鏈接啓動一個新的可用鏈接，由於TIME_WAIT狀態持續2MSL，就能夠保證當成功創建一個新TCP鏈接的時候，來自舊鏈接重複分組已經在網絡中消逝。
MSL時間
----------------------------
MSL就是maximum segment lifetime(最大分節生命期），這是一個IP數據包能在互聯網上生存的最長時間，超過這個時間IP數據包將在網絡中消失 。MSL在RFC 1122上建議是2分鐘，而源自berkeley的TCP實現傳統上使用30秒。
TIME_WAIT狀態維持時間
----------------------------
TIME_WAIT狀態維持時間是兩個MSL時間長度，也就是在1-4分鐘。Windows操做系統就是4分鐘。
用於統計當前各類狀態的鏈接的數量的命令
---------------------------
#netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
返回結果以下：
LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122
對上述結果的解釋：
CLOSED：無鏈接是活動的或正在進行
LISTEN：服務器在等待進入呼叫
SYN_RECV：一個鏈接請求已經到達，等待確認
SYN_SENT：應用已經開始，打開一個鏈接
ESTABLISHED：正常數據傳輸狀態
FIN_WAIT1：應用說它已經完成
FIN_WAIT2：另外一邊已贊成釋放
ITMED_WAIT：等待全部分組死掉
CLOSING：兩邊同時嘗試關閉
TIME_WAIT：另外一邊已初始化一個釋放
LAST_ACK：等待全部分組死掉
進一步論述這個問題：
===============================
--------------客戶端主動關閉鏈接-----------------------
注意一個問題，進入TIME_WAIT狀態的通常狀況下是客戶端。
大多數服務器端通常執行被動關閉，服務器不會進入TIME_WAIT狀態。
當在服務器端關閉某個服務再從新啓動時，服務器是會進入TIME_WAIT狀態的。
舉例：
1.客戶端鏈接服務器的80服務，這時客戶端會啓用一個本地的端口訪問服務器的80，訪問完成後關閉此鏈接，馬上再次訪問服務器的
80，這時客戶端會啓用另外一個本地的端口，而不是剛纔使用的那個本地端口。緣由就是剛纔的那個鏈接還處於TIME_WAIT狀態。
2.客戶端鏈接服務器的80服務，這時服務器關閉80端口，當即再次重啓80端口的服務，這時可能不會成功啓動，緣由也是服務器的連
接還處於TIME_WAIT狀態。
服務端提供服務時，通常監聽一個端口就夠了。例如Apach監聽80端口。
客戶端則是使用一個本地的空閒端口（大於1024），與服務端的Apache的80端口創建鏈接。
當通訊時使用短鏈接，並由客戶端主動關閉鏈接時，主動關閉鏈接的客戶端會產生TIME_WAIT狀態的鏈接，一個TIME_WAIT狀態的鏈接就佔用了一個本地端口。這樣在TIME_WAIT狀態結束以前，本地最多就能承受6萬個TIME_WAIT狀態的鏈接，就無故口可用了。
客戶端與服務端進行短鏈接的TCP通訊，若是在同一臺機器上進行壓力測試模擬上萬的客戶請求，而且循環與服務端進行短鏈接通訊，那麼這臺機器將產生4000個左右的TIME_WAIT socket，後續的短鏈接就會產生address already in use : connect的異常。
關閉的時候使用RST的方式，不進入 TIME_WAIT狀態，是否可行？
--------------服務端主動關閉鏈接------------------------------
服務端提供在服務時，通常監聽一個端口就夠了。例如Apach監聽80端口。
客戶端則是使用一個本地的空閒端口（大於1024），與服務端的Apache的80端口創建鏈接。
當通訊時使用短鏈接，並由服務端主動關閉鏈接時，主動關閉鏈接的服務端會產生TIME_WAIT狀態的鏈接。
因爲都鏈接到服務端80端口，服務端的TIME_WAIT狀態的鏈接會有不少個。
假如server一秒鐘處理1000個請求，那麼就會積壓240秒*1000=24萬個TIME_WAIT的記錄，服務有能力維護這24萬個記錄。
大多數服務器端通常執行被動關閉，服務器不會進入TIME_WAIT狀態。
服務端爲了解決這個TIME_WAIT問題，可選擇的方式有三種：
Ø 保證由客戶端主動發起關閉（即作爲B端）
Ø 關閉的時候使用RST的方式
Ø 對處於TIME_WAIT狀態的TCP容許重用
通常Apache的配置是：
Timeout 30
KeepAlive On #表示服務器端不會主動關閉連接
MaxKeepAliveRequests 100
KeepAliveTimeout 180
表示：Apache不會主動關閉連接，
兩種狀況下Apache會主動關閉鏈接：
一、Apache收到了http協議頭中有客戶端要求Apache關閉鏈接信息，如setRequestHeader("Connection", "close");
二、鏈接保持時間達到了180秒的超時時間，將關閉。
若是配置以下：
KeepAlive Off #表示服務器端會響應完數據後主動關閉連接
--------------有代理時------------------------------
nginx代理使用了短連接的方式和後端交互，若是使用了nginx代理，那麼系統TIME_WAIT的數量會變得比較多，這是因爲nginx代理使用了短連接的方式和後端交互的緣由，使得nginx和後端的ESTABLISHED變得不多而TIME_WAIT不少。這不但發生在安裝nginx的代理服務器上，並且也會使後端的app服務器上有大量的TIME_WAIT。查閱TIME_WAIT資料，發現這個狀態不少也沒什麼大問題，但可能由於它佔用了系統過多的端口，致使後續的請求沒法獲取端口而形成障礙。
對於大型的服務，一臺server搞不定，須要一個LB(Load Balancer)把流量分配到若干後端服務器上，若是這個LB是以NAT方式工做的話，可能會帶來問題。假如全部從LB到後端Server的IP包的source address都是同樣的(LB的對內地址），那麼LB到後端Server的TCP鏈接會受限制，由於頻繁的TCP鏈接創建和關閉，會在server上留下TIME_WAIT狀態，並且這些狀態對應的remote address都是LB的，LB的source port撐死也就60000多個(2^16=65536,1~1023是保留端口，還有一些其餘端口缺省也不會用），每一個LB上的端口一旦進入Server的TIME_WAIT黑名單，就有240秒不能再用來創建和Server的鏈接，這樣LB和Server最多也就能支持300個左右的鏈接。若是沒有LB，不會有這個問題，由於這樣server看到的remote address是internet上廣闊無垠的集合，對每一個address，60000多個port實在是夠用了。
一開始我以爲用上LB會很大程度上限制TCP的鏈接數，可是實驗代表沒這回事，LB後面的一臺Windows Server 2003每秒處理請求數照樣達到了600個，難道TIME_WAIT狀態沒起做用？用Net Monitor和netstat觀察後發現，Server和LB的XXXX端口之間的鏈接進入TIME_WAIT狀態後，再來一個LB的XXXX端口的SYN包，Server照樣接收處理了，而是想像的那樣被drop掉了。翻書，從書堆裏面找出覆滿塵土的大學時代買的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中間提到一句，對於BSD-derived實現，只要SYN的sequence number比上一次關閉時的最大sequence number還要大，那麼TIME_WAIT狀態同樣接受這個SYN，難不成Windows也算BSD-derived?有了這點線索和關鍵字(BSD)，找到這個post，在NT4.0的時候，仍是和BSD-derived不同的，不過Windows Server 2003已是NT5.2了，也許有點差異了。
作個試驗，用Socket API編一個Client端，每次都Bind到本地一個端口好比2345，重複的創建TCP鏈接往一個Server發送Keep-Alive=false的HTTP請求，Windows的實現讓sequence number不斷的增加，因此雖然Server對於Client的2345端口鏈接保持TIME_WAIT狀態，可是老是可以接受新的請求，不會拒絕。那若是SYN的Sequence Number變小會怎麼樣呢？一樣用Socket API，不過此次用Raw IP，發送一個小sequence number的SYN包過去，Net Monitor裏面看到，這個SYN被Server接收後如泥牛如海，一點反應沒有，被drop掉了。
按照書上的說法，BSD-derived和Windows Server 2003的作法有安全隱患，不過至少這樣至少不會出現TIME_WAIT阻止TCP請求的問題，固然，客戶端要配合，保證不一樣TCP鏈接的sequence number要上漲不要降低。
-------------------------------------------
Q: 我正在寫一個unix server程序，不是daemon，常常須要在命令行上重啓它，絕大
多數時候工做正常，可是某些時候會報告"bind: address in use"，因而重啓失
敗。
A: Andrew Gierth
server程序老是應該在調用bind()以前設置SO_REUSEADDR套接字選項。至於
TIME_WAIT狀態，你沒法避免，那是TCP協議的一部分。
Q: 編寫 TCP/SOCK_STREAM 服務程序時，SO_REUSEADDR到底什麼意思？
A: 這個套接字選項通知內核，若是端口忙，但TCP狀態位於 TIME_WAIT ，能夠重用
端口。若是端口忙，而TCP狀態位於其餘狀態，重用端口時依舊獲得一個錯誤信息，
指明"地址已經使用中"。若是你的服務程序中止後想當即重啓，而新套接字依舊
使用同一端口，此時 SO_REUSEADDR 選項很是有用。必須意識到，此時任何非期
望數據到達，均可能致使服務程序反應混亂，不過這只是一種可能，事實上很不
可能。
一個套接字由相關五元組構成，協議、本地地址、本地端口、遠程地址、遠程端
口。SO_REUSEADDR 僅僅表示能夠重用本地本地地址、本地端口，整個相關五元組
仍是惟一肯定的。因此，重啓後的服務程序有可能收到非指望數據。必須慎重使
用 SO_REUSEADDR 選項。