TCP的三次握手與四次揮手詳解

所謂三次握手(Three-way Handshake)，是指建立一個TCP連接時，需要客戶端和服務器總共發送3個報文。

三次握手的目的是連接服務器指定端口，建立 TCP 連接，並同步連接雙方的序列號和確認號，交換 TCP 窗口大小信息。在 socket 編程中，客戶端執行 connect() 時。將觸發三次握手。

第一次握手：

客戶端將TCP報文標誌位SYN置為1，隨機產生一個序號值seq=J，保存在TCP首部的序列號(Sequence Number)字段裡， 指明客戶端打算連接的服務器的端口，並將該數據包發送給服務器端，發送完畢後，客戶端進入SYN_SENT狀態，等待服務器端確認。

第二次握手：

服務器端收到數據包後由標誌位SYN=1知道客戶端請求建立連接，服務器端將TCP報文標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個序號值seq=K，並將該數據包發送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態。

第三次握手：

客戶端收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該數據包發送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務器端之間可以開始傳輸數據了。

注意:我們上面寫的ack和ACK，不是同一個概念：

小寫的ack代表的是頭部的確認號Acknowledge number， 縮寫ack，是對上一個包的序號進行確認的號，ack=seq+1。 大寫的ACK，則是我們上面說的TCP首部的標誌位，用於標誌的TCP包是否對上一個包進行了確認操作，如果確認了，則把ACK標誌位設置成1。

三次握手過程的示意圖如下：

sequenceDiagram
    participant c as client
    participant s as server
    c->>s: 1.SYN=1,seq=J,請求建立連接
    activate c
    c-->>c: SYN_SENT
    deactivate c
    activate s
    s-->>s: SYN_RECEIVED
    s->>c: 2.SYN=1,seq=K,ACK=1,ack=J+1
    deactivate s
    activate c
    c-->>c: ESTABLISHED
    c->>s: 3.ACK=1,seq=J+1,ack=K+1
    deactivate c
    activate s
    s-->>s: ESTABLISHED
    deactivate s
    Note over c,s: 數據傳輸

為什麼需要三次握手？

我們假設client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。

本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。

假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。

所以，採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。 server由於收不到確認，就知道client並沒有要求建立連接。

TCP 四次揮手關閉連接

四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發。 由於TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉。

揮手請求可以是Client端，也可以是Server端發起的，我們假設是Client端發起：

第一次揮手：

Client端發起揮手請求，向Server端發送標誌位是FIN報文段，設置序列號seq，此時，Client端進入FIN_WAIT_1狀態，這表示Client端沒有數據要發送給Server端了。

第二次揮手:

Server端收到了Client端發送的FIN報文段，向Client端返回一個標誌位是ACK的報文段，ack設為seq加1，Client端進入FIN_WAIT_2狀態，Server端告訴Client端，我確認並同意你的關閉請求。

第三次揮手:

Server端向Client端發送標誌位是FIN的報文段，請求關閉連接，同時Server端進入LAST_ACK狀態。

第四次揮手:

Client端收到Server端發送的FIN報文段，向Server端發送標誌位是ACK的報文段，然後Client端進入TIME_WAIT狀態。 Server端收到Client端的ACK報文段以後，就關閉連接。此時，Client端等待2MSL的時間後依然沒有收到回复，則證明Server端已正常關閉，那好，Client端也可以關閉連接了。

四次揮手過程的示意圖如下：

sequenceDiagram
    participant c as client
    participant s as server
    c->>s: 1.FIN=M,請求斷開連接
    activate c
    c-->>c: FIN_WAIT_1
    deactivate c
    activate s
    s-->>s: CLOSE_WAIT
    s->>c: 2.ack=M+1
    deactivate s
    activate c
    c-->>c: FIN_WAIt_2
    deactivate c
    s->>c: 3.FIN=N,請求斷開連接
    activate s
    s-->>s: LAST_ACK
    deactivate s
    c->>s: 4.ACK=1,ack=N+1
    activate c
    activate s
    s-->>s: CLOSED
    deactivate s
    c-->>c: TIME_WAIT
    c-->>c: CLOSED
    deactivate c
    

為什麼連接的時候是三次握手，關閉的時候卻是四次握手？

建立連接時因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。所以建立連接只需要三次握手。

由於TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議，TCP是全雙工模式。 這就意味著，關閉連接時，當Client端發出FIN報文段時，只是表示Client端告訴Server端數據已經發送完畢了。當Server端收到FIN報文並返回ACK報文段，表示它已經知道Client端沒有數據發送了，但是Server端還是可以發送數據到Client端的，所以Server很可能並不會立即關閉SOCKET，直到Server端把數據也發送完畢。 當Server端也發送了FIN報文段時，這個時候就表示Server端也沒有數據要發送了，就會告訴Client端，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接

為什麼要等待2MSL？

MSL：報文段最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間。

有以下兩個原因：

第一點：保證TCP協議的全雙工連接能夠可靠關閉： 由於IP協議的不可靠性或者是其它網絡原因，導致了Server端沒有收到Client端的ACK報文，那麼Server端就會在超時之後重新發送FIN，如果此時Client端的連接已經關閉處於CLOESD狀態，那麼重發的FIN就找不到對應的連接了，從而導致連接錯亂，所以，Client端發送完最後的ACK不能直接進入CLOSED狀態，而要保持TIME_WAIT，當再次收到FIN的收，能夠保證對方收到ACK，最後正確關閉連接。

第二點：保證這次連接的重複數據段從網絡中消失 如果Client端發送最後的ACK直接進入CLOSED狀態，然後又再向Server端發起一個新連接，這時不能保證新連接的與剛關閉的連接的端口號是不同的，也就是新連接和老連接的端口號可能一樣了，那麼就可能出現問題：如果前一次的連接某些數據滯留在網絡中，這些延遲數據在建立新連接後到達Client端，由於新老連接的端口號和IP都一樣，TCP協議就認為延遲數據是屬於新連接的，新連接就會接收到臟數據，這樣就會導致數據包混亂。所以TCP連接需要在TIME_WAIT狀態等待2倍MSL，才能保證本次連接的所有數據在網絡中消失。