time-wait狀態是tcp的11個狀態其中之一，是發生在正常關閉tcp連線的時候發生的。如下圖所示：
在這幅圖中我們可以明顯看出，流程是這樣的，顯示主動傳送乙個fin報文，然後接收到乙個ack報文，這樣這一方的連線已經關閉，也就是不能再傳送資料了，進入fin_wait2狀態，這個狀態就是為了等待，被動關閉連線的一方，傳送fin報文，在這期間可以接收來自對方的資料，等到被動關閉這一端，傳送完畢後，就會發出乙個fin報文，那麼在接收到fin報文後，進入time_wait狀態，首先向被動連線那一方，傳送乙個ack，然後進入等待狀態，等待時長為2msl（msl為乙個tcp報文在網路中能夠存活的最大時長），很多人問，為什麼會進入乙個等待，狀態呢。因為如上圖所示，被動關閉連線的哪一方，在傳送出fin報文後，要確定主動方，接收到它傳送的fin報文，怎麼知道是否接收到呢，那麼就是對方返回乙個ack報文。設想如果主動方傳送的最後乙個報文不能到達被動關閉連線方呢？這時候如果主動方不等待，直接選擇關閉連線，然後被動方又不知道，超時會重傳fin報文，但是主動方已經關閉了，所以不會反回任何應答，這樣就會讓被動方關閉連線上出問題，所以得等待一段時間，看被動方是否接收到了最後乙個ack，如果沒接收到的話，fin報文會超時重傳，那麼在等待階段接收到fin報文後，可以重發，最後乙個ack。這樣在關閉連線上就沒有什麼問題了。另外其實，如果不等待一段時間還會發生另外乙個問題，設想在tcp互動過程中，乙個報文因為各種原因，沒有到達目的地，如果不等待一段時間，那麼意味著在關閉連線後立刻在這個埠上就可以建立新的連線，那麼在新連線互動的過程中，如果上乙個連線的那個沒有到達的報文，現在到達了，那麼是不是就會出現新的問題，所以說要等待2msl時間，可以讓老的報文徹底消失，才能開始乙個新的連線。
經過以上的討論其實要在time_wait階段等待一段時間的主要原因有兩個：
1.能夠確保被動關閉連線方能夠，接收到最後乙個ack，也就是能夠確定，主動方已經接收到被動方的fin報文。
2.能夠確保本次連線的所有未到達的報文段，能夠徹底在網路中消失，不會影響下一次在相同埠上建立的新連線。
所以一般在某乙個埠上關閉tcp連線後不能立即啟用本埠建立新的連線，因為在time_wait階段是不允許建立新的連線的。
Tcp主動關閉連線導致TIME WAIT狀態
最近寫了乙個程序，需要通過20個執行緒迴圈600個使用者獲取每乙個使用者的xx資訊，是通過socket連線oracle mdb伺服器獲取的，但是在本機windows上測試發現大量的time wait狀態，按照網上的說法，調了登錄檔的引數，但是無濟於事，socket.setreuseaddress方法...
理解tcp關閉連線中的time wait狀態
首先看一下tcp關閉連線時的四次握手過程 1.client向server傳送fin包，表示client主動要關閉連線，然後進入fin wait 1狀態，等待server返回ack包。此後client不能再向server傳送資料，但能讀取資料。2.server收到fin包後向client傳送ack包，...
TCP連線出現很多TIME WAIT
我為啥會發現呢，本來任務是發現pinpoint上有的請求時間等待間隙過長，為了查詢出tomcat的api鏈路有等待的。我開始排查tcp的連線開始，然後再到tomcat的執行緒優化數。再檢查到tcp連線的時候發現了大問題。netstat ant grep 8080 wc l使用以上命令檢視tomcat...