TCP 三次握手與四次揮手
目錄
TCP與UDP的區(qū)別
TCP 三次握手
為什么需要三次握手？而不是兩次
TCP 四次揮手
為什么需要等待 2MSL
為什么需要四次揮手？而不是三次
1. TCP 與 UDP 的區(qū)別
TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的，可靠的通信協(xié)議，而 UDP（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）是無連接的，不可靠的通信協(xié)議。
它們兩者都是構(gòu)成網(wǎng)絡(luò)運輸層的關(guān)鍵協(xié)議，接下來我們通過一個表格對比二者的區(qū)別：
從表格中我們可以看出，TCP 與 UDP 最大的區(qū)別就在于可靠傳輸。那 TCP 的可靠傳輸是由什么保證的呢？一個很重要的性質(zhì)就是，TCP 是面向連接的通信協(xié)議。
TCP 每次在通信之前，客戶端和服務(wù)端都需要通過發(fā)送數(shù)據(jù)消息，先建立一個穩(wěn)定的傳輸"通道"，然后再進行數(shù)據(jù)傳輸。這個過程我們稱之為"TCP 連接的三次握手"。
2. TCP 三次握手
TCP 三次握手建立連接，是 TCP 數(shù)據(jù)傳輸?shù)谋匾^程。流程大致分為以下幾步：
剛開始，客戶端（Client）和服務(wù)器（Server）都處于 CLOSED 狀態(tài)；
服務(wù)端創(chuàng)建傳輸控制塊（TCB），時刻準備客戶進程的連接請求，處于 LISTEN 監(jiān)聽狀態(tài)；
第一次握手：客戶端將 TCP 報文的標志位 SYN 置為1，隨機產(chǎn)生一個序號值 seq=x 保存在 TCP 首部的序列號字段里，然后指明客戶端打算連接的服務(wù)器端口，并將數(shù)據(jù)包發(fā)送給服務(wù)器端。發(fā)送完畢后，客戶端進入 SYN-SEND 狀態(tài)；
第二次握手：服務(wù)端收到數(shù)據(jù)包后，由標志位 SYN=1 確認了客戶端要請求建立連接。于是，服務(wù)端將 TCP 報文的標志位 SYN 和確認應(yīng)答號 ACK 都置為 1，請求號 ack = x+1（表示序列號為 x 的消息已經(jīng)接收了，下一次傳輸?shù)男蛄刑枮?x+1），再隨機產(chǎn)生一個序號值 seq=y，然后將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求。這時，服務(wù)端進入 SYN-RCVD 狀態(tài)；
第三次握手：客戶端收到服務(wù)端的確認后，檢查 ack 是否為 x+1，ACK 是否為1，如果正確則將確認應(yīng)答 ACK 置為 1，請求號 ack=y+1（表示序列號為 y 的消息已經(jīng)接收了，下一次傳輸?shù)男蛄刑枮?y+1），并將數(shù)據(jù)包發(fā)送給服務(wù)器。服務(wù)器端檢查 ack 是否為 y+1，ACK 是否為 1，如果正確則成功建立連接?？头撕头?wù)器都進入 ESTABLISHED 狀態(tài)，三次握手結(jié)束，客戶端和服務(wù)器可以開始傳輸數(shù)據(jù)了。
在上述過程中，還有一些重要的概念：
半連接：收到 SYN 包而還未收到 ACK 包時的連接狀態(tài)稱為半連接，即尚未完全完成三次握手的 TCP 連接，處于第一次握手之后，第三次握手之前。
半連接隊列：在三次握手協(xié)議中，服務(wù)器維護一個半連接隊列，該隊列為每個客戶端的 SYN 包開設(shè)一個條目，該條目表明服務(wù)器已收到 SYN 包，并向客戶發(fā)出確認，正在等待客戶的確認包。這些條目所標識的連接在服務(wù)器處于 SYN_ RECV 狀態(tài)，當服務(wù)器收到客戶的確認包時，刪除該條目，服務(wù)器進入 ESTABLISHED 狀態(tài)。
3. 為什么三次握手
如上可見，TCP 建立通信連接時，需要進行三次握手。那么，為什么兩次不行呢？舉一個 A-B 撥打電話的場景：
A：你好，我想和你建立通話連接，連接號為 x；
B：好的，可以建立通話連接，連接號為 x；
A：收到，連接號為 x 的連接已經(jīng)建立，我們可以開始通話了。
我們可以發(fā)現(xiàn)，如果只有兩次握手，會發(fā)生比如以下場景：
當客戶端發(fā)出第一次請求連接時，由于網(wǎng)絡(luò)節(jié)點擁堵導(dǎo)致服務(wù)端未收到請求的報文，這時，由于服務(wù)端沒有響應(yīng)，客戶端可能會發(fā)送多次連接請求；
如果沒有三次握手的確認，當之前傳了很久的請求到達服務(wù)端時，服務(wù)器會認為這是一個新的請求，于是建立連接，但是這個 TCP 連接一直不會通信，這樣，服務(wù)端的很多資源就被白白浪費掉了。
結(jié)合上面的電話撥號例子，兩次連接可能出現(xiàn)的問題：
A：你好，我想和你建立通話連接，連接號為 x；
由于信號不穩(wěn)定，這條消息發(fā)了很久 B 都沒收到，于是，A 又重新發(fā)了一條，連接號為 y；
B：好的，可以建立通話連接，連接號為 y；
A：收到，連接號為 y 的連接已經(jīng)建立（自然之前連接號為 x 的連接就不用了），于是開始通話。
這時，之前發(fā)送的 x 連接也發(fā)到了 B 端，如果沒有三次握手，那么 B 可能會誤以為這時 A 又發(fā)起了一個連接。于是，分配好資源，等待連接號為 x 的無效連接傳輸消息。
因此，采用三次握手建立連接可以防止上述問題的出現(xiàn)，當客戶端收到一個已失效的建立連接確認報文時，不會向服務(wù)端進行第三次握手確認。而服務(wù)端由于收不到確認，就不會和客戶端建立連接了。
總結(jié)：三次握手可以防止已失效的連接請求又傳送到服務(wù)器端，導(dǎo)致無效連接的出現(xiàn)，浪費服務(wù)端資源。
4. ?TCP 四次揮手
當數(shù)據(jù)傳輸完成后，為了節(jié)省服務(wù)器的資源和網(wǎng)絡(luò)開銷，需要進行斷連。可以理解為，電話打完了，需要我們手動進行掛電話的操作。
當客戶端（Client，以下簡稱C端）和服務(wù)器（Server，以下簡稱S端）都是連接狀態(tài)時：
第一次揮手：C 端不想再進行數(shù)據(jù)傳輸了，就發(fā)起一條揮手請求，將 TCP 報文的標志位 FIN=1，設(shè)置序列號 seq 為隨機數(shù) x。此時，C 端進入 FIN_WAIT_1 狀態(tài)；
第二次揮手：S 端收到 C 端的 FIN 數(shù)據(jù)報，知道 C 端不再發(fā)送數(shù)據(jù)了。于是返回一條 ACK 確認消息，表示同意 C 端的關(guān)閉請求，然后 S 端進入 CLOSE_WAIT 狀態(tài)。當 C 端收到 S 端的確認消息后，進入 FIN_WAIT_2 狀態(tài)，等待 S 端的連接結(jié)束；
第三次揮手：S 端發(fā)送數(shù)據(jù)完畢后，給 C 端發(fā)送標志位為 FIN 的報文段，請求關(guān)閉連接，并進入 LAST_ACK 狀態(tài)；
第四次揮手：當 C 端收到 FIN 報文段之后，再向 S 端回復(fù)標志位為 ACK 的應(yīng)答消息，然后進入 TIME_WAIT 狀態(tài)，當?shù)却?2MSL（報文的最大存活時間，后面會詳細講解） 后還沒收到回復(fù)，證明 S 端已經(jīng)正常關(guān)閉，于是 C 端進入CLOSED 狀態(tài)。而 S 端在收到 C 端的 ACK 報文段以后，就關(guān)閉連接，直接進入 CLOSED 狀態(tài)。
和我們的電話通話不同，TCP 連接是全雙工的，也就是在通信的時候允許數(shù)據(jù)在兩個方向上同時傳輸?？梢岳斫鉃槭请娫?電話留言，兩邊都需要掛電話才會結(jié)束通訊過程，整個流程可以看成是如下場景：
A：我不想說話了，掛電話了哈；
B：好的，你先掛電話，但是我還有話要說；
A：收到了掛電話的請求應(yīng)答，于是把電話掛了。這時 A 除了做應(yīng)答以外不能再說話（傳輸真實數(shù)據(jù)），但是可以聽到聲音（接收數(shù)據(jù)）；
B：我也不想說話了，掛電話了哈；
A：好的，已收到，等待一會兒就把電話掛了；
B：收到掛電話的請求應(yīng)答后，把手機關(guān)掉了。 A 過了一會兒，發(fā)現(xiàn) B 確實把電話掛了，于是也關(guān)了手機，通訊結(jié)束。
5. 為什么要等待 2MSL
Max Segment Lifetime（簡稱 MSL），指報文的最大存活時間，它是任何報文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長時間。
從上面斷連的第四次揮手階段，我們發(fā)現(xiàn)客戶端在收到服務(wù)端的斷連請求后，還等待了 2MSL 才變?yōu)?CLOSED 狀態(tài)。這是為什么呢？
1）可以保證 TCP 的全雙工連接能夠可靠關(guān)閉
由于 IP 協(xié)議的不可靠性或者其它網(wǎng)絡(luò)原因，導(dǎo)致 S 端沒有收到 C 端的 ACK 報文，那么 S 端就會在超時后重新發(fā)送 FIN，如果此時 C 端的連接已經(jīng)關(guān)閉處于 CLOSED 狀態(tài)，那么重發(fā)的 FIN 就找不到對應(yīng)的連接了，從而導(dǎo)致連接錯亂。
因此，C 端發(fā)送完最后的 ACK 不能直接進入 CLOSED 狀態(tài)，而要保持 TIME_WAIT，等待可能重傳的 FIN 報文，保證對方能收到 ACK。
2）保證此處連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失
如果 C 端發(fā)送最后的 ACK 后直接進入 CLOSED 狀態(tài)，然后再向 S 端發(fā)起一個新連接，這時無法保證新連接與剛關(guān)閉連接的端口號是不同的，就可能出現(xiàn)問題：如果前一次連接的某些數(shù)據(jù)滯留在網(wǎng)絡(luò)中，這些延遲數(shù)據(jù)在建立新連接后到達 C 端，由于新老接口的端口號和 IP 都一樣，TCP 協(xié)議就認為延遲數(shù)據(jù)是屬于新連接的，新連接就會收到臟數(shù)據(jù)，導(dǎo)致數(shù)據(jù)包混亂。
所以，TCP 連接需要在 TIME_WAIT 狀態(tài)等待 2 倍 MSL，保證本次連接的所有數(shù)據(jù)在網(wǎng)絡(luò)中消失。
6. 為什么四次揮手
建立連接時當 Server 收到 Client 端的 SYN 連接請求時，可以直接發(fā)送帶有同步標志位 SYN 和確認應(yīng)答號 ACK 的報文，所以建立連接只需要三次握手。
由于 TCP 是全雙工模式，這就意味著關(guān)閉連接時，當 C 端發(fā)出 FIN 報文段時，只是表示 C 端的數(shù)據(jù)已經(jīng)發(fā)送完畢了，但 S 端還是可以發(fā)送數(shù)據(jù)到 C 端的。
因此，S 端很可能不會立即關(guān)閉 SOCKET，故 S 端數(shù)據(jù)發(fā)送完畢后就需要 "第四次揮手" 另外發(fā)送報文段通知 C 端去斷開連接。
