基于TCP協議的通訊流程 1、TCP建立連接

2、TCP斷開連接
3、TCP狀態轉換

TCP狀態解釋：

SYN-RECVD：再收到和發送一個連接請求后等待對方對連接請求的確認
ESTABLISHED：代表一個打開的連接
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
FIN-WAIT-2：從遠程TCP等待連接中斷請求
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
CLOSING：等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED：沒有任何連接狀態

TIME_WAIT狀態：
? ? ? ? 從TCP狀態遷移圖可知，只有首先調用close()發起主動關閉的一方才會進入TIME_WAIT狀態，而且是必須進入（圖中左 ? ? ?下角所示的3條狀態遷移線最終均要進入該狀態才能回到初始的CLOSED狀態）。
? ? ? ? 從圖中還可看到，進入TIME_WAIT狀態的TCP連接需要經過2MSL才能回到初始狀態，其中，MSL是指Max
? ? ?Segment Lifetime，即數據包在網絡中的最大生存時間。每種TCP協議的實現方法均要指定一個合適的MSL值，如RFC1122給 ? ? ?出的建議值為2分鐘，又如Berkeley體系的TCP實現通常選擇30秒作為MSL值。這意味著TIME_WAIT的典型持續時間為1-4分 ? ? ?鐘。
? ? ? ?TIME_WAIT狀態存在的原因主要有兩點：
? ???? 1）為實現TCP這種全雙工（full-duplex）連接的可靠釋放
? ? ? ?參考本文前面給出的TCP釋放連接4次揮手示意圖，假設發起active close的一方（圖中為client）發送的ACK（4次交互 ? ? ?的最后一個包）在網絡中丟失，那么由于TCP的重傳機制，執行passiveclose的一方（圖中為server）需要重發其FIN，在 ? ? ?該FIN到達client（client是active close發起方）之前，client必須維護這條連接的狀態（盡管它已調用過close），具 ? ? ?體而言，就是這條TCP連接對應的（local_ip, local_port）資源不能被立即釋放或重新分配。直到romete peer重發的FIN ? ? ?達到，client也重發ACK后，該TCP連接才能恢復初始的CLOSED狀態。如果activeclose方不進入TIME_WAIT以維護其連接狀 ? ? ?態，則當passive close方重發的FIN達到時，active close方的TCP傳輸層會以RST包響應對方，這會被對方認為有錯誤發 ? ? ?生（而事實上，這是正常的關閉連接過程，并非異常）。
? ? ? ? 2）為使舊的數據包在網絡因過期而消失
? ? ? ?為說明這個問題，我們先假設TCP協議中不存在TIME_WAIT狀態的限制，再假設當前有一條TCP連接：(local_ip, ? ? ? ? ? local_port, remote_ip,remote_port)，因某些原因，我們先關閉，接著很快以相同的四元組建立一條新連接。本文前面介紹過，TCP連接由四元組唯一標識，因此，在我們假設的情況中，TCP協議棧是無法區分前后兩條TCP連接的不同的，在它看來，這根本就是同一條連接，中間先釋放再建立的過程對其來說是“感知”不到的。這樣就可能發生這樣的情況：前一條TCP連接由local peer發送的數據到達remote peer后，會被該remot peer的TCP傳輸層當做當前TCP連接的正常數據接收并向上傳遞至應用層（而事實上，在我們假設的場景下，這些舊數據到達remote peer前，舊連接已斷開且一條由相同四元組構成的新TCP連接已建立，因此，這些舊數據是不應該被向上傳遞至應用層的），從而引起數據錯亂進而導致各種無法預知的詭異現象。作為一種可靠的傳輸協議，TCP必須在協議層面考慮并避免這種情況的發生，這正是TIME_WAIT狀態存在的第2個原因。
? ? ? ?具體而言，local peer主動調用close后，此時的TCP連接進入TIME_WAIT狀態，處于該狀態下的TCP連接不能立即以同樣的四元組建立新連接，即發起active close的那方占用的local port在TIME_WAIT期間不能再被重新分配。由于TIME_WAIT狀態持續時間為2MSL，這樣保證了舊TCP連接雙工鏈路中的舊數據包均因過期（超過MSL）而消失，此后，就可以用相同的四元組建立一條新連接而不會發生前后兩次連接數據錯亂的情況。

另一比較深入的說法

TIME_WAIT狀態的存在：讓4次握手關閉流程更加可靠；4次握手的最后一個ACK是是由主動關閉方發送出去的，若這個ACK丟失，被動關閉方會再次發一個FIN過來，而此時主動方已經認為斷開鏈接，收不到這個FIN，被動方就會再次發送。若主動關閉方能夠保持一個2MSL的TIME_WAIT狀態，則有更大的機會讓丟失的ACK被再次發送出去。

主動關閉的過程：TIME_WAIT1->TIME_WAIT 2->CLOSED

被動關閉的過程：CLOSE_WAIT->CLOSED

? ? 1、客戶端是調用函數close()，這時，客戶端會發送一個FIN給服務器。 ? ? 2、服務器收到FIN，關閉套接字讀通道，并將自己狀態設置為CLOSE_WAIT（表示被動關閉），并返回一個ACK給客戶端。 ? ? ? 3、客戶端收到ACK，關閉套接字寫通道 ? ? 這是兩次握手，接下來，服務器會調用close() ? ? 1、服務器close()，發送一個FIN到客戶端。 ? ? 2、客戶端收到FIN，關閉讀通道，并將自己狀態設置成TIME_WAIT，發送一個ACK給服務器。 ? ? 3、服務器收到ACK，關閉寫通道，并將自己狀態設置為CLOSE。 ? ? 4、客戶端等待兩個最大數據傳輸時間，然后將自己狀態設置成CLOSED。 TIME_WAIT狀態的作用： ? ? 1、保證全雙工通信可靠關閉：如果不設置TIME_WAIT狀態，直接設置成CLOSED狀態，那么服務器得不到回復，會一直發送FIN給客戶端。 ? ? 2、保證這次連接的重復數據段從網絡中消失。如果不設置，那么最后一個回復的時候，需要建立一個socket，端口號可能跟現在的不一樣，服務器就會認為是另外的端口號發來的，從而出現數據混亂。

總結

以上是生活随笔為你收集整理的网络：TCP通讯之 time_wait 状态的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。