詳解 TCP 連接的“三次握手”與“四次揮手”

原文:https://www.cnblogs.com/AhuntSun-blog/p/12028636.html
聲明:本文為作者投稿,版權(quán)歸作者個人所有琼讽。

image

TCP connection

image
image

客戶端與服務(wù)器之間數(shù)據(jù)的發(fā)送和返回的過程當(dāng)中需要創(chuàng)建一個叫TCP connection的東西必峰; 由于TCP不存在連接的概念,只存在請求和響應(yīng)钻蹬,請求和響應(yīng)都是數(shù)據(jù)包吼蚁,它們之間都是經(jīng)過由TCP創(chuàng)建的一個從客戶端發(fā)起,服務(wù)器接收的類似連接的通道脉让,這個連接可以一直保持桂敛,http請求是在這個連接的基礎(chǔ)上發(fā)送的;在一個TCP連接上是可以發(fā)送多個http請求的溅潜,不同的版本這個模式不一樣术唬。在HTTP/1.0中這個TCP連接是在http請求創(chuàng)建的時候同步創(chuàng)建的,http請求發(fā)送到服務(wù)器端滚澜,服務(wù)器端響應(yīng)了之后粗仓,這個TCP連接就關(guān)閉了; HTTP/1.1中可以以某種方式聲明這個連接一直保持设捐,一個請求傳輸完之后借浊,另一個請求可以接著傳輸。這樣的好處是:在創(chuàng)建一個TCP連接的過程中需要“三次握手”的消耗萝招,“三次握手”代表有三次網(wǎng)絡(luò)傳輸蚂斤。如果TCP連接保持,第二個請求發(fā)送就沒有這“三次握手”的消耗槐沼。HTTP/2中同一個TCP連接里還可以并發(fā)地傳輸http請求曙蒸。

image
TCP報文格式簡介
image

其中比較重要的字段有:

(1)序號(sequence number):Seq序號,占32位岗钩,用來標(biāo)識從TCP源端向目的端發(fā)送的字節(jié)流纽窟,發(fā)起方發(fā)送數(shù)據(jù)時對此進行標(biāo)記。

(2)確認(rèn)號(acknowledgement number):Ack序號兼吓,占32位臂港,只有ACK標(biāo)志位為1時,確認(rèn)序號字段才有效视搏,Ack=Seq+1审孽。

(3)標(biāo)志位(Flags):共6個,即URG凶朗、ACK瓷胧、PSH、RST棚愤、SYN搓萧、FIN等杂数。具體含義如下:

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

需要注意的是:

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

image.png

TCP的三次握手(Three-Way Handshake)

1.”三次握手”的詳解

所謂的三次握手即TCP連接的建立。這個連接必須是一方主動打開养距,另一方被動打開的诉探。

以下為客戶端主動發(fā)起連接的圖解:
image

握手之前主動打開連接的客戶端結(jié)束CLOSED階段,被動打開的服務(wù)器端也結(jié)束CLOSED階段棍厌,并進入LISTEN階段肾胯。隨后開始“三次握手”:

(1)首先客戶端向服務(wù)器端發(fā)送一段TCP報文,其中:

  • 標(biāo)記位為SYN耘纱,表示“請求建立新連接”;

  • 序號為Seq=X(X一般為1)敬肚;

  • 隨后客戶端進入SYN-SENT階段。

(2)服務(wù)器端接收到來自客戶端的TCP報文之后束析,結(jié)束LISTEN階段艳馒。并返回一段TCP報文,其中:

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

  • 序號為Seq=y斋日;

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

(3)客戶端接收到來自服務(wù)器端的確認(rèn)收到數(shù)據(jù)的TCP報文之后第献,明確了從客戶端到服務(wù)器的數(shù)據(jù)傳輸是正常的,結(jié)束SYN-SENT階段兔港。并返回最后一段TCP報文庸毫。其中:

  • 標(biāo)志位為ACK,表示“確認(rèn)收到服務(wù)器端同意連接的信號”(即告訴服務(wù)器衫樊,我知道你收到我發(fā)的數(shù)據(jù)了)飒赃;
  • 序號為Seq=x+1利花,表示收到服務(wù)器端的確認(rèn)號Ack,并將其值作為自己的序號值载佳;
  • 確認(rèn)號為Ack=y+1炒事,表示收到服務(wù)器端序號Seq,并將其值加1作為自己的確認(rèn)號Ack的值蔫慧;
  • 隨后客戶端進入ESTABLISHED階段挠乳。

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

