【面試必考】TCP協(xié)議“三次握手”與“四次揮手”

時間：2020-06-15 09:37:47

關(guān)鍵字： TCP

手機(jī)看文章

掃描二維碼
隨時隨地手機(jī)看文章

[導(dǎo)讀]引言從上一篇文章我們就知道TCP協(xié)議是提供面向連接的服務(wù)，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立連接，俗稱“握手”，數(shù)據(jù)傳送完成后要終止連接，俗稱“揮手”。因此TCP是一種可靠的傳輸服務(wù)，但是正因為這樣，也不可避免的增加了許多額

引言

從上一篇文章我們就知道TCP協(xié)議是提供面向連接的服務(wù)，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立連接，俗稱“握手”，數(shù)據(jù)傳送完成后要終止連接，俗稱“揮手”。因此TCP是一種可靠的傳輸服務(wù)，但是正因為這樣，也不可避免的增加了許多額外的開銷，比如確認(rèn)，流量控制等，那么我們今天就來說說它是怎么建立連接與終止連接的！

“三次握手”

首先建立連接的過程是由客戶端發(fā)起，而服務(wù)器無時無刻都在等待著客戶端的連接（服務(wù)器處于監(jiān)聽狀態(tài)listen），TCP連接一般來說會經(jīng)歷以下過程，先來看個GIF圖：

三次握手(圖片來源網(wǎng)絡(luò))

第一步：客戶端的TCP首先向服務(wù)器端的TCP發(fā)送一個特殊的TCP報文段。該報文段中不包含任何應(yīng)用層的數(shù)據(jù)，但是在報文段的首部中的SYN標(biāo)志位會被置為1。因此，這個特殊報文段被稱為SYN 報文段（握手請求報文）。另外，客戶端會隨機(jī)地選擇一個初始序號（ISN，假設(shè)為 x，如動態(tài)圖），并將此序號放置于該SYN報文段的序號字段 sqe中；但握手請求報文報文段中的ACK標(biāo)志為0，所以此時它的確認(rèn)序號 ack是無效的，是什么值我們也不用管。握手請求報文會被封裝在一個IP數(shù)據(jù)報中，然后發(fā)送給服務(wù)器。此時，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號
第二步：服務(wù)器收到了客戶端發(fā)出的SYN報文段，服務(wù)器便會從SYN報文段中提取對應(yīng)的信息，為該TCP連接分配TCP緩存和變量來維護(hù)這個鏈接，（當(dāng)然啦，這服務(wù)器必須得有內(nèi)存來響應(yīng)這個鏈接，很多時候服務(wù)器被攻擊時就沒空搭理這個鏈接了），并向該客戶端返回一個允許連接的報文段（握手應(yīng)答報文）。此時，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)，這個報文段同樣也不包含任何應(yīng)用層數(shù)據(jù)，但是，在報文段的首部卻包含3個重要的信息。

SYN 與 ACK 標(biāo)志都被置為 1。
將TCP報文段首部的確認(rèn)序號 ack字段設(shè)置為 x+1，這個 x 是從握手請求報文中得到的。
服務(wù)器也會隨機(jī)選擇自己的初始序號ISN，注意此ISN是服務(wù)器端的ISN，假設(shè)為y，并將它放置到TCP報文段首部的序號字段中。

這個允許連接的報文段實際上表明了：“我收到了你發(fā)起建立連接的請求，初始序號為x，我同意建立該TCP連接，我自己的初始序號是y，確認(rèn)序號是 x+1”。該允許連接的報文段有時會被稱為SYN ACK報文段（SYN ACK segment），由于ACK標(biāo)志位1，所以TCP報文段首部的窗口大小字段是有效的。TCP規(guī)定這個SYN ACK報文段也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號。

第三步：當(dāng)客戶端收到服務(wù)器的握手應(yīng)答報文后，還要給服務(wù)器返回一個應(yīng)答報文 ，表示已經(jīng)收到服務(wù)器的握手應(yīng)答報文，應(yīng)答報文中客戶端會將ACK標(biāo)志置1，此時，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)，而對于SYN標(biāo)志，因為連接已經(jīng)建立了，所以SYN標(biāo)志會被置為0，同時客戶端也要給該TCP連接分配緩存和變量來維護(hù)這個鏈接，將TCP報文段首部的確認(rèn)序號字段設(shè)置為y+1，同時也將客戶端自己的窗口大小告訴服務(wù)器。在握手的第三個階段可以在報文段中攜帶數(shù)據(jù)，TCP規(guī)定，這個ACK報文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號。

在完成握手后，客戶端與服務(wù)器就建立了連接，同時雙方都得到了彼此的窗口大小，序號等信息，然后客戶端就可以和服務(wù)器開心地傳輸數(shù)據(jù)了，在鏈接過程中這些傳輸數(shù)據(jù)都是平等的，任何一方都可以隨意傳輸數(shù)據(jù)到另一方，在傳輸TCP報文段的時候，每個TCP報文段首部的SYN標(biāo)志都會被置0，因為它只用于發(fā)起連接，同步序號。

