自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

三次握手+四次揮手,一文搞定所有!

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理 開(kāi)發(fā)工具
TCP 三次握手和四次揮手的問(wèn)題在面試中是最為常見(jiàn)的考點(diǎn)之一。很多讀者都知道三次和四次,但是如果問(wèn)深入一點(diǎn),他們往往都無(wú)法作出準(zhǔn)確回答。本文就來(lái)詳解 TCP 連接的三次握手與四次揮手。

 TCP 三次握手和四次揮手的問(wèn)題在面試中是最為常見(jiàn)的考點(diǎn)之一。很多讀者都知道三次和四次,但是如果問(wèn)深入一點(diǎn),他們往往都無(wú)法作出準(zhǔn)確回答。本文就來(lái)詳解 TCP 連接的三次握手與四次揮手。

[[312325]]
圖片來(lái)自 Pexels 

TCP Connection

 

客戶(hù)端與服務(wù)器之間數(shù)據(jù)的發(fā)送和返回的過(guò)程當(dāng)中需要?jiǎng)?chuàng)建一個(gè)叫 TCP Connection 的東西。

由于 TCP 不存在連接的概念,只存在請(qǐng)求和響應(yīng),請(qǐng)求和響應(yīng)都是數(shù)據(jù)包,它們之間都是經(jīng)過(guò)由 TCP 創(chuàng)建的一個(gè)從客戶(hù)端發(fā)起,服務(wù)器接收的類(lèi)似連接的通道,這個(gè)連接可以一直保持,HTTP 請(qǐng)求是在這個(gè)連接的基礎(chǔ)上發(fā)送的。

在一個(gè) TCP 連接上是可以發(fā)送多個(gè) HTTP 請(qǐng)求的,不同的版本這個(gè)模式不一樣。

在 HTTP/1.0 中這個(gè) TCP 連接是在 HTTP 請(qǐng)求創(chuàng)建的時(shí)候同步創(chuàng)建的,HTTP 請(qǐng)求發(fā)送到服務(wù)器端,服務(wù)器端響應(yīng)了之后,這個(gè) TCP 連接就關(guān)閉了。

HTTP/1.1 中可以以某種方式聲明這個(gè)連接一直保持,一個(gè)請(qǐng)求傳輸完之后,另一個(gè)請(qǐng)求可以接著傳輸。

這樣的好處是:在創(chuàng)建一個(gè) TCP 連接的過(guò)程中需要“三次握手”的消耗,“三次握手”代表有三次網(wǎng)絡(luò)傳輸。

如果 TCP 連接保持,第二個(gè)請(qǐng)求發(fā)送就沒(méi)有這“三次握手”的消耗。HTTP/2 中同一個(gè) TCP 連接里還可以并發(fā)地傳輸 HTTP 請(qǐng)求。

TCP 報(bào)文格式簡(jiǎn)介

 

其中比較重要的字段有:

  • 序號(hào)(sequence number):Seq 序號(hào),占 32 位,用來(lái)標(biāo)識(shí)從 TCP 源端向目的端發(fā)送的字節(jié)流,發(fā)起方發(fā)送數(shù)據(jù)時(shí)對(duì)此進(jìn)行標(biāo)記。
  • 確認(rèn)號(hào)(acknowledgement number):Ack 序號(hào),占 32 位,只有 ACK 標(biāo)志位為 1 時(shí),確認(rèn)序號(hào)字段才有效,Ack=Seq+1。
  • 標(biāo)志位(Flags):共 6 個(gè),即 URG、ACK、PSH、RST、SYN、FIN 等。

六個(gè)標(biāo)志位具體含義如下:

  • URG:緊急指針(urgent pointer)有效。
  • ACK:確認(rèn)序號(hào)有效。
  • PSH:接收方應(yīng)該盡快將這個(gè)報(bào)文交給應(yīng)用層。
  • RST:重置連接。
  • SYN:發(fā)起一個(gè)新連接。
  • FIN:釋放一個(gè)連接。