在客戶端與服務(wù)器端傳輸?shù)腡CP報文中黍析,雙方的確認(rèn)號Ack和序號Seq的值卖怜,都是在彼此Ack和Seq值的基礎(chǔ)上進行計算的,這樣做保證了TCP報文傳輸?shù)倪B貫性橄仍。一旦出現(xiàn)某一方發(fā)出的TCP報文丟失韧涨,便無法繼續(xù)"握手",以此確保了"三次握手"的順利完成侮繁。此后客戶端和服務(wù)器端進行正常的數(shù)據(jù)傳輸虑粥。這就是“三次握手”的過程。

2.“三次握手”的動態(tài)過程

image

3.“三次握手”的通俗理解

image

舉個栗子:把客戶端比作男孩宪哩,服務(wù)器比作女孩娩贷。用他們的交往來說明“三次握手”過程:(1)男孩喜歡女孩,于是寫了一封信告訴女孩:我愛你锁孟,請和我交往吧彬祖!;寫完信之后,男孩焦急地等待品抽,因為不知道信能否順利傳達(dá)給女孩储笑。(2)女孩收到男孩的情書后,心花怒放圆恤,原來我們是兩情相悅呀突倍!于是給男孩寫了一封回信:我收到你的情書了,也明白了你的心意盆昙,其實换怖,我也喜歡你骡楼!我愿意和你交往焰望!; 寫完信之后锈颗,女孩也焦急地等待,因為不知道回信能否能順利傳達(dá)給男孩炼团。(3)男孩收到回信之后很開心澎嚣,因為發(fā)出的情書女孩收到了疏尿,并且從回信中知道了女孩喜歡自己,并且愿意和自己交往币叹。然后男孩又寫了一封信告訴女孩:你的心意和信我都收到了润歉,謝謝你,還有我愛你颈抚!女孩收到男孩的回信之后踩衩,也很開心,因為發(fā)出的情書男孩收到了贩汉。由此男孩女孩雙方都知道了彼此的心意驱富,之后就快樂地交流起來了~~這就是通俗版的“三次握手”,期間一共往來了三封信也就是“三次握手”匹舞,以此確認(rèn)兩個方向上的數(shù)據(jù)傳輸通道是否正常褐鸥。

4.為什么要進行第三次握手?

為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷以及防止已失效的連接請求報文段突然又傳送到了服務(wù)端赐稽,因而產(chǎn)生錯誤叫榕。

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

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

客戶端可能設(shè)置了一個超時時間史飞,時間到了就關(guān)閉了連接創(chuàng)建的請求尖昏。再重新發(fā)出創(chuàng)建連接的請求,而服務(wù)器端是不知道的构资,如果沒有第三次握手告訴服務(wù)器端客戶端收的到服務(wù)器端傳輸?shù)臄?shù)據(jù)的話抽诉,

服務(wù)器端是不知道客戶端有沒有接收到服務(wù)器端返回的信息的。

這個過程可理解為:
image

這樣沒有給服務(wù)器端一個創(chuàng)建還是關(guān)閉連接端口的請求吐绵,服務(wù)器端的端口就一直開著掸鹅,等到客戶端因超時重新發(fā)出請求時,服務(wù)器就會重新開啟一個端口連接拦赠。那么服務(wù)器端上沒有接收到請求數(shù)據(jù)的上一個端口就一直開著,長此以往葵姥,這樣的端口多了荷鼠,就會造成服務(wù)器端開銷的嚴(yán)重浪費。還有一種情況是已經(jīng)失效的客戶端發(fā)出的請求信息榔幸,由于某種原因傳輸?shù)搅朔?wù)器端允乐,服務(wù)器端以為是客戶端發(fā)出的有效請求矮嫉,接收后產(chǎn)生錯誤。所以我們需要“第三次握手”來確認(rèn)這個過程牍疏,讓客戶端和服務(wù)器端能夠及時地察覺到因為網(wǎng)絡(luò)等一些問題導(dǎo)致的連接創(chuàng)建失敗蠢笋,這樣服務(wù)器端的端口就可以關(guān)閉了不用一直等待。也可以這樣理解:“第三次握手”是客戶端向服務(wù)器端發(fā)送數(shù)據(jù)鳞陨,這個數(shù)據(jù)就是要告訴服務(wù)器昨寞,客戶端有沒有收到服務(wù)器“第二次握手”時傳過去的數(shù)據(jù)。若發(fā)送的這個數(shù)據(jù)是“收到了”的信息厦滤,接收后服務(wù)器就正常建立TCP連接援岩,否則建立TCP連接失敗,服務(wù)器關(guān)閉連接端口掏导。由此減少服務(wù)器開銷和接收到失效請求發(fā)生的錯誤享怀。

