引言

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

“三次握手”

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

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

1. 第一步：客戶端的TCP首先向服務(wù)器端的TCP發(fā)送一個(gè)特殊的TCP報(bào)文段。該報(bào)文段中不包含任何應(yīng)用層的數(shù)據(jù)，但是在報(bào)文段的首部中的SYN標(biāo)志位會(huì)被置為1。因此，這個(gè)特殊報(bào)文段被稱為SYN 報(bào)文段（握手請(qǐng)求報(bào)文）。另外，客戶端會(huì)隨機(jī)地選擇一個(gè)初始序號(hào)（ISN，假設(shè)為 x，如動(dòng)態(tài)圖），并將此序號(hào)放置于該SYN報(bào)文段的序號(hào)字段 sqe中；但握手請(qǐng)求報(bào)文報(bào)文段中的ACK標(biāo)志為0，所以此時(shí)它的確認(rèn)序號(hào) ack是無(wú)效的，是什么值我們也不用管。握手請(qǐng)求報(bào)文會(huì)被封裝在一個(gè)IP數(shù)據(jù)報(bào)中，然后發(fā)送給服務(wù)器。此時(shí)，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）。TCP規(guī)定，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個(gè)序號(hào)

   
   

2. 第二步：服務(wù)器收到了客戶端發(fā)出的SYN報(bào)文段，服務(wù)器便會(huì)從SYN報(bào)文段中提取對(duì)應(yīng)的信息，為該TCP連接分配TCP緩存和變量來(lái)維護(hù)這個(gè)鏈接，（當(dāng)然啦，這服務(wù)器必須得有內(nèi)存來(lái)響應(yīng)這個(gè)鏈接，很多時(shí)候服務(wù)器被攻擊時(shí)就沒(méi)空搭理這個(gè)鏈接了），并向該客戶端返回一個(gè)允許連接的報(bào)文段（握手應(yīng)答報(bào)文）。此時(shí)，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)，這個(gè)報(bào)文段同樣也不包含任何應(yīng)用層數(shù)據(jù)，但是，在報(bào)文段的首部卻包含3個(gè)重要的信息。

• SYN 與 ACK 標(biāo)志都被置為 1。

• 將TCP報(bào)文段首部的確認(rèn)序號(hào) ack字段設(shè)置為 x+1，這個(gè) x 是從握手請(qǐng)求報(bào)文中得到的。

• 服務(wù)器也會(huì)隨機(jī)選擇自己的初始序號(hào)ISN，注意此ISN是服務(wù)器端的ISN，假設(shè)為y，并將它放置到TCP報(bào)文段首部的序號(hào)字段中。

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

3. 第三步：當(dāng)客戶端收到服務(wù)器的握手應(yīng)答報(bào)文后，還要給服務(wù)器返回一個(gè)應(yīng)答報(bào)文 ，表示已經(jīng)收到服務(wù)器的握手應(yīng)答報(bào)文，應(yīng)答報(bào)文中客戶端會(huì)將ACK標(biāo)志置1，此時(shí)，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)，而對(duì)于SYN標(biāo)志，因?yàn)?code style="font-size: inherit;line-height: inherit;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin: 0px 2px;color: rgb(233, 105, 0);background: rgb(248, 248, 248);">連接已經(jīng)建立了，所以SYN標(biāo)志會(huì)被置為0，同時(shí)客戶端也要給該TCP連接分配緩存和變量來(lái)維護(hù)這個(gè)鏈接，將TCP報(bào)文段首部的確認(rèn)序號(hào)字段設(shè)置為y+1，同時(shí)也將客戶端自己的窗口大小告訴服務(wù)器。在握手的第三個(gè)階段可以在報(bào)文段中攜帶數(shù)據(jù)，TCP規(guī)定，這個(gè)ACK報(bào)文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號(hào)。