需要注意的是:

  • 不要將確認(rèn)序號(hào) Ack 與標(biāo)志位中的 ACK 搞混了。
  • 確認(rèn)方 Ack=發(fā)起方 Seq+1,兩端配對(duì)。

TCP 的三次握手

“三次握手”的詳解

所謂的三次握手即 TCP 連接的建立。這個(gè)連接必須是一方主動(dòng)打開(kāi),另一方被動(dòng)打開(kāi)的。

以下為客戶(hù)端主動(dòng)發(fā)起連接的圖解:

 

握手之前主動(dòng)打開(kāi)連接的客戶(hù)端結(jié)束 CLOSED 階段,被動(dòng)打開(kāi)的服務(wù)器端也結(jié)束 CLOSED 階段,并進(jìn)入 LISTEN 階段,隨后開(kāi)始“三次握手”。

①首先客戶(hù)端向服務(wù)器端發(fā)送一段 TCP 報(bào)文。

其中:標(biāo)記位為 SYN,表示“請(qǐng)求建立新連接”;序號(hào)為 Seq=x(x 一般為 1);隨后客戶(hù)端進(jìn)入 SYN-SENT 階段。

②服務(wù)器端接收到來(lái)自客戶(hù)端的 TCP 報(bào)文之后,結(jié)束 LISTEN 階段。并返回一段 TCP 報(bào)文。

其中:標(biāo)志位為 SYN 和 ACK,表示“確認(rèn)客戶(hù)端的報(bào)文 Seq 序號(hào)有效,服務(wù)器能正常接收客戶(hù)端發(fā)送的數(shù)據(jù),并同意創(chuàng)建新連接”(即告訴客戶(hù)端,服務(wù)器收到了你的數(shù)據(jù))。

序號(hào)為 Seq=y;確認(rèn)號(hào)為 Ack=x+1,表示收到客戶(hù)端的序號(hào) Seq 并將其值加 1 作為自己確認(rèn)號(hào) Ack 的值;隨后服務(wù)器端進(jìn)入 SYN-RCVD 階段。

③客戶(hù)端接收到來(lái)自服務(wù)器端的確認(rèn)收到數(shù)據(jù)的 TCP 報(bào)文之后,明確了從客戶(hù)端到服務(wù)器的數(shù)據(jù)傳輸是正常的,結(jié)束 SYN-SENT 階段。并返回最后一段 TCP 報(bào)文。

其中:標(biāo)志位為 ACK,表示“確認(rèn)收到服務(wù)器端同意連接的信號(hào)”(即告訴服務(wù)器,我知道你收到我發(fā)的數(shù)據(jù)了)。

序號(hào)為 Seq=x+1,表示收到服務(wù)器端的確認(rèn)號(hào) Ack,并將其值作為自己的序號(hào)值。

確認(rèn)號(hào)為 Ack=y+1,表示收到服務(wù)器端序號(hào) Seq,并將其值加 1 作為自己的確認(rèn)號(hào) Ack 的值;隨后客戶(hù)端進(jìn)入 ESTABLISHED 階段。

服務(wù)器收到來(lái)自客戶(hù)端的“確認(rèn)收到服務(wù)器數(shù)據(jù)”的 TCP 報(bào)文之后,明確了從服務(wù)器到客戶(hù)端的數(shù)據(jù)傳輸是正常的。結(jié)束 SYN-SENT 階段,進(jìn)入 ESTABLISHED 階段。

在客戶(hù)端與服務(wù)器端傳輸?shù)?TCP 報(bào)文中,雙方的確認(rèn)號(hào) Ack 和序號(hào) Seq 的值,都是在彼此 Ack 和 Seq 值的基礎(chǔ)上進(jìn)行計(jì)算的,這樣做保證了 TCP 報(bào)文傳輸?shù)倪B貫性。

一旦出現(xiàn)某一方發(fā)出的 TCP 報(bào)文丟失,便無(wú)法繼續(xù)"握手",以此確保了"三次握手"的順利完成。

此后客戶(hù)端和服務(wù)器端進(jìn)行正常的數(shù)據(jù)傳輸。這就是“三次握手”的過(guò)程。