5.抓包驗證

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

圖中顯示的就是完整的TCP連接的”三次握手”過程趟咆。在52528 -> 80中添瓷,52528是本地(客戶端)端口,80是服務(wù)器的端口值纱。80端口和52528端口之間的三次來回就是"三次握手"過程鳞贷。注意到”第一次握手”客戶端發(fā)送的TCP報文中以[SYN]作為標(biāo)志位,并且客戶端序號Seq=0计雌; 接下來”第二次握手”服務(wù)器返回的TCP報文中以[SYN悄晃,ACK]作為標(biāo)志位;并且服務(wù)器端序號Seq=0凿滤;確認(rèn)號Ack=1(“第一次握手”中客戶端序號Seq的值+1);最后”第三次握手”客戶端再向服務(wù)器端發(fā)送的TCP報文中以[ACK]作為標(biāo)志位妈橄;其中客戶端序號Seq=1(“第二次握手”中服務(wù)器端確認(rèn)號Ack的值);確認(rèn)號Ack=1(“第二次握手”中服務(wù)器端序號Seq的值+1)翁脆。這就完成了”三次握手”的過程眷蚓,符合前面分析的結(jié)果。

image

TCP的四次揮手(Four-Way Wavehand)

1反番、前言

對于"三次握手"我們耳熟能詳沙热,因為其相對的簡單。但是罢缸,我們卻不常聽見“四次揮手”篙贸,就算聽過也未必能詳細(xì)地說明白它的具體過程。下面就為大家詳盡枫疆,直觀爵川,完整地介紹“四次揮手”的過程。

2息楔、“四次揮手”的詳解

所謂的四次揮手即TCP連接的釋放(解除)寝贡。連接的釋放必須是一方主動釋放扒披,另一方被動釋放。以下為客戶端主動發(fā)起釋放連接的圖解:
image

揮手之前主動釋放連接的客戶端結(jié)束ESTABLISHED階段圃泡。隨后開始“四次揮手”:

(1)首先客戶端想要釋放連接碟案,向服務(wù)器端發(fā)送一段TCP報文,其中:

  • 標(biāo)記位為FIN颇蜡,表示“請求釋放連接“价说;

  • 序號為Seq=U;

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

注意:這里不發(fā)送的是正常連接時傳輸?shù)臄?shù)據(jù)(非確認(rèn)報文)疑苔,而不是一切數(shù)據(jù),所以客戶端仍然能發(fā)送ACK確認(rèn)報文甸鸟。(2)服務(wù)器端接收到從客戶端發(fā)出的TCP報文之后惦费,確認(rèn)了客戶端想要釋放連接,隨后服務(wù)器端結(jié)束ESTABLISHED階段抢韭,進入CLOSE-WAIT階段(半關(guān)閉狀態(tài))并返回一段TCP報文薪贫,其中:

  • 標(biāo)記位為ACK,表示“接收到客戶端發(fā)送的釋放連接的請求”刻恭;

  • 序號為Seq=V瞧省;

  • 確認(rèn)號為Ack=U+1,表示是在收到客戶端報文的基礎(chǔ)上鳍贾,將其序號Seq值加1作為本段報文確認(rèn)號Ack的值鞍匾;

  • 隨后服務(wù)器端開始準(zhǔn)備釋放服務(wù)器端到客戶端方向上的連接。

客戶端收到從服務(wù)器端發(fā)出的TCP報文之后骑科,確認(rèn)了服務(wù)器收到了客戶端發(fā)出的釋放連接請求橡淑,隨后客戶端結(jié)束FIN-WAIT-1階段,進入FIN-WAIT-2階段

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