在完成握手后，客戶端與服務(wù)器就建立了連接，同時(shí)雙方都得到了彼此的窗口大小，序號(hào)等信息，然后客戶端就可以和服務(wù)器開心地傳輸數(shù)據(jù)了，在鏈接過(guò)程中這些傳輸數(shù)據(jù)都是平等的，任何一方都可以隨意傳輸數(shù)據(jù)到另一方，在傳輸TCP報(bào)文段的時(shí)候，每個(gè)TCP報(bào)文段首部的SYN標(biāo)志都會(huì)被置0，因?yàn)樗挥糜诎l(fā)起連接，同步序號(hào)。

“四次揮手”

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

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

四次揮手過(guò)程如下（有一個(gè)GIF上傳不了，就算了）：

1. 客戶端發(fā)出一個(gè)FIN報(bào)文段主動(dòng)進(jìn)行關(guān)閉連接，此時(shí)報(bào)文段的FIN標(biāo)志位為1，假設(shè)序號(hào)為u，一般來(lái)說(shuō)ACK標(biāo)志也會(huì)被置一，但此時(shí)確認(rèn)序號(hào)字段是無(wú)效的（因?yàn)?code style="font-size: inherit;line-height: inherit;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin: 0px 2px;color: rgb(233, 105, 0);background: rgb(248, 248, 248);">FIN標(biāo)志位為1），此時(shí)，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)（關(guān)于TCP協(xié)議狀態(tài)的內(nèi)容到時(shí)候再慢慢講吧，有點(diǎn)復(fù)雜）。TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)，也要消耗一個(gè)序號(hào)。

2. 當(dāng)服務(wù)器收到這個(gè) FIN報(bào)文段，它發(fā)回一個(gè)ACK報(bào)文段（此報(bào)文段是終止連接應(yīng)答），確認(rèn)序號(hào)為u+1，并且?guī)献约旱男蛱?hào)v，和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)，此時(shí)已經(jīng)斷開<客戶端 -> 服務(wù)器>的方向連接，但<服務(wù)器 -> 客戶端>方向的連接仍然存在，并且服務(wù)器可以發(fā)送數(shù)據(jù)給客戶端，客戶端也必須接受這些數(shù)據(jù)，這時(shí)候服務(wù)器處于半關(guān)閉狀態(tài)（CLOSE-WAIT），客戶端收到服務(wù)器發(fā)送的ACK報(bào)文段后處于FIN-WAIT-2（終止等待2）狀態(tài)。

3. 一般來(lái)說(shuō)服務(wù)器會(huì)向應(yīng)用程序請(qǐng)求關(guān)閉與這個(gè)客戶端的連接，接著服務(wù)器就會(huì)發(fā)送一個(gè)FIN報(bào)文段（這個(gè)報(bào)文段是服務(wù)器向客戶端發(fā)出，請(qǐng)求終止連接），此時(shí)假設(shè)序號(hào)為w，ACK標(biāo)志雖然也為1，但是確認(rèn)序號(hào)字段也是無(wú)效的，此時(shí)，服務(wù)器則進(jìn)入LAST_ACK狀態(tài)（服務(wù)器等待對(duì)方接受關(guān)閉連接）。

4. 客戶端返回一個(gè)ACK報(bào)文段來(lái)確認(rèn)終止（服務(wù)器的）連接的請(qǐng)求，ACK標(biāo)志置一，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1（w+1），此時(shí)斷開<`服務(wù)器 -> 客戶端 >方向上的連接。此時(shí)，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2*MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，才進(jìn)入CLOSED狀態(tài)。而服務(wù)器則在收到客戶端的ACK報(bào)文段后立即進(jìn)入CLOSED`狀態(tài)。
   

   
   

補(bǔ)充

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

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

C語(yǔ)言、嵌入式應(yīng)用：TCP通信實(shí)例分析

【socket筆記】TCP、UDP通信總結(jié)

【socket應(yīng)用】基于C語(yǔ)言的天氣客戶端的實(shí)現(xiàn)

若覺(jué)得文章不錯(cuò)，轉(zhuǎn)發(fā)分享、在看，也是我們繼續(xù)更新的動(dòng)力。

在公眾號(hào)內(nèi)回復(fù)更多資源，可免費(fèi)獲取嵌入式資料。期待你的關(guān)注~

加好友，回暗號(hào)【嵌入式大雜燴】，進(jìn)微信群