概述

我們都知道 TCP 是 可靠的數據傳輸協議，UDP是不可靠傳輸，那么TCP它是怎么保證可靠傳輸的呢？那我們就不得不提 TCP 的三次握手和四次揮手。

三次握手

下圖為三次握手的流程圖

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

第一次握手

建立連接?？蛻舳税l送連接請求報文段，將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并沒有要求建立連接?！?/p>

2、網絡故障

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

為什么要四次揮手呢

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

---

想了解更多精彩內容請關注我的公眾號

本人簡書blog地址：http://www.jianshu.com/u/1f0067e24ff8????
點擊這里快速進入簡書
GIT地址：http://git.oschina.net/brucekankan/
點擊這里快速進入GIT

總結

以上是生活随笔為你收集整理的TCP 三次握手 和 四次挥手的全部內容，希望文章能夠幫你解決所遇到的問題。

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