(3)服務(wù)器端自從發(fā)出ACK確認(rèn)報文之后斗埂,經(jīng)過CLOSED-WAIT階段符糊,做好了釋放服務(wù)器端到客戶端方向上的連接準(zhǔn)備,再次向客戶端發(fā)出一段TCP報文呛凶,其中:

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

  • 序號為Seq=W;

  • 確認(rèn)號為Ack=U+1县好;表示是在收到客戶端報文的基礎(chǔ)上围橡,將其序號Seq值加1作為本段報文確認(rèn)號Ack的值。

隨后服務(wù)器端結(jié)束CLOSE-WAIT階段缕贡,進入LAST-ACK階段翁授。并且停止在服務(wù)器端到客戶端的方向上發(fā)送數(shù)據(jù),但是服務(wù)器端仍然能夠接收從客戶端傳輸過來的數(shù)據(jù)晾咪。(4)客戶端收到從服務(wù)器端發(fā)出的TCP報文收擦,確認(rèn)了服務(wù)器端已做好釋放連接的準(zhǔn)備,結(jié)束FIN-WAIT-2階段谍倦,進入TIME-WAIT階段塞赂,并向服務(wù)器端發(fā)送一段報文,其中:

  • 標(biāo)記位為ACK昼蛀,表示“接收到服務(wù)器準(zhǔn)備好釋放連接的信號”宴猾。
  • 序號為Seq=U+1;表示是在收到了服務(wù)器端報文的基礎(chǔ)上叼旋,將其確認(rèn)號Ack值作為本段報文序號的值仇哆。
  • 確認(rèn)號為Ack=W+1;表示是在收到了服務(wù)器端報文的基礎(chǔ)上夫植,將其序號Seq值作為本段報文確認(rèn)號的值讹剔。

隨后客戶端開始在TIME-WAIT階段等待2MSL

為什么要客戶端要等待2MSL呢?見后文详民。

服務(wù)器端收到從客戶端發(fā)出的TCP報文之后結(jié)束LAST-ACK階段延欠,進入CLOSED階段。由此正式確認(rèn)關(guān)閉服務(wù)器端到客戶端方向上的連接阐斜∩蓝常客戶端等待完2MSL之后,結(jié)束TIME-WAIT階段谒出,進入CLOSED階段隅俘,由此完成“四次揮手”。

后“兩次揮手”既讓客戶端知道了服務(wù)器端準(zhǔn)備好釋放連接了笤喳,也讓服務(wù)器端知道了客戶端了解了自己準(zhǔn)備好釋放連接了为居。于是,可以確認(rèn)關(guān)閉服務(wù)器端到客戶端方向上的連接了杀狡,由此完成“四次揮手”蒙畴。

與“三次揮手”一樣,在客戶端與服務(wù)器端傳輸?shù)腡CP報文中,雙方的確認(rèn)號Ack和序號Seq的值膳凝,都是在彼此Ack和Seq值的基礎(chǔ)上進行計算的碑隆,這樣做保證了TCP報文傳輸?shù)倪B貫性,一旦出現(xiàn)某一方發(fā)出的TCP報文丟失蹬音,便無法繼續(xù)"揮手"上煤,以此確保了"四次揮手"的順利完成。

3著淆、“四次揮手”的通俗理解

image

舉個栗子:把客戶端比作男孩劫狠,服務(wù)器比作女孩。通過他們的分手來說明“四次揮手”過程永部。

  • "第一次揮手":日久見人心独泞,男孩發(fā)現(xiàn)女孩變成了自己討厭的樣子,忍無可忍苔埋,于是決定分手懦砂,隨即寫了一封信告訴女孩。
  • “第二次揮手”:女孩收到信之后讲坎,知道了男孩要和自己分手孕惜,怒火中燒,心中暗罵:你算什么東西晨炕,當(dāng)初你可不是這個樣子的衫画!于是立馬給男孩寫了一封回信:分手就分手,給我點時間瓮栗,我要把你的東西整理好削罩,全部還給你!
    男孩收到女孩的第一封信之后费奸,明白了女孩知道自己要和她分手弥激。隨后等待女孩把自己的東西收拾好。
  • “第三次揮手”:過了幾天愿阐,女孩把男孩送的東西都整理好了微服,于是再次寫信給男孩:你的東西我整理好了,快把它們拿走缨历,從此你我恩斷義絕以蕴!
  • “第四次揮手”:男孩收到女孩第二封信之后,知道了女孩收拾好東西了辛孵,可以正式分手了丛肮,于是再次寫信告訴女孩:我知道了,這就去拿回來魄缚!