“三次握手”的動(dòng)態(tài)過(guò)程

 

“三次握手”的通俗理解

 

舉個(gè)栗子:把客戶(hù)端比作男孩,服務(wù)器比作女孩。

用他們的交往來(lái)說(shuō)明“三次握手”過(guò)程:

  • 男孩喜歡女孩,于是寫(xiě)了一封信告訴女孩:我愛(ài)你,請(qǐng)和我交往吧!;寫(xiě)完信之后,男孩焦急地等待,因?yàn)椴恢佬拍芊耥樌麄鬟_(dá)給女孩。
  • 女孩收到男孩的情書(shū)后,心花怒放,原來(lái)我們是兩情相悅呀!于是給男孩寫(xiě)了一封回信:我收到你的情書(shū)了,也明白了你的心意,其實(shí),我也喜歡你!我愿意和你交往!

寫(xiě)完信之后,女孩也焦急地等待,因?yàn)椴恢阑匦拍芊衲茼樌麄鬟_(dá)給男孩。

  • 男孩收到回信之后很開(kāi)心,因?yàn)榘l(fā)出的情書(shū)女孩收到了,并且從回信中知道了女孩喜歡自己,并且愿意和自己交往。

然后男孩又寫(xiě)了一封信告訴女孩:你的心意和信我都收到了,謝謝你,還有我愛(ài)你!

女孩收到男孩的回信之后,也很開(kāi)心,因?yàn)榘l(fā)出的情書(shū)男孩收到了。由此男孩女孩雙方都知道了彼此的心意,之后就快樂(lè)地交流起來(lái)了~~

這就是通俗版的“三次握手”,期間一共往來(lái)了三封信也就是“三次握手”,以此確認(rèn)兩個(gè)方向上的數(shù)據(jù)傳輸通道是否正常。

為什么要進(jìn)行第三次握手

為了防止服務(wù)器端開(kāi)啟一些無(wú)用的連接增加服務(wù)器開(kāi)銷(xiāo)以及防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端,因而產(chǎn)生錯(cuò)誤。

由于網(wǎng)絡(luò)傳輸是有延時(shí)的(要通過(guò)網(wǎng)絡(luò)光纖和各種中間代理服務(wù)器),在傳輸?shù)倪^(guò)程中,比如客戶(hù)端發(fā)起了 SYN=1 創(chuàng)建連接的請(qǐng)求(第一次握手)。

如果服務(wù)器端就直接創(chuàng)建了這個(gè)連接并返回包含 SYN、ACK 和 Seq 等內(nèi)容的數(shù)據(jù)包給客戶(hù)端,這個(gè)數(shù)據(jù)包因?yàn)榫W(wǎng)絡(luò)傳輸?shù)脑騺G失了,丟失之后客戶(hù)端就一直沒(méi)有接收到服務(wù)器返回的數(shù)據(jù)包。

客戶(hù)端可能設(shè)置了一個(gè)超時(shí)時(shí)間,時(shí)間到了就關(guān)閉了連接創(chuàng)建的請(qǐng)求。

再重新發(fā)出創(chuàng)建連接的請(qǐng)求,而服務(wù)器端是不知道的,如果沒(méi)有第三次握手告訴服務(wù)器端客戶(hù)端收的到服務(wù)器端傳輸?shù)臄?shù)據(jù)的話(huà),服務(wù)器端是不知道客戶(hù)端有沒(méi)有接收到服務(wù)器端返回的信息的。

這個(gè)過(guò)程可理解為:

 

這樣沒(méi)有給服務(wù)器端一個(gè)創(chuàng)建還是關(guān)閉連接端口的請(qǐng)求,服務(wù)器端的端口就一直開(kāi)著,等到客戶(hù)端因超時(shí)重新發(fā)出請(qǐng)求時(shí),服務(wù)器就會(huì)重新開(kāi)啟一個(gè)端口連接。

