[tcp] tcp中11種狀態詳解

前言
很早之前，去面試，面試官問我，tcp鏈接一共有多少種狀態以及各狀態的含義。我一臉懵逼，我知道一些狀態，如LISTEN、TIME_WAIT等，但沒有關注過總共有多少種狀態，更別說每種狀態的意義了，後面爲了面試詳細看了下tcp協議狀態，雖然當時記住了(其實也只是粗略的知道)，後面老是會忘記，又去搜索，如今將其記下

TCP三次握手和四次揮手

tcp11中狀態及變遷其實基本包含在正常的三次握手和四次揮手中，除開CLOSING

tcp正常三次握手

從圖片流程看，正常的三次握手從服務端打開監聽監聽(LISTEN)->客戶端先發起SYN請求->服務端發起SYN及ACK確認->客戶端再確認即三次握手TCP鏈接成功

而三次握手裏面也包含tcp其中四種狀態及變遷

LISTEN
服務端狀態，應用程序打開監聽端口，處理來自客戶端TCP端口的鏈接請求

SYN_SENT
客戶端狀態，當客戶端經過應用程序connect()鏈接時，客戶端TCP發送SYN請求主動創建鏈接，此時狀態爲SYN_SENT

SYN_RECV
服務端狀態，當收到客戶端SYN請求後，服務端會發送一個SYN鏈接請求及ACK確認到客戶端，再等待對方鏈接請求確認，這時狀態爲SYN_RECV，若是發現有不少SYN_RCVD狀態，可能受到了SYN FLood的Dos攻擊

ESTABLISHED
當客戶端回覆正確的ack值後，就創建一個打開的鏈接，客戶端和服務端就都進入ESTABLISHED狀態，此時即可以PSH數據

tcp正常四次揮手

從圖片流程看，正常的四次握手包含6種tcp狀態變遷
如主動發起關閉方爲客戶端
客戶端發送FIN進入FIN_WAIT1 -> 服務端發送ACK確認並進入CLOSE_WAIT(被動關閉)狀態->客戶端收到ACK確認後進入FIN_WAIT2狀態 -> 服務端再發送FIN進入LAST_ACK狀態 -> 客戶端收到服務端的FIN後發送ACK確認進入TIME_WAIT狀態 -> 服務端收到ACK確認後進入CLOSED狀態斷開鏈接 -> 客戶端在等待2MSL的時間若是期間沒有收到服務端的相關包請求，則進入CLOSED狀態斷開鏈接

FIN_WAIT1
客戶端調用close()關閉鏈接後，TCP發出FIN請求主動關閉鏈接，而後進入FIN_WAIT1狀態
等待遠程TCP鏈接中斷請求或者確認

CLOSE_WAIT
被動關閉狀態，TCP接收到FIN後，就發送ack迴應客戶端的FIN請求，而後就進入了CLOSE_WAIT狀態

FIN_WAIT2
半關閉狀態，主動關閉端(也就是客戶端調用close()後)接收到ack確認後，此時進入FIN_WAIT2狀態，該狀態下，客戶端應用程序依然能接收數據

LAST_ACK
服務端發送確認中斷後，也發送FIN關閉請求，而後進入LAST_ACK最後確認關閉狀態

TIME_WAIT
在主動關閉端接收到FIN後，TCP就發送ACK，並進入TIME-WAIT狀態，該狀態持保持由內核參數net.ipv4.tcp_keepalive_time控制時間，默認爲2小時，以後主動關閉方也進入CLOSED狀態關閉鏈接

CLOSED
TCP鏈接關閉，被動關閉端在接收到ack包後，進入CLOSED狀態關閉TCP鏈接

CLOSING狀態

CLOSING狀態通常較少出現，這種是客戶端和服務端同時發起了FIN主動請求關閉。如客戶端發送FIN主動關閉，可是沒有收到服務端發來的ACK確認，而是先收到了服務端發來的FIN請求關閉鏈接，因此必須是同時

在進入CLOSING狀態後，只要收到了對方對本身發送的FIN的ACK，收到FIN的ACK確認就進入TIME_WAIT狀態，所以，若是RTT(Round Trip Time TCP包的往返延時)處在一個可接受的範圍內，發出的FIN會很快被ACK從而進入到TIME_WAIT狀態，CLOSING狀態持續的時間就特別短，所以很難看到這種狀態