這里雙方都有各自的堅持宝与。

  • 女孩自發(fā)出第二封信開始,限定一天內(nèi)收不到男孩回信,就會再發(fā)一封信催促男孩來取東西习劫!
  • 男孩自發(fā)出第二封信開始咆瘟,限定兩天內(nèi)沒有再次收到女孩的信就認(rèn)為,女孩收到了自己的第二封信诽里;若兩天內(nèi)再次收到女孩的來信搞疗,就認(rèn)為自己的第二封信女孩沒收到,需要再寫一封信须肆,再等兩天…..

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

4.為什么“握手”是三次,“揮手”卻要四次泄隔?

TCP建立連接時之所以只需要"三次握手"拒贱,是因為在第二次"握手"過程中,服務(wù)器端發(fā)送給客戶端的TCP報文是以SYN與ACK作為標(biāo)志位的佛嬉。SYN是請求連接標(biāo)志逻澳,表示服務(wù)器端同意建立連接;ACK是確認(rèn)報文暖呕,表示告訴客戶端斜做,服務(wù)器端收到了它的請求報文。即SYN建立連接報文與ACK確認(rèn)接收報文是在同一次"握手"當(dāng)中傳輸?shù)耐謇浚?三次握手"不多也不少瓤逼,正好讓雙方明確彼此信息互通。TCP釋放連接時之所以需要“四次揮手”,是因為FIN釋放連接報文與ACK確認(rèn)接收報文是分別由第二次和第三次"握手"傳輸?shù)目馕铩楹谓⑦B接時一起傳輸霸旗,釋放連接時卻要分開傳輸?

  • 建立連接時戚揭,被動方服務(wù)器端結(jié)束CLOSED階段進入“握手”階段并不需要任何準(zhǔn)備诱告,可以直接返回SYN和ACK報文,開始建立連接民晒。
  • 釋放連接時精居,被動方服務(wù)器,突然收到主動方客戶端釋放連接的請求時并不能立即釋放連接镀虐,因為還有必要的數(shù)據(jù)需要處理箱蟆,所以服務(wù)器先返回ACK確認(rèn)收到報文,經(jīng)過CLOSE-WAIT階段準(zhǔn)備好釋放連接之后刮便,才能返回FIN釋放連接報文空猜。

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

5.為什么客戶端在TIME-WAIT階段要等2MSL?

為的是確認(rèn)服務(wù)器端是否收到客戶端發(fā)出的ACK確認(rèn)報文當(dāng)客戶端發(fā)出最后的ACK確認(rèn)報文時辈毯,并不能確定服務(wù)器端能夠收到該段報文坝疼。所以客戶端在發(fā)送完ACK確認(rèn)報文之后,會設(shè)置一個時長為2MSL的計時器谆沃。MSL指的是Maximum Segment Lifetime:一段TCP報文在傳輸過程中的最大生命周期钝凶。2MSL即是服務(wù)器端發(fā)出為FIN報文和客戶端發(fā)出的ACK確認(rèn)報文所能保持有效的最大時長。服務(wù)器端在1MSL內(nèi)沒有收到客戶端發(fā)出的ACK確認(rèn)報文唁影,就會再次向客戶端發(fā)出FIN報文耕陷;

  • 如果客戶端在2MSL內(nèi),再次收到了來自服務(wù)器端的FIN報文据沈,說明服務(wù)器端由于各種原因沒有接收到客戶端發(fā)出的ACK確認(rèn)報文哟沫。客戶端再次向服務(wù)器端發(fā)出ACK確認(rèn)報文锌介,計時器重置嗜诀,重新開始2MSL的計時;
  • 否則客戶端在2MSL內(nèi)沒有再次收到來自服務(wù)器端的FIN報文孔祸,說明服務(wù)器端正常接收了ACK確認(rèn)報文隆敢,客戶端可以進入CLOSED階段,完成“四次揮手”崔慧。

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

6.抓包驗證

image

