Socket中的TIME_WAIT狀態
在高併發短連接的server端，當server處理完client的請求後立刻closesocket此時會出現time_wait狀態然後如果client再併發2000個連接，此時部分連接就連接不上了,用linger強制關閉可以解決此問題，但是linger會導致數據丟失，linger值爲0時是強制關閉,無論併發多少多能正常連接上,如果非0會發生部分連接不上的情況!（可調用setsockopt設置套接字的linger延時標誌，同時將延時時間設置爲0。）
TCP/IP的RFC文檔。TIME_WAIT是TCP連接斷開時必定會出現的狀態。
是無法避免掉的，這是TCP協議實現的一部分。
在WINDOWS下，可以修改註冊表讓這個時間變短一些
time_wait的時間爲2msl,默認爲4min.
你可以通過改變這個變量:
TcpTimedWaitDelay
把它縮短到30s
TCP要保證在所有可能的情況下使得所有的數據都能夠被投遞。當你關閉一個socket時，主動關閉一端的socket將進入TIME_WAIT狀態，而被動關閉一方則轉入CLOSED狀態，這的確能夠保證所有的數據都被傳輸。當一個socket關閉的時候，是通過兩端互發信息的四次握手過程完成的，當一端調用close()時，就說明本端沒有數據再要發送了。這好似看來在握手完成以後，socket就都應該處於關閉CLOSED狀態了。但這有兩個問題，首先，我們沒有任何機制保證最後的一個ACK能夠正常傳輸，第二，網絡上仍然有可能有殘餘的數據包(wandering
duplicates)，我們也必須能夠正常處理。 ..
通過正確的狀態機，我們知道雙方的關閉過程如下
圖
假設最後一個ACK丟失了，服務器會重發它發送的最後一個FIN，所以客戶端必須維持一個狀態信息，以便能夠重發ACK；如果不維持這種狀態，客戶端在接收到FIN後將會響應一個RST，服務器端接收到RST後會認爲這是一個錯誤。如果TCP協議能夠正常完成必要的操作而終止雙方的數據流傳輸，就必須完全正確的傳輸四次握手的四個節，不能有任何的丟失。這就是爲什麼socket在關閉後，仍然處於 TIME_WAIT狀態，因爲他要等待以便重發ACK。 .
如果目前連接的通信雙方都已經調用了close()，假定雙方都到達CLOSED狀態，而沒有TIME_WAIT狀態時，就會出現如下的情況。現在有一個新的連接被建立起來，使用的IP地址與端口與先前的完全相同，後建立的連接又稱作是原先連接的一個化身。還假定原先的連接中有數據報殘存於網絡之中，這樣新的連接收到的數據報中有可能是先前連接的數據報。爲了防止這一點，TCP不允許從處於TIME_WAIT狀態的socket建立一個連接。處於TIME_WAIT狀態的socket在等待兩倍的MSL時間以後（之所以是兩倍的MSL，是由於MSL是一個數據報在網絡中單向發出到認定丟失的時間，一個數據報有可能在發送圖中或是其響應過程中成爲殘餘數據報，確認一個數據報及其響應的丟棄的需要兩倍的MSL），將會轉變爲CLOSED狀態。這就意味着，一個成功建立的連接，必然使得先前網絡中殘餘的數據報都丟失了。
由於TIME_WAIT狀態所帶來的相關問題，我們可以通過設置SO_LINGER標誌來避免socket進入TIME_WAIT狀態，這可以通過發送RST而取代正常的TCP四次握手的終止方式。但這並不是一個很好的主意，TIME_WAIT對於我們來說往往是有利的。
客戶端與服務器端建立TCP/IP連接後關閉SOCKET後，服務器端連接的端口
狀態爲TIME_WAIT
是不是所有執行主動關閉的socket都會進入TIME_WAIT狀態呢？
有沒有什麼情況使主動關閉的socket直接進入CLOSED狀態呢？
主動關閉的一方在發送最後一個 ack 後
就會進入 TIME_WAIT 狀態 停留2MSL（max segment lifetime）時間
這個是TCP/IP必不可少的，也就是“解決”不了的。
也就是TCP/IP設計者本來是這麼設計的
主要有兩個原因
1。防止上一次連接中的包，迷路後重新出現，影響新連接
（經過2MSL，上一次連接中所有的重複包都會消失）
2。可靠的關閉TCP連接
在主動關閉方發送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發
fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以
主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。
TIME_WAIT 並不會佔用很大資源的，除非受到攻擊。
還有，如果一方 send 或 recv 超時，就會直接進入 CLOSED 狀態