那么服務(wù)器端上沒(méi)有接收到請(qǐng)求數(shù)據(jù)的上一個(gè)端口就一直開(kāi)著,長(zhǎng)此以往,這樣的端口多了,就會(huì)造成服務(wù)器端開(kāi)銷(xiāo)的嚴(yán)重浪費(fèi)。

還有一種情況是已經(jīng)失效的客戶(hù)端發(fā)出的請(qǐng)求信息,由于某種原因傳輸?shù)搅朔?wù)器端,服務(wù)器端以為是客戶(hù)端發(fā)出的有效請(qǐng)求,接收后產(chǎn)生錯(cuò)誤。

所以我們需要“第三次握手”來(lái)確認(rèn)這個(gè)過(guò)程,讓客戶(hù)端和服務(wù)器端能夠及時(shí)地察覺(jué)到因?yàn)榫W(wǎng)絡(luò)等一些問(wèn)題導(dǎo)致的連接創(chuàng)建失敗,這樣服務(wù)器端的端口就可以關(guān)閉了,不用一直等待。

也可以這樣理解:“第三次握手”是客戶(hù)端向服務(wù)器端發(fā)送數(shù)據(jù),這個(gè)數(shù)據(jù)就是要告訴服務(wù)器,客戶(hù)端有沒(méi)有收到服務(wù)器“第二次握手”時(shí)傳過(guò)去的數(shù)據(jù)。

若發(fā)送的這個(gè)數(shù)據(jù)是“收到了”的信息,接收后服務(wù)器就正常建立 TCP 連接,否則建立 TCP 連接失敗,服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開(kāi)銷(xiāo)和接收到失效請(qǐng)求發(fā)生的錯(cuò)誤。

抓包驗(yàn)證

下面是用抓包工具抓到的一些數(shù)據(jù)包,可用來(lái)分析 TCP 的三次握手:

 

圖中顯示的就是完整的 TCP 連接的”三次握手”過(guò)程。在 52528→80 中,52528 是本地(客戶(hù)端)端口,80 是服務(wù)器的端口。80 端口和 52528 端口之間的三次來(lái)回就是"三次握手"過(guò)程。

注意到“第一次握手”客戶(hù)端發(fā)送的 TCP 報(bào)文中以[SYN]作為標(biāo)志位,并且客戶(hù)端序號(hào) Seq=0。

接下來(lái)”第二次握手”服務(wù)器返回的 TCP 報(bào)文中以[SYN,ACK]作為標(biāo)志位;并且服務(wù)器端序號(hào) Seq=0;確認(rèn)號(hào) Ack=1(“第一次握手”中客戶(hù)端序號(hào) Seq 的值+1)。

最后”第三次握手”客戶(hù)端再向服務(wù)器端發(fā)送的 TCP 報(bào)文中以[ACK]作為標(biāo)志位;其中客戶(hù)端序號(hào) Seq=1(“第二次握手”中服務(wù)器端確認(rèn)號(hào) Ack 的值);確認(rèn)號(hào) Ack=1(“第二次握手”中服務(wù)器端序號(hào) Seq 的值 +1)。

這就完成了”三次握手”的過(guò)程,符合前面分析的結(jié)果。

TCP 的四次揮手

對(duì)于"三次握手"我們耳熟能詳,因?yàn)槠湎鄬?duì)的簡(jiǎn)單。但是,我們卻不常聽(tīng)見(jiàn)“四次揮手”,就算聽(tīng)過(guò)也未必能詳細(xì)地說(shuō)明白它的具體過(guò)程。下面就為大家詳盡,直觀,完整地介紹“四次揮手”的過(guò)程。

“四次揮手”的詳解

所謂的四次揮手即 TCP 連接的釋放(解除)。連接的釋放必須是一方主動(dòng)釋放,另一方被動(dòng)釋放。

以下為客戶(hù)端主動(dòng)發(fā)起釋放連接的圖解:

 

揮手之前主動(dòng)釋放連接的客戶(hù)端結(jié)束 ESTABLISHED 階段。隨后開(kāi)始“四次揮手”。

