三次握手，四次揮手，原來TCP這么有禮貌！

我們在和他人談話時，需要遵循一定的規(guī)則，比如確保對方能聽懂我的語言。如果跟一個不懂中文的外國人說中文，是不可能很好地進行交流的。

計算機之間的通信也是如此，必須遵循一定的規(guī)則才能順利“交流”。

TCP與UDP是什么

在TCP/IP協(xié)議棧（互聯(lián)網(wǎng)協(xié)議系列）中，TCP（Transmission Control Protocol ，傳輸控制協(xié)議）與UDP（User Datagram Protocol ，用戶數(shù)據(jù)報協(xié)議）是傳輸層中的兩種協(xié)議，我們平時刷視頻、打游戲、看新聞等都要通過這兩種協(xié)議進行數(shù)據(jù)傳輸。

那么這兩種協(xié)議有什么區(qū)別呢？

看完上面的表格，是不是還是有點懵，下面小編用一個比喻來告訴你二者究竟有什么不同。

我們把兩個應用之間的通信當作是兩個人在通信，在不考慮時間因素的前提下，我們把TCP看成是打電話，把UDP看成是寫信。

兩個人打電話時，需要提前撥通對方的電話，這就是需要建立連接；通話過程中，雙方能及時確認消息，如果聽不清楚可以要求對方重新說一次，這就是安全可靠。

寫信只需要根據(jù)地址把信發(fā)出去，這就是不需要建立連接；發(fā)出去的信也不知道對方能否收到，這就是不可靠。

TCP為了保證傳輸文件的完整性，會根據(jù)接收方的接收速率控制發(fā)送方的發(fā)送速率，即實行流量控制，所以TCP的傳輸速度低于UDP。

這兩種協(xié)議不存在哪個好哪個差，都有著各自適合的應用場景。

比如傳輸文件時對速度沒有要求，但是必須保證文件完整送達，沒有數(shù)據(jù)丟失，這時就應該采用TCP協(xié)議，而我們在視頻聊天時，時效性要求高而準確性要求略低，這時就采用UDP協(xié)議。

TCP是面向連接的協(xié)議，正如打電話時需要提前撥通電話，結束通話后需要掛斷電話，那么TCP是如何建立連接與斷開連接的呢？

計算機之間的通信也是如此，必須遵循一定的規(guī)則才能順利“交流”。

TCP的三次握手

在傳輸數(shù)據(jù)前，兩臺主機需要通過三次會話建立連接，這個過程我們稱為三次握手。

第一次握手：客戶端向服務端請求建立連接，

SYN=1（建立連接），

seq=x（序列號），

客戶端進入SYN_SENT狀態(tài)。

第二次握手：服務端向客戶端返回確認并請求建立連接，

SYN=1（建立連接），

ACK=1 （已收到），

ack=x+1（確認號為收到的序列號加一），

seq=y（序列號），

服務端進入SYN_RCVD狀態(tài)。

第三次握手：客戶端向服務端發(fā)送確認報文，

ACK=1 （已收到），

ack=y+1（確認號為收到的序列號加一），

seq=x+1（序列號），

三次握手完成以后，2個主機之間，就可以傳輸數(shù)據(jù)啦~

TCP的四次揮手

當數(shù)據(jù)傳輸完成后，兩臺主機需要通過四次會話斷開連接，這個過程我們稱為四次揮手。

第一次揮手：客戶端向服務端請求斷開連接，

FIN=1（斷開連接），

seq=u（序列號），

客戶端進入FIN_WAIT_1狀態(tài)。

第二次揮手：服務端向客戶端返回確認報文，

ACK=1 （已收到），

ack=u+1（確認號為收到的序列號加一），

seq=v（序列號），

服務端進入CLOSE_WAIT狀態(tài)，客戶端進入FIN_WAIT_2狀態(tài)。

第三次揮手：服務端完成數(shù)據(jù)傳輸后，向客戶端發(fā)送斷開連接請求，

FIN=1（斷開連接），

ACK=1 （已收到），

ack=u+1（確認號為收到的序列號加一），

seq=w（序列號），

服務端進入LAST_ACK狀態(tài)。

第四次揮手：客戶端向服務端返回確認報文，

ACK=1 （已收到），

ack=w+1（確認號為收到的序列號加一），

seq=u+1（序列號），

客戶端進入TIME_WAIT狀態(tài)，服務端進入CLOSED狀態(tài)。

客戶端處于TIME_WAIT狀態(tài)時，TCP連接還未釋放掉，等待2個MSL（Maximum Segment Lifetime，最大段生命周期）的時長后，客戶端進入CLOSE狀態(tài)。

看到這里，相信大家還有些疑問，下面就由小編來一一解答。

為什么是三次握手，兩次握手或者四次握手不可以嗎？

如果是兩次握手，就可能出現(xiàn)下面這種情況。

客戶端發(fā)送建立連接請求，由于網(wǎng)絡擁塞，遲遲沒有得到回應。客戶端再次發(fā)送連接請求，服務端回應，連接建立。

一段時間后，客戶端第一次發(fā)送的連接請求到達服務端，服務端以為客戶端重新請求建立連接（其實并沒有），此時服務端會返回響應報文并一直處于待連接狀態(tài)，這就造成了資源浪費，如下圖所示。

那為什么不是四次握手呢？

四次握手也能達到三次握手的效果，也就是將原本的第二次握手拆分成兩次，一次發(fā)送確認報文，一次分開發(fā)送請求建立連接報文，但這同樣造成了資源浪費，如下圖所示。所以最終確定通過三次握手建立連接。

為什么是四次揮手，三次揮手不可以嗎？

不可以。當客戶端發(fā)送斷開連接請求后停止發(fā)送數(shù)據(jù)（客戶端還能接收數(shù)據(jù)），有可能此時服務端還有數(shù)據(jù)需要發(fā)給客戶端，所以它先回一個確認報文，等發(fā)送完所有數(shù)據(jù)，再發(fā)送斷開連接的報文，通知客戶端可以斷開連接了。

四次揮手結束后，為什么客戶端沒有立刻關閉呢？

客戶端沒有立刻關閉，而是進入TIME_WAIT狀態(tài)，等待2個MSL的時長后，客戶端才進入CLOSE狀態(tài)，這是為了確保第四次揮手的確認消息到達服務端。

如果服務端在規(guī)定時間內(nèi)未收到最后的確認消息，會重新進行第三次揮手請求斷開連接，客戶端重新發(fā)送確認消息，如下圖所示。

MSL是報文的最長生存時間，2個MSL是在網(wǎng)絡中來回兩個報文所需要的最長時間，如果超過這個時間，客戶端沒有重新收到斷開連接的請求，說明四次揮手順利完成，可以斷開連接了。

總結

今天的內(nèi)容就到這里了，和小編一起復習一下今天的內(nèi)容吧：

TCP和UDP是傳輸層中的兩種協(xié)議，TCP安全可靠但傳輸速度慢，UDP傳速度快但可能丟失數(shù)據(jù)，這兩種協(xié)議各有優(yōu)勢，適合不同的應用場景。

兩臺主機建立連接和斷開連接的過程被稱為“三次握手”和“四次揮手”。

了解了為什么一定是三次握手和四次揮手。

相信通過今天的學習，以后被問到TCP和UDP的相關問題，大家都能侃侃而談了。如果大家對TCP和UDP還有新的認識，歡迎在評論區(qū)留言。