圖中顯示的就是完整的TCP連接釋放的”四次揮手”過程尊浪。在 80 -> 55389 中匣屡,假設(shè)80是本地(客戶端)端口,55389是服務(wù)器端口拇涤。80端口與55389之間的四次來回就是"四次揮手"過程捣作。

  • ”第一次揮手”客戶端發(fā)送的FIN請求釋放連接報文以[FIN,ACK]作為標(biāo)志位鹅士,其中報文序號Seq=2445券躁;確認(rèn)號Ack=558;
    注意:這里與“第三次握手”的ACK并不是表示確認(rèn)的ACK報文掉盅。
  • ”第二次揮手”服務(wù)器端返回的ACK確認(rèn)報文以[ACK]作為標(biāo)志位也拜;其中報文序號Seq=558;確認(rèn)號Ack=2246趾痘;
  • ”第三次揮手”服務(wù)器端繼續(xù)返回的FIN同意釋放連接報文以[FIN慢哈,ACK]作為標(biāo)志位;其中報文序號Seq=558永票;確認(rèn)號Ack=2246卵贱;
  • ”第四次揮手”客戶端發(fā)出的ACK確認(rèn)接收報文以[ACK]作為標(biāo)志位滥沫;其中報文序號Seq=2446;確認(rèn)號Ack=559键俱。

后一次“揮手”傳輸報文中的序號Seq值等于前一次"握手"傳輸報文中的確認(rèn)號Ack值兰绣;
后一次“揮手”傳輸報文中的確認(rèn)號Ack值等于前一次"握手"傳輸報文中的序號Seq值;

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市踪央,隨后出現(xiàn)的幾起案子臀玄,更是在濱河造成了極大的恐慌,老刑警劉巖畅蹂,帶你破解...
    沈念sama閱讀 216,372評論 6 498
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件镐牺,死亡現(xiàn)場離奇詭異,居然都是意外死亡魁莉,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,368評論 3 392
  • 文/潘曉璐 我一進店門募胃,熙熙樓的掌柜王于貴愁眉苦臉地迎上來旗唁,“玉大人,你說我怎么就攤上這事痹束〖煲撸” “怎么了?”我有些...
    開封第一講書人閱讀 162,415評論 0 353
  • 文/不壞的土叔 我叫張陵祷嘶,是天一觀的道長屎媳。 經(jīng)常有香客問我,道長论巍,這世上最難降的妖魔是什么烛谊? 我笑而不...
    開封第一講書人閱讀 58,157評論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮嘉汰,結(jié)果婚禮上丹禀,老公的妹妹穿的比我還像新娘。我一直安慰自己鞋怀,他們只是感情好双泪,可當(dāng)我...
    茶點故事閱讀 67,171評論 6 388
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著密似,像睡著了一般焙矛。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上残腌,一...
    開封第一講書人閱讀 51,125評論 1 297
  • 那天村斟,我揣著相機與錄音贫导,去河邊找鬼。 笑死邓梅,一個胖子當(dāng)著我的面吹牛脱盲,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播日缨,決...
    沈念sama閱讀 40,028評論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼钱反,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了匣距?” 一聲冷哼從身側(cè)響起面哥,我...
    開封第一講書人閱讀 38,887評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎毅待,沒想到半個月后尚卫,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,310評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡尸红,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,533評論 2 332
  • 正文 我和宋清朗相戀三年吱涉,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片外里。...
    茶點故事閱讀 39,690評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡怎爵,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出盅蝗,到底是詐尸還是另有隱情鳖链,我是刑警寧澤,帶...
    沈念sama閱讀 35,411評論 5 343
  • 正文 年R本政府宣布墩莫,位于F島的核電站芙委,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏狂秦。R本人自食惡果不足惜灌侣,卻給世界環(huán)境...
    茶點故事閱讀 41,004評論 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望裂问。 院中可真熱鬧顶瞳,春花似錦、人聲如沸愕秫。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,659評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽戴甩。三九已至符喝,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間甜孤,已是汗流浹背协饲。 一陣腳步聲響...
    開封第一講書人閱讀 32,812評論 1 268
  • 我被黑心中介騙來泰國打工畏腕, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人茉稠。 一個月前我還...
    沈念sama閱讀 47,693評論 2 368
  • 正文 我出身青樓描馅,卻偏偏與公主長得像,于是被迫代替她去往敵國和親而线。 傳聞我的和親對象是個殘疾皇子铭污,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,577評論 2 353

推薦閱讀更多精彩內(nèi)容