①首先客戶(hù)端想要釋放連接,向服務(wù)器端發(fā)送一段 TCP 報(bào)文。

其中:標(biāo)記位為 FIN,表示“請(qǐng)求釋放連接“;序號(hào)為 Seq=U。

隨后客戶(hù)端進(jìn)入 FIN-WAIT-1 階段,即半關(guān)閉階段。并且停止在客戶(hù)端到服務(wù)器端方向上發(fā)送數(shù)據(jù),但是客戶(hù)端仍然能接收從服務(wù)器端傳輸過(guò)來(lái)的數(shù)據(jù)。

注意:這里不發(fā)送的是正常連接時(shí)傳輸?shù)臄?shù)據(jù)(非確認(rèn)報(bào)文),而不是一切數(shù)據(jù),所以客戶(hù)端仍然能發(fā)送 ACK 確認(rèn)報(bào)文。

②服務(wù)器端接收到從客戶(hù)端發(fā)出的 TCP 報(bào)文之后,確認(rèn)了客戶(hù)端想要釋放連接,隨后服務(wù)器端結(jié)束 ESTABLISHED 階段,進(jìn)入 CLOSE-WAIT 階段(半關(guān)閉狀態(tài))并返回一段 TCP 報(bào)文。

其中:標(biāo)記位為 ACK,表示“接收到客戶(hù)端發(fā)送的釋放連接的請(qǐng)求”。

序號(hào)為 Seq=V,確認(rèn)號(hào)為 Ack=U+1,表示是在收到客戶(hù)端報(bào)文的基礎(chǔ)上,將其序號(hào) Seq 值加 1 作為本段報(bào)文確認(rèn)號(hào) Ack 的值;隨后服務(wù)器端開(kāi)始準(zhǔn)備釋放服務(wù)器端到客戶(hù)端方向上的連接。

客戶(hù)端收到從服務(wù)器端發(fā)出的 TCP 報(bào)文之后,確認(rèn)了服務(wù)器收到了客戶(hù)端發(fā)出的釋放連接請(qǐng)求,隨后客戶(hù)端結(jié)束 FIN-WAIT-1 階段,進(jìn)入 FIN-WAIT-2 階段。

前"兩次揮手"既讓服務(wù)器端知道了客戶(hù)端想要釋放連接,也讓客戶(hù)端知道了服務(wù)器端了解了自己想要釋放連接的請(qǐng)求。于是,可以確認(rèn)關(guān)閉客戶(hù)端到服務(wù)器端方向上的連接了。

③服務(wù)器端自從發(fā)出 ACK 確認(rèn)報(bào)文之后,經(jīng)過(guò) CLOSED-WAIT 階段,做好了釋放服務(wù)器端到客戶(hù)端方向上的連接準(zhǔn)備,再次向客戶(hù)端發(fā)出一段 TCP 報(bào)文。

其中:標(biāo)記位為 FIN,ACK,表示“已經(jīng)準(zhǔn)備好釋放連接了”。注意:這里的 ACK 并不是確認(rèn)收到服務(wù)器端報(bào)文的確認(rèn)報(bào)文。

序號(hào)為 Seq=W,確認(rèn)號(hào)為 Ack=U+1,表示是在收到客戶(hù)端報(bào)文的基礎(chǔ)上,將其序號(hào) Seq 值加 1 作為本段報(bào)文確認(rèn)號(hào) Ack 的值。

隨后服務(wù)器端結(jié)束 CLOSE-WAIT 階段,進(jìn)入 LAST-ACK 階段。并且停止在服務(wù)器端到客戶(hù)端的方向上發(fā)送數(shù)據(jù),但是服務(wù)器端仍然能夠接收從客戶(hù)端傳輸過(guò)來(lái)的數(shù)據(jù)。

④客戶(hù)端收到從服務(wù)器端發(fā)出的 TCP 報(bào)文,確認(rèn)了服務(wù)器端已做好釋放連接的準(zhǔn)備,結(jié)束 FIN-WAIT-2 階段,進(jìn)入 TIME-WAIT 階段,并向服務(wù)器端發(fā)送一段報(bào)文。

