tcp狀態轉移要點
tcp協議規定，對於已經建立的連線，網路雙方要進行四次握手才能成功斷開連線，如果缺少其中某個步驟，將會使連線處於假死狀態，連線本身占用的資源不會被釋放，網路伺服器程式要同時管理大量連線，所以很有必要保證無用連線完全斷開，否則大量僵死的連線會浪費許多伺服器資源，在眾多tcp狀態中，最值得注意的狀態有兩個：close_wait和time_wait
1.listening狀態
ftp服務啟動後首先處於偵聽（listening）狀態。
2.established狀態
建立連線，表示兩台機器正在通訊。
3.close_wait
（1）對方主動關閉連線或者網路異常導致連線中斷，（被迫斷開連線）這時我方的狀態變為close_wait（對方主動關閉連線），此時我方要呼叫close()使連線正確關閉
4.time_wait
（1）我方主動呼叫close()斷開連線，（2）收到對方確認後狀態變為time_wait，tcp協議規定time-wait狀態一直持續2msl（兩倍的分段最大生存期），以此確保舊的連線狀態不會對新連線產生影響，處於time_wait狀態的連線占用的資源不會被核心釋放，所以作為伺服器，在可能的情況下，盡量不要主動斷開連線，以減少time_wait狀態造成的資源浪費。
tcp連線的四次握手
（1）host1上的應用程式關閉己方的連線導致tcp傳送乙個fin訊息給host2；
（2）host2傳送乙個確認訊息給host1，並且host2把host1發來的fin作為eof訊息給host2上的應用程式；
（3）一段時間過後，host2上的應用程式關閉它那裡的連線，引發乙個fin訊息給host1；
（4）host1給host2傳送乙個確認訊息，然後host2關閉連線並釋放資源，然而，host1並沒有關閉連線，而是進入time_wait狀態，並為兩個最大段生存時間（2msl）保留在此狀態。
time-wait的好處
在第四步的時候，host1傳送的ack可能丟失導致host2重新傳送fin訊息，time_wait維護連線狀態，如果執行主動關閉的一方的host1不進入到time_wait狀態就關閉連線，當重傳的fin訊息到達時，因為tcp已經不再有連線的資訊了，所有就用rst訊息應答，導致host2進入錯誤的狀態而不是有序終止狀態，如果傳送最後ack訊息的一方處於time-wait狀態並仍然記錄連線資訊，它就可以正確的相應對方host2的fin訊息
缺陷：在time_wait狀態時，核心不釋放資源，造成資源浪費，因此作為伺服器不應該主動釋放連線。
具體見：
tcp連線建立
tcp連線建立是3此握手
第一次：建立連線時，客戶端傳送syn(syn=j)到伺服器，並進入syn_send（客戶端傳送syn進入syn_send）狀態，等待伺服器確認；
第二次：伺服器受到syn包，必須確認客戶的syn（ack=j+1），同時自己也傳送乙個syn(syn=k)，及syn+ack包，此時伺服器進入syn_recv狀態；
第三次：客戶端受到伺服器的syn+ack包，向伺服器傳送確認包ack（ack=k+1），此包傳送完畢，客戶端和伺服器進入established狀態，完成三次握手。
TCP IP 斷開連線
tcp ip 斷開連線 四次握手 斷開連線其實從我的角度看不區分客戶端和伺服器端，任何一方都可以呼叫close or closesocket 之類 的函式開始主動終止乙個連線。這裡先暫時說正常情況。當呼叫close函式斷開乙個連線時，主動斷開的 一方傳送fin finish報文給對方。有了之前的經驗...
TCP IP連線和斷開連線
tcp ip 三次握手 第一次握手 建立連線時，客戶端a傳送syn包 syn j 到伺服器b，並進入syn send狀態，等待伺服器b確認。第二次握手 伺服器b收到syn包，必須確認客戶a的syn ack j 1 同時自己也傳送乙個syn包 syn k 即syn ack包，此時伺服器b進入syn r...
TCP IP 斷開連線 2008
四次握手 斷開連線其實從我的角度看不區分客戶端和伺服器端，任何一方都可以呼叫close or closesocket 之類 的函式開始主動終止乙個連線。這裡先暫時說正常情況。當呼叫close函式斷開乙個連線時，主動斷開的 一方傳送fin finish報文給對方。有了之前的經驗，我想你應該明白我說的f...