一檢視現在time_wait的數量及淺析

    netstat -an | grep TIME_WAIT | wc -l 

發現系統存在大量TIME_WAIT狀態的連線，通過調整核心引數解決，在 /etc/sysctl.conf中加入

net.ipv4.tcp_tw_recycle = 1    （表示開啟TCP連線中TIME-WAIT sockets的快速回收，預設為0，表示關閉）

建立TCP需要3次握手，而終止TCP需要4次互動；


主動關閉socket的一方最終為time_wait，被動關閉的則為close_wait；


為什麼time_wait需要2*MSL等待時間？
MSL就是maximum segment lifetime(最大分節生命期），這是一個IP資料包能在網際網路上生存的最長時間，超過這個時間將在網路中消失。

1、 若設定了SO_LINGER（亦即linger結構中的l_onoff域設為非零），並設定了零超時間隔，則closesocket()不被阻塞立即執行，不論是否有排隊資料未傳送或未被確認。這種關閉方式稱為 “強制”或“失效”關閉 ，因為套介面的虛電路立即被複位，且丟失了未傳送的資料。在遠端的recv()呼叫將以WSAECONNRESET出錯。 
2、 若設定了SO_LINGER並確定了非零的超時間隔，則closesocket()呼叫阻塞程序，直到所剩資料傳送完畢或超時。這種關閉稱為 “優雅”或“從容”關閉 。請注意如果套介面置為非阻塞且SO_LINGER設為非零超時，則closesocket()呼叫將以WSAEWOULDBLOCK錯誤返回。 
3、 若在一個流類套介面上設定了SO_DONTLINGER（也就是說將linger結構的l_onoff域設為零），則closesocket()呼叫立即返回。但是，如果可能，排隊的資料將在套介面關閉前傳送。請注意，在這種情況下WINDOWS套介面實現將在一段不確定的時間內保留套介面以及其他資源，這對於想用所以套介面的應用程式來說有一定影響。 

二.出現原因分析

TCP連線的終止 
TCP建立一個連線至少需要交換三個分組，也因此稱之為TCP的三路握手（three-way handshake），然而在TCP終止連線時，由於雙方都需要傳送一個FIN分節給對端確認，因此TCP終止連線一般是需要交換四個分節。具體來看： 

1、 應用程序（active close）首先呼叫close，於是導致TCP傳送一個FIN分節，表示資料已分送完畢，請求關閉套接字。 
2、 另一端應用程序（passive close）接受收到FIN，並由該端的TCP確認（確認的過程是TCP傳送ACK分節給對端套接字）。FIN的接受也作為檔案結束符傳遞給上層應用程序。這裡的檔案結束符並非應用程序的EOF，在TCP位元組流中，EOF的讀或寫通過收發一個特殊的FIN分節來實現。 
3、 另端（passive close）應用程序在接受到檔案束符後，會呼叫close關閉它的套接字，這導致該端的TCP也傳送了一個FIN分節。 
4、 主動關閉端（active close）接受到這個FIN後，TCP對它進行確認。（TCP傳送ACK分節，值得注意的是主動關閉端在未接受到FIN之前，它的狀態就是TIME_WAIT）。



綜上所述：TIME_WAIT狀態出現場景是主動關閉端在未接受到FIN之前，它的狀態就是TIME_WAIT。

二.TCP為什麼如此設計

1。防止上一次連線中的包(特別是最後一個ACK包)，迷路後重新出現，影響新連線  （經過2MSL(max segment lifetime)，上一次連線中所有的重複包都會消失）。
2。可靠的關閉TCP連線  在主動關閉方傳送的最後一個 ack(fin) ，有可能丟失，這時被動方會重新發
  fin, 如果這時主動方處於 CLOSED 狀態 ，就會響應 rst 而不是 ack。所以  主動方要處於 TIME_WAIT 狀態，而不能是 CLOSED 。TIME_WAIT 並不會佔用很大資源的，除非受到攻擊。還有，如果一方 send 或 recv 超時，就會直接進入 CLOSED 狀態。

三.規避大量出現TIME_WAIT的方法

在伺服器的日常維護過程中，會經常用到下面的命令：

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

它會顯示例如下面的資訊：

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

常用的三個狀態是：ESTABLISHED 表示正在通訊，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關閉。

ps:以上為自己總結網上各個blog的內容，方便自己掌握知識點用!

四.三次握手的詳細描述

1. 第一次握手：建立連線。客戶端傳送連線請求報文段，將SYN位置為1，Sequence Number為x；然後，客戶端進入SYN_SEND狀態，等待伺服器的確認；
2. 第二次握手：伺服器收到SYN報文段。伺服器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設定Acknowledgment Number為x+1(Sequence Number+1)；同時，自己自己還要傳送SYN請求資訊，將SYN位置為1，Sequence Number為y；伺服器端將上述所有資訊放到一個報文段（即SYN+ACK報文段）中，一併傳送給客戶端，此時伺服器進入SYN_RECV狀態；
3. 第三次握手：客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1，向伺服器傳送ACK報文段，這個報文段傳送完畢以後，客戶端和伺服器端都進入ESTABLISHED狀態，完成TCP三次握手。

完成了三次握手，客戶端和伺服器端就可以開始傳送資料。以上就是TCP三次握手的總體介紹。

為什麼要三次握手

既然總結了TCP的三次握手，那為什麼非要三次呢？怎麼覺得兩次就可以完成了。那TCP為什麼非要進行三次連線呢？在謝希仁的《計算機網路》中是這樣說的：

為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤。

在書中同時舉了一個例子，如下：

“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”

這就很明白了，防止了伺服器端的一直等待而浪費資源。

五。四次揮手的詳細描述

當客戶端和伺服器通過三次握手建立了TCP連線以後，當資料傳送完畢，肯定是要斷開TCP連線的啊。那對於TCP的斷開連線，這裡就有了神祕的“四次分手”。

1. 第一次分手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；
2. 第二次分手：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number為Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我也沒有資料要傳送了，可以進行關閉連線了；
3. 第三次分手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入CLOSE_WAIT狀態；
4. 第四次分手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。

至此，TCP的四次分手就這麼愉快的完成了。當你看到這裡，你的腦子裡會有很多的疑問，很多的不懂，感覺很凌亂；沒事，我們繼續總結。

為什麼要四次分手

那四次分手又是為何呢？TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。TCP是全雙工模式，這就意味著，當主機1發出FIN報文段時，只是表示主機1已經沒有資料要傳送了，主機1告訴主機2，它的資料已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的資料；當主機2返回ACK報文段時，表示它已經知道主機1沒有資料傳送了，但是主機2還是可以傳送資料到主機1的；當主機2也傳送了FIN報文段時，這個時候就表示主機2也沒有資料要傳送了，就會告訴主機1，我也沒有資料要傳送了，之後彼此就會愉快的中斷這次TCP連線。如果要正確的理解四次分手的原理，就需要了解四次分手過程中的狀態變化。

• FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
• FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點資料需要傳送給你(ACK資訊)，稍後再關閉連線。（主動方）
• CLOSE_WAIT：這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。（被動方）
• LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）
• TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FINWAIT1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）
• CLOSED: 表示連線中斷。