其中:標(biāo)記位為 ACK,表示“接收到服務(wù)器準(zhǔn)備好釋放連接的信號(hào)”。

序號(hào)為 Seq=u+1;表示是在收到了服務(wù)器端報(bào)文的基礎(chǔ)上,將其確認(rèn)號(hào) Ack 值作為本段報(bào)文序號(hào)的值。

確認(rèn)號(hào)為 Ack=w+1;表示是在收到了服務(wù)器端報(bào)文的基礎(chǔ)上,將其序號(hào) Seq 值作為本段報(bào)文確認(rèn)號(hào)的值。隨后客戶(hù)端開(kāi)始在 TIME-WAIT 階段等待 2MSL。

服務(wù)器端收到從客戶(hù)端發(fā)出的 TCP 報(bào)文之后結(jié)束 LAST-ACK 階段,進(jìn)入 CLOSED 階段。由此正式確認(rèn)關(guān)閉服務(wù)器端到客戶(hù)端方向上的連接。

客戶(hù)端等待完 2MSL 之后,結(jié)束 TIME-WAIT 階段,進(jìn)入 CLOSED 階段,由此完成“四次揮手”。

后“兩次揮手”既讓客戶(hù)端知道了服務(wù)器端準(zhǔn)備好釋放連接了,也讓服務(wù)器端知道了客戶(hù)端了解了自己準(zhǔn)備好釋放連接了。

于是,可以確認(rèn)關(guān)閉服務(wù)器端到客戶(hù)端方向上的連接了,由此完成“四次揮手”。

與“三次揮手”一樣,在客戶(hù)端與服務(wù)器端傳輸?shù)?TCP 報(bào)文中,雙方的確認(rèn)號(hào) Ack 和序號(hào) Seq 的值,都是在彼此 Ack 和 Seq 值的基礎(chǔ)上進(jìn)行計(jì)算的。

這樣保證了 TCP 報(bào)文傳輸?shù)倪B貫性,一旦出現(xiàn)某一方發(fā)出的 TCP 報(bào)文丟失,便無(wú)法繼續(xù)"揮手",以此確保了"四次揮手"的順利完成。

“四次揮手”的動(dòng)態(tài)過(guò)程

“四次揮手”的通俗理解

舉個(gè)栗子:把客戶(hù)端比作男孩,服務(wù)器比作女孩。 

通過(guò)他們的分手來(lái)說(shuō)明“四次揮手”過(guò)程:

  • "第一次揮手":日久見(jiàn)人心,男孩發(fā)現(xiàn)女孩變成了自己討厭的樣子,忍無(wú)可忍,于是決定分手,隨即寫(xiě)了一封信告訴女孩。
  • “第二次揮手”:女孩收到信之后,知道了男孩要和自己分手,怒火中燒,心中暗罵:你算什么東西,當(dāng)初你可不是這個(gè)樣子的!于是立馬給男孩寫(xiě)了一封回信:分手就分手,給我點(diǎn)時(shí)間,我要把你的東西整理好,全部還給你!

男孩收到女孩的第一封信之后,明白了女孩知道自己要和她分手。隨后等待女孩把自己的東西收拾好。

  • “第三次揮手”:過(guò)了幾天,女孩把男孩送的東西都整理好了,于是再次寫(xiě)信給男孩:你的東西我整理好了,快把它們拿走,從此你我恩斷義絕!
  • “第四次揮手”:男孩收到女孩第二封信之后,知道了女孩收拾好東西了,可以正式分手了,于是再次寫(xiě)信告訴女孩:我知道了,這就去拿回來(lái)!

這里雙方都有各自的堅(jiān)持:

  • 女孩自發(fā)出第二封信開(kāi)始,限定一天內(nèi)收不到男孩回信,就會(huì)再發(fā)一封信催促男孩來(lái)取東西!
  • 男孩自發(fā)出第二封信開(kāi)始,限定兩天內(nèi)沒(méi)有再次收到女孩的信就認(rèn)為,女孩收到了自己的第二封信;若兩天內(nèi)再次收到女孩的來(lái)信,就認(rèn)為自己的第二封信女孩沒(méi)收到,需要再寫(xiě)一封信,再等兩天…..

