客戶端與伺服器端建立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 狀態
TIME WAIT狀態釋疑
一 現象 登陸伺服器的時候輸入netstat natup 發現存在大量time wait狀態的連線 tcp 0 0 127.0.0.1 3306 127.0.0.1 41378 time wait tcp 0 0 127.0.0.1 3306 127.0.0.1 41379 time wait tc...
TCP IP中的TIME WAIT狀態
毫無疑問，tcp中有關網路程式設計最不容易理解的是它的time wait狀態，time wait狀態存在於主動關閉socket連線的一方。time wait狀態存在的理由 tcp ip協議就是這樣設計的，是不可避免的。主要有兩個原因 1 可靠地實現tcp全雙工連線的終止 tcp協議在關閉連線的四次握...
TCP連線的TIME WAIT狀態
time wait狀態是tcp的11個狀態其中之一，是發生在正常關閉tcp連線的時候發生的。如下圖所示 在這幅圖中我們可以明顯看出，流程是這樣的，顯示主動傳送乙個fin報文，然後接收到乙個ack報文，這樣這一方的連線已經關閉，也就是不能再傳送資料了，進入fin wait2狀態，這個狀態就是為了等待，...