“四次揮手”

建立一個連接需要三次握手，而終止一個連接則需要經(jīng)過 四次揮手，這由 TCP的特性造成的，因為 TCP協(xié)議可以提供全雙工的傳輸服務(wù)，因此每個方向上的連接必須單獨關(guān)閉。當(dāng)客戶端完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個 FIN報文段（終止連接請求報文段）來終止<客戶端 -> 服務(wù)器>方向上的連接。當(dāng)服務(wù)器收到一個 FIN報文段時，它必須通知應(yīng)用層客戶端已經(jīng)終止了<客戶端 -> 服務(wù)器>方向的連接，服務(wù)器一般也會選擇關(guān)閉<服務(wù)器 -> 客戶端>方向的連接。

一般來說，服務(wù)器是貪婪的，幾乎不會主動斷開<服務(wù)器 -> 客戶端>方向的連接，所以很多時候都是客戶端主動斷開連接?？蛻舳税l(fā)送一個FIN報文段只意味著在這一<客戶端 -> 服務(wù)器>方向上沒有數(shù)據(jù)流動，而<服務(wù)器 -> 客戶端>方向的連接仍是有效的，但是在實際應(yīng)用中只有很少的 TCP應(yīng)用程序才這樣做。

四次揮手過程如下（有一個GIF上傳不了，就算了）：

客戶端發(fā)出一個FIN報文段主動進(jìn)行關(guān)閉連接，此時報文段的FIN標(biāo)志位為1，假設(shè)序號為u，一般來說ACK標(biāo)志也會被置一，但此時確認(rèn)序號字段是無效的（因為FIN標(biāo)志位為1），此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)（關(guān)于TCP協(xié)議狀態(tài)的內(nèi)容到時候再慢慢講吧，有點復(fù)雜）。TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。
當(dāng)服務(wù)器收到這個 FIN報文段，它發(fā)回一個ACK報文段（此報文段是終止連接應(yīng)答），確認(rèn)序號為u+1，并且?guī)献约旱男蛱杤，和SYN一樣，一個FIN將占用一個序號，此時已經(jīng)斷開<客戶端 -> 服務(wù)器>的方向連接，但<服務(wù)器 -> 客戶端>方向的連接仍然存在，并且服務(wù)器可以發(fā)送數(shù)據(jù)給客戶端，客戶端也必須接受這些數(shù)據(jù)，這時候服務(wù)器處于半關(guān)閉狀態(tài)（CLOSE-WAIT），客戶端收到服務(wù)器發(fā)送的ACK報文段后處于FIN-WAIT-2（終止等待2）狀態(tài)。
一般來說服務(wù)器會向應(yīng)用程序請求關(guān)閉與這個客戶端的連接，接著服務(wù)器就會發(fā)送一個FIN報文段（這個報文段是服務(wù)器向客戶端發(fā)出，請求終止連接），此時假設(shè)序號為w，ACK標(biāo)志雖然也為1，但是確認(rèn)序號字段也是無效的，此時，服務(wù)器則進(jìn)入LAST_ACK狀態(tài)（服務(wù)器等待對方接受關(guān)閉連接）。
客戶端返回一個ACK報文段來確認(rèn)終止（服務(wù)器的）連接的請求，ACK標(biāo)志置一，并將確認(rèn)序號設(shè)置為收到序號加1（w+1），此時斷開<`服務(wù)器 -> 客戶端 >方向上的連接。此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2*MSL（最長報文段壽命）的時間后，才進(jìn)入CLOSED狀態(tài)。而服務(wù)器則在收到客戶端的ACK報文段后立即進(jìn)入CLOSED`狀態(tài)。

四次揮手

補(bǔ)充

說明：至于為什么提及TCP狀態(tài)，是為了結(jié)合圖來寫的（圖片來源網(wǎng)絡(luò)，我也沒法改是不是），大家過一遍就好了，暫時也不用太深入了解，下一篇再寫TCP狀態(tài)轉(zhuǎn)移~

提供點技術(shù)支持吧，不要純理論分享了，為了更好的理解在整個TCP連接期間，TCP序列號和確認(rèn)號是如何工作的，我們可以使用wireshark抓包工具內(nèi)置的繪制流功能，先過濾IP地址，設(shè)置過濾規(guī)則為：ip.src == xxx.xxx.xxx.xxx or ip.dst == xxx.xxx.xxx.xxx，選擇菜單欄中的 Statistics（統(tǒng)計） ->Flow Graph（流量圖）繪制流功能，就能看到整個TCP協(xié)議連接的過程了（在第二張圖的最右邊是有注釋的）。