倘若雙方信都能正常收到,最少只用四封信就能徹底分手!這就是“四次揮手”。

為啥握手是三次,揮手卻要四次

TCP 建立連接時(shí)之所以只需要"三次握手",是因?yàn)樵诘诙?quot;握手"過(guò)程中,服務(wù)器端發(fā)送給客戶(hù)端的 TCP 報(bào)文是以 SYN 與 ACK 作為標(biāo)志位的。

SYN 是請(qǐng)求連接標(biāo)志,表示服務(wù)器端同意建立連接;ACK 是確認(rèn)報(bào)文,表示告訴客戶(hù)端,服務(wù)器端收到了它的請(qǐng)求報(bào)文。

即 SYN 建立連接報(bào)文與 ACK 確認(rèn)接收?qǐng)?bào)文是在同一次"握手"當(dāng)中傳輸?shù)?,所?quot;三次握手"不多也不少,正好讓雙方明確彼此信息互通。

TCP 釋放連接時(shí)之所以需要“四次揮手”,是因?yàn)?FIN 釋放連接報(bào)文與 ACK 確認(rèn)接收?qǐng)?bào)文是分別由第二次和第三次"握手"傳輸?shù)摹?/p>

為何建立連接時(shí)一起傳輸,釋放連接時(shí)卻要分開(kāi)傳輸?

  • 建立連接時(shí),被動(dòng)方服務(wù)器端結(jié)束 CLOSED 階段進(jìn)入“握手”階段并不需要任何準(zhǔn)備,可以直接返回 SYN 和 ACK 報(bào)文,開(kāi)始建立連接。
  • 釋放連接時(shí),被動(dòng)方服務(wù)器,突然收到主動(dòng)方客戶(hù)端釋放連接的請(qǐng)求時(shí)并不能立即釋放連接。

因?yàn)檫€有必要的數(shù)據(jù)需要處理,所以服務(wù)器先返回 ACK 確認(rèn)收到報(bào)文,經(jīng)過(guò) CLOSE-WAIT 階段準(zhǔn)備好釋放連接之后,才能返回 FIN 釋放連接報(bào)文。

所以是“三次握手”,“四次揮手”。

為啥客戶(hù)端在TIME-WAIT階段要等2MSL

為的是確認(rèn)服務(wù)器端是否收到客戶(hù)端發(fā)出的 ACK 確認(rèn)報(bào)文,當(dāng)客戶(hù)端發(fā)出最后的 ACK 確認(rèn)報(bào)文時(shí),并不能確定服務(wù)器端能夠收到該段報(bào)文。

所以客戶(hù)端在發(fā)送完 ACK 確認(rèn)報(bào)文之后,會(huì)設(shè)置一個(gè)時(shí)長(zhǎng)為 2MSL 的計(jì)時(shí)器。

MSL 指的是 Maximum Segment Lifetime:一段 TCP 報(bào)文在傳輸過(guò)程中的最大生命周期。

2MSL 即是服務(wù)器端發(fā)出為 FIN 報(bào)文和客戶(hù)端發(fā)出的 ACK 確認(rèn)報(bào)文所能保持有效的最大時(shí)長(zhǎng)。

服務(wù)器端在 1MSL 內(nèi)沒(méi)有收到客戶(hù)端發(fā)出的 ACK 確認(rèn)報(bào)文,就會(huì)再次向客戶(hù)端發(fā)出 FIN 報(bào)文:

  • 如果客戶(hù)端在 2MSL 內(nèi),再次收到了來(lái)自服務(wù)器端的 FIN 報(bào)文,說(shuō)明服務(wù)器端由于各種原因沒(méi)有接收到客戶(hù)端發(fā)出的 ACK 確認(rèn)報(bào)文。

