當tcp主動關閉套接字時，採用四步握手機制來徹底關閉連線。如圖：
客戶端主動關閉連線，傳送fin段到服務端。tcp狀態由established(連線狀態)轉為fin_wait1(表示，傳送的fin需要確認)。
服務端接受fin後，服務端的tcp狀態由established轉為close_wait，並且回送ack。
客戶端接受確認ack後，tcp狀態由fin_wait1轉化為fin_wait2(表示已經確認fin，等待來自服務端的fin請求)。
服務端傳送fin，tcp狀態close_wait轉為last_ack(表示伺服器在等待客戶端的ack)
結束到fin後，客戶端傳送ack並且將狀態轉會為time_wait
伺服器接受ack，tcp狀態轉為closed(關閉)。過一段時間，客戶端有time_wait轉為closed。
傳送主動關閉的一方在最終轉換訊息時經歷了乙個time_wait狀態，並且保持這個狀態一段時間。time_wait狀態存在打作用是什麼？
確認對等端收到了最後的ack。最後的ack可能意外丟失，導致對等端認為fin丟失，進而重傳fin。因此，這個狀態可以對重傳作出回應。
伺服器發起主動關閉但不進入time_wait狀態，而這時客戶端崩潰重啟，重啟後立即發起重新連線。重連時使用上次埠號進行連線，兩端通訊時，所使用的序列號恰好與上次相同，這樣當上次連線殘留在路由器中的資料到達伺服器(延時資料段)，進行資料整合時出現混亂。 當存在time_wait狀態時，伺服器會拒絕客戶端的連線請求，這樣確保不會使用處於time_wait狀態的tcp連線埠號來與客戶端連線。
客戶端發起主動關閉，而不處於time_wait狀態。在這種情況下可能發起連線時重用以前的埠號，這樣產生相同的問題。
time_wait狀態存在，意味著兩端的連線依然存在，意味著在time_wait狀態時依然保留四元組（源ip，源埠，目的ip，目的埠)，兩端不得使用這些埠建立連線。
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包，...
UNP 第二章，TCP狀態，TIME WAIT
狀態可以用 netstat 驗證 加粗線為 資料交換。可以看出，tcp在 建立連線和 關閉連線，耗費資源，因為udp只需要兩次資料通訊即可。但udp沒有可靠傳輸，和流量控制。上面協商的mss為，兩者最小值，即小於536 注釋 mss時syn的乙個選項，用於告訴對方 它的最大分節大小，即在本次連線中，...