1. 程式人生 > >TCP 三次握手 和 四次揮手

TCP 三次握手 和 四次揮手

概述

我們都知道 TCP 是 可靠的資料傳輸協議,UDP是不可靠傳輸,那麼TCP它是怎麼保證可靠傳輸的呢?那我們就不得不提 TCP 的三次握手和四次揮手。

三次握手

下圖為三次握手的流程圖

下面通過我們 wireshark 抓包工具來分析三次握手
三次握手資料包

第一次握手

建立連線。客戶端傳送連線請求報文段,將SYN位置為1,Sequence Number為x;(x 是隨機生成的一個 int 數值)然後,客戶端進入SYN_SEND狀態,等待伺服器的確認;

第二次握手

伺服器收到SYN報文段。伺服器收到客戶端的SYN報文段,需要對這個SYN報文段進行確認,設定Acknowledgment Number為x+1(Sequence Number+1);同時,自己自己還要傳送SYN請求資訊,將SYN位置為1,Sequence Number為 y (y 是隨機生存的一個 int 數值);伺服器端將上述所有資訊放到一個報文段(即SYN+ACK報文段)中,一併傳送給客戶端,此時伺服器進入SYN_RECV狀態;

第三次握手

客戶端收到伺服器的SYN+ACK報文段。然後將Acknowledgment Number設定為y+1,向伺服器傳送ACK報文段,這個報文段傳送完畢以後,客戶端和伺服器端都進入ESTABLISHED狀態,完成TCP三次握手。

四次揮手

第一次揮手:

Client (可以使客戶端,也可以是伺服器端),設定Sequence Number和Acknowledgment Number,向 Server傳送一個FIN報文段;此時,Client 進入FIN_WAIT_1狀態;這表示 Client 沒有資料要傳送給 Server了;

客戶端傳送第一次揮手後,就不能在向 服務端傳送資料了。

第二次揮手:

Server 收到了 Client 傳送的FIN報文段,向 Client 回一個ACK報文段,Acknowledgment Number 為 Sequence Number 加 1;Client 進入 FIN_WAIT_2 狀態;Server 告訴 Client ,我“同意”你的關閉請求;

Server 第一次響應後,還可以繼續向 Client 傳送資料,這裡只是告訴 Client ,我收到你傳送的關閉請求。

第三次揮手

Server 向 Client 傳送 FIN 報文段,請求關閉連線,同時 Server 進入 CLOSE_WAIT 狀態;

**當 Server 的資料響應完成後,再告訴 Client,我這邊也可以關閉請求了, 這時
Server 就不能再向 Client 傳送資料了**

第四次揮手

Client 收到 Server 傳送的 FIN 報文段,向 Server 傳送 ACK 報文段,然後 Client 進入
TIME_WAIT 狀態;Server 收到 Client 的 ACK 報文段以後,就關閉連線;此時,Client
等待2MSL後依然沒有收到回覆,則證明 Server 端已正常關閉,那好,Client 也可以關閉連線了。

什麼是MSL

MSL是Maximum Segment Lifetime英文的縮寫,中文可以譯為“報文最大生存時間”,他是任何報文在網路上存在的最長時間,超過這個時間報文將被丟棄。因為tcp報文(segment)是ip資料報(datagram)的資料部分,具體稱謂請參見《資料在網路各層中的稱呼》一文,而ip頭中有一個TTL域,TTL是time to live的縮寫,中文可以譯為“生存時間”,這個生存時間是由源主機設定初始值但不是存的具體時間,而是儲存了一個ip資料報可以經過的最大路由數,每經過一個處理他的路由器此值就減1,當此值為0則資料報將被丟棄,同時傳送ICMP報文通知源主機。RFC 793中規定MSL為2分鐘,實際應用中常用的是30秒,1分鐘和2分鐘等。

2MSL即兩倍的MSL,TCP的TIME_WAIT狀態也稱為2MSL等待狀態,當TCP的一端發起主動關閉,在發出最後一個ACK包後,即第3次握手完成後傳送了第四次握手的ACK包後就進入了TIME_WAIT狀態,必須在此狀態上停留兩倍的MSL時間,等待2MSL時間主要目的是怕最後一個ACK包對方沒收到,那麼對方在超時後將重發第三次握手的FIN包,主動關閉端接到重發的FIN包後可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的埠不能使用,要等到2MSL時間結束才可繼續使用。當連線處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設定SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此埠。

TTL與MSL是有關係的但不是簡單的相等的關係,MSL要大於等於TTL。

為什麼要三次握手?

為什麼要三次握手

TCP 建立連線,其實通過兩次握手就可以建立連線了,為什麼要三次呢?是不是多此一舉呢?

1、《計算機網路》中是這樣說的:

為了防止已失效的連線請求報文段突然又傳送到了服務端,因而產生錯誤。
在書中同時舉了一個例子,如下:
已失效的連線請求報文段”的產生在這樣一種情況下:client發出的第一個連線請求報文段並沒有丟失,而是在某個網路結點長時間的滯留了,以致延誤到連線釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後,就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段,同意建立連線。假設不採用“三次握手”,那麼只要server發出確認,新的連線就建立了。由於現在client並沒有發出建立連線的請求,因此不會理睬server的確認,也不會向server傳送資料。但server卻以為新的運輸連線已經建立,並一直等待client發來資料。這樣,server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況,client不會向server的確認發出確認。server由於收不到確認,就知道client並沒有要求建立連線。”

2、網路故障

比如,現在網路出現了故障,只能發請求資料包,而接收不到響應資料包,那麼只要傳送一次請求,伺服器就建立請求,這樣肯定也是不對的,網路請求有來有回才能完成通訊。所以三次握手是必不可少的。

為什麼要四次揮手呢

TCP協議是一種面向連線的、可靠的、基於位元組流的運輸層通訊協議。TCP是全雙工模式,這就意味著,當 Client 發出FIN報文段時,只是表示 Client 已經沒有資料要傳送了,Client 告訴 Server,它的資料已經全部發送完畢了;但是,這個時候 Client 還是可以接受來自 Server 的資料;當 Server 返回ACK報文段時,表示它已經知道 Client 沒有資料傳送了,但是 Server 還是可以傳送資料到 Client 的;當 Server 也傳送了FIN報文段時,這個時候就表示 Server 也沒有資料要傳送了,就會告訴 Client ,我也沒有資料要傳送了,之後彼此就會愉快的中斷這次TCP連線。如果要正確的理解四次分手的原理,就需要了解四次分手過程中的狀態變化。