客戶(hù)端再次向服務(wù)器端發(fā)出 ACK 確認(rèn)報(bào)文,計(jì)時(shí)器重置,重新開(kāi)始 2MSL 的計(jì)時(shí)。

  • 否則客戶(hù)端在 2MSL 內(nèi)沒(méi)有再次收到來(lái)自服務(wù)器端的 FIN 報(bào)文,說(shuō)明服務(wù)器端正常接收了 ACK 確認(rèn)報(bào)文,客戶(hù)端可以進(jìn)入 CLOSED 階段,完成“四次揮手”。

所以,客戶(hù)端要經(jīng)歷時(shí)長(zhǎng)為 2SML 的 TIME-WAIT 階段;這也是為什么客戶(hù)端比服務(wù)器端晚進(jìn)入 CLOSED 階段的原因。

抓包驗(yàn)證

 

圖中顯示的就是完整的 TCP 連接釋放的”四次揮手”過(guò)程。在 80→55389 中,假設(shè) 80 是本地(客戶(hù)端)端口,55389 是服務(wù)器端口。

80 端口與 55389 之間的四次來(lái)回就是"四次揮手"過(guò)程:

  • “第一次揮手”客戶(hù)端發(fā)送的 FIN 請(qǐng)求釋放連接報(bào)文以[FIN,ACK]作為標(biāo)志位,其中報(bào)文序號(hào) Seq=2445;確認(rèn)號(hào) Ack=558。注意:這里與“第三次握手”的 ACK 并不是表示確認(rèn)的 ACK 報(bào)文。
  • “第二次揮手”服務(wù)器端返回的 ACK 確認(rèn)報(bào)文以[ACK]作為標(biāo)志位;其中報(bào)文序號(hào) Seq=558;確認(rèn)號(hào) Ack=2246。
  • “第三次揮手”服務(wù)器端繼續(xù)返回的 FIN 同意釋放連接報(bào)文以[FIN,ACK]作為標(biāo)志位;其中報(bào)文序號(hào) Seq=558;確認(rèn)號(hào) Ack=2246。
  • “第四次揮手”客戶(hù)端發(fā)出的 ACK 確認(rèn)接收?qǐng)?bào)文以[ACK]作為標(biāo)志位;其中報(bào)文序號(hào) Seq=2446;確認(rèn)號(hào) Ack=559。

后一次“揮手”傳輸報(bào)文中的序號(hào) Seq 值等于前一次"握手"傳輸報(bào)文中的確認(rèn)號(hào) Ack 值。

后一次“揮手”傳輸報(bào)文中的確認(rèn)號(hào) Ack 值等于前一次"握手"傳輸報(bào)文中的序號(hào) Seq 值。

故這是連續(xù)的“四次揮手”過(guò)程,與前面的分析相符。

 

責(zé)任編輯:武曉燕 來(lái)源: 博客園
相關(guān)推薦

2020-03-02 14:41:04

運(yùn)維架構(gòu)技術(shù)

2015-10-13 09:42:52

TCP網(wǎng)絡(luò)協(xié)議

2019-06-12 11:26:37

TCP三次握手四次揮手

2024-01-12 08:23:11

TCPACK服務(wù)器

2021-07-03 17:47:25

TCP控制協(xié)議

2021-01-29 06:11:08

TCP通信三次握手

2019-02-01 09:38:16

2021-05-18 12:27:40

TCP控制協(xié)議

2023-10-24 15:22:09

TCPUDP

2020-02-17 10:10:43

TCP三次握手四次揮手

2017-09-25 21:27:07

TCP協(xié)議數(shù)據(jù)鏈

2023-03-07 08:38:23

三次握手四次揮手服務(wù)端

2021-05-28 09:08:20

TCP連接序列號(hào)

2019-01-25 09:21:30

2020-06-29 14:50:47

TCP狀態(tài)ACK

2015-11-09 09:58:56

2023-10-28 09:07:57

TCP面試三次握手

2022-11-17 10:20:49

TCP三次握手四次揮手

2023-10-17 15:44:19

TCP四次揮手

2023-11-01 08:04:08

WiresharkTCP協(xié)議
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)