1. 程式人生 > >TCP的三次握手與四次揮手過程,各個狀態名稱與含義 三次握手(轉載)

TCP的三次握手與四次揮手過程,各個狀態名稱與含義 三次握手(轉載)

TCP的三次握手與四次揮手過程,各個狀態名稱與含義 三次握手

第一次握手:主機A傳送位碼為syn=1,隨機產生seq number=10001的資料包到伺服器,主機B由SYN=1知道,A要求建立聯機,此時狀態為SYN_SENT; 第二次握手:主機B收到請求後要確認聯機資訊,向A傳送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=20001的包,此時狀態由LISTEN變為SYN_RECV; 第三次握手:主機A收到後檢查ack number是否正確,即第一次傳送的seq number+1,以及位碼ack是否為1,若正確,主機A會再發送ack number=(主機B的seq+1),ack=1,主機B收到後確認seq值與ack=1則連線建立成功,雙方狀態ESTABLISHED。

完成三次握手,主機A與主機B開始傳送資料

各個狀態名稱與含義

CLOSED: 這個沒什麼好說的了,表示初始狀態。 LISTEN: 這個也是非常容易理解的一個狀態,表示伺服器端的某個SOCKET處於監聽狀態,可以接受連線了。 SYN_RECV: 這個狀態表示接受到了SYN報文,在正常情況下,這個狀態是伺服器端的SOCKET在建立TCP連線時的三次握手會話過程中的一箇中間狀態,很短暫,基本 上用netstat你是很難看到這種狀態的,除非你特意寫了一個客戶端測試程式,故意將三次TCP握手過程中最後一個ACK報文不予傳送。因此這種狀態 時,當收到客戶端的ACK報文後,它會進入到ESTABLISHED狀態。 SYN_SENT: 這個狀態與SYN_RECV遙想呼應,當客戶端SOCKET執行CONNECT連線時,它首先發送SYN報文,因此也隨即它會進入到了SYN_SENT狀 態,並等待服務端的傳送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已傳送SYN報文。 ESTABLISHED:這個容易理解了,表示連線已經建立了。

四次揮手 img

FIN_WAIT_1: 這個狀態要好好解釋一下,其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是:FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時,它想主動關閉連線,向對方傳送了FIN報文,此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後,則進入到FIN_WAIT_2狀態,當然在實際的正常情況下,無論對方何種情況下,都應該馬 上回應ACK報文,所以FIN_WAIT_1狀態一般是比較難見到的,而FIN_WAIT_2狀態還有時常常可以用netstat看到。 FIN_WAIT_2:上面已經詳細解釋了這種狀態,實際上FIN_WAIT_2狀態下的SOCKET,表示半連線,也即有一方要求close連線,但另外還告訴對方,我暫時還有點資料需要傳送給你,稍後再關閉連線。 TIME_WAIT: 表示收到了對方的FIN報文,併發送出了ACK報文,就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下,收到了對方同時帶 FIN標誌和ACK標誌的報文時,可以直接進入到TIME_WAIT狀態,而無須經過FIN_WAIT_2狀態。 CLOSING: 這種狀態比較特殊,實際情況中應該是很少見,屬於一種比較罕見的例外狀態。正常情況下,當你傳送FIN報文後,按理來說是應該先收到(或同時收到)對方的 ACK報文,再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後,並沒有收到對方的ACK報文,反而卻也收到了對方的FIN報文。什 麼情況下會出現此種情況呢?其實細想一下,也不難得出結論:那就是如果雙方几乎在同時close一個SOCKET的話,那麼就出現了雙方同時傳送FIN報 文的情況,也即會出現CLOSING狀態,表示雙方都正在關閉SOCKET連線。 CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢?當對方close一個SOCKET後傳送FIN報文給自己,你係統毫無疑問地會迴應一個ACK報文給對 方,此時則進入到CLOSE_WAIT狀態。接下來呢,實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方,如果沒有的話,那麼你也就可以 close這個SOCKET,傳送FIN報文給對方,也即關閉連線。所以你在CLOSE_WAIT狀態下,需要完成的事情是等待你去關閉連線。 LAST_ACK: 這個狀態還是比較容易好理解的,它是被動關閉一方在傳送FIN報文後,最後等待對方的ACK報文。當收到ACK報文後,也即可以進入到CLOSED可用狀態了。

為什麼建立連線協議是三次握手,而關閉連線卻是四次握手呢? 這 是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求後,它可以把ACK和SYN(ACK起應答作用,而SYN起同步作用)放在一 個報文裡來發送。但關閉連線時,當收到對方的FIN報文通知時,它僅僅表示對方沒有資料傳送給你了;但未必你所有的資料都全部發送給對方了,所以你可以未 必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後,再發送FIN報文給對方來表示你同意現在可以關閉連線了,所以它這裡的ACK報文 和FIN報文多數情況下都是分開發送的。

為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態? 因為雖然雙方都同意關閉連線了,而且握手的4個報文也都發送完畢,按理可以直接回到CLOSED 狀態(就好比從SYN_SENT 狀態到ESTABLISH 狀態那樣),但是我們必須假想網路是不可靠的,你無法保證你(客戶端)最後傳送的ACK報文一定會被對方收到,就是說對方處於LAST_ACK 狀態下的SOCKET可能會因為超時未收到ACK報文,而重發FIN報文,所以這個TIME_WAIT 狀態的作用就是用來重發可能丟失的ACK報文。

關閉TCP連線一定需要4次揮手嗎? 不一定,4次揮手關閉TCP連線是最安全的做法。但在有些時候,我們不喜歡TIME_WAIT 狀態(如當MSL數值設定過大導致伺服器端有太多TIME_WAIT狀態的TCP連線,減少這些條目數可以更快地關閉連線,為新連線釋放更多資源),這時我們可以通過設定SOCKET變數的SO_LINGER標誌來避免SOCKET在close()之後進入TIME_WAIT狀態,這時將通過傳送RST強制終止TCP連線(取代正常的TCP四次握手的終止方式)。但這並不是一個很好的主意,TIME_WAIT 對於我們來說往往是有利的。