在伺服器的日常維護過程中，會經常用到下面的命令：
[plain]view plain
copy
?netstat -n | awk 』/^tcp/ end '
netstat -n | awk '/^tcp/ end 』
它會顯示例如下面的資訊：
time_wait 814
close_wait 1
fin_wait1 1
established 634
syn_recv 2
last_ack 1
常用的三個狀態是：established 表示正在通訊，time_wait 表示主動關閉，close_wait 表示被動關閉。
tcp協議規定，對於已經建立的連線，網路雙方要進行四次握手才能成功斷開連線，如果缺少了其中某個步驟，將會使連線處於假死狀態，連線本身占用的資源不會被釋放。網路伺服器程式要同時管理大量連線，所以很有必要保證無用連線完全斷開，否則大量僵死的連線會浪費許多伺服器資源。在眾多tcp狀態中，最值得注意的狀態有兩個：close_wait和time_wait。
time_wait
time_wait 是主動關閉鏈結時形成的，等待2msl時間，約4分鐘。主要是防止最後乙個ack丟失。 由於time_wait 的時間會非常長，因此server端應儘量減少主動關閉連線
close_wait
close_wait是被動關閉連線是形成的。根據tcp狀態機，伺服器端收到客戶端傳送的fin，則按照tcp實現傳送ack，因此進入close_wait狀態。但如果伺服器端不執行close()，就不能由close_wait遷移到last_ack，則系統中會存在很多close_wait狀態的連線。此時，可能是系統忙於處理讀、寫操作，而未將已收到fin的連線，進行close。此時，recv/read已收到fin的連線socket，會返回0。
為什麼需要 time_wait 狀態？
假設最終的ack丟失，server將重發fin，client必須維護tcp狀態資訊以便可以重發最終的ack，否則會傳送rst，結果server認為發生錯誤。tcp實現必須可靠地終止連線的兩個方向(全雙工關閉)，client必須進入 time_wait 狀態，因為client可能面 臨重發最終ack的情形。
為什麼 time_wait 狀態需要保持 2msl 這麼長的時間？
如果 time_wait 狀態保持時間不足夠長(比如小於2msl)，第乙個連線就正常終止了。第二個擁有相同相關五元組的連線出現，而第乙個連線的重複報文到達，干擾了第二個連線。tcp實現必須防止某個連線的重複報文在連線終止後出現，所以讓time_wait狀態保持時間足夠長(2msl)，連線相應方向上的tcp報文要麼完全響應完畢，要麼被 丟棄。建立第二個連線的時候，不會混淆。
time_wait 和close_wait狀態socket過多
如果伺服器出了異常，百分之**十都是下面兩種情況：
1.伺服器保持了大量time_wait狀態
2.伺服器保持了大量close_wait狀態，簡單來說close_wait數目過大是由於被動關閉連線處理不當導致的。
因為linux分配給乙個使用者的檔案控制代碼是有限的，而time_wait和close_wait兩種狀態如果一直被保持，那麼意味著對應數目的通道就一直被佔著，而且是「佔著茅坑不使勁」，一旦達到控制代碼數上限，新的請求就無法被處理了，接著就是大量too many open files異常，tomcat崩潰。
TIME WAIT和CLOSE WAIT狀態區別
在伺服器的日常維護過程中，會經常用到下面的命令 netstat n awk tcp end 它會顯示例如下面的資訊 time wait 814 close wait 1 fin wait1 1 established 634 syn recv 2 last ack 1 常用的三個狀態是 establ...
TIME WAIT狀態和reuse問題
time wait狀態和reuse問題。上一篇看了tcp的三次握手與四次揮手，記得四次揮手，主動斷開連線的一方最後乙個狀態就是time wait狀態，並且一定是主動斷開連線的一方，它可能使socket能陷入一種時間比較長的狀態，過多的time wait會影響新socket的建立。那麼time wai...
tcp三次握手和time wait
第一次握手 建立連線時，客戶端傳送syn包和乙個隨機序列號seq x到伺服器，並進入syn send狀態，等待伺服器進行確認。syn，同 步序列編號 第二次握手，伺服器收到syn包，必須確認客戶的syn，然後伺服器傳送乙個ack 1,syn 1,seq y的隨機數和ack x 1的確認數的包傳送回去...