原文:https://www.cnblogs.com/AhuntSun-blog/p/12028636.html
聲明:本文為作者投稿,版權(quán)歸作者個人所有琼讽。
TCP connection
客戶端與服務(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請求曙蒸。
其中比較重要的字段有:
(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石蔗,兩端配對罕邀。
TCP的三次握手(Three-Way Handshake)
1.”三次握手”的詳解
所謂的三次握手即TCP連接的建立。這個連接必須是一方主動打開养距,另一方被動打開的诉探。
握手之前主動打開連接的客戶端結(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)過程
3.“三次握手”的通俗理解
舉個栗子:把客戶端比作男孩宪哩,服務(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ù)器端返回的信息的。
這個過程可理解為:這樣沒有給服務(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的三次握手:圖中顯示的就是完整的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é)果。
TCP的四次揮手(Four-Way Wavehand)
1反番、前言
對于"三次握手"我們耳熟能詳沙热,因為其相對的簡單。但是罢缸,我們卻不常聽見“四次揮手”篙贸,就算聽過也未必能詳細(xì)地說明白它的具體過程。下面就為大家詳盡枫疆,直觀爵川,完整地介紹“四次揮手”的過程。
2息楔、“四次揮手”的詳解
所謂的四次揮手即TCP連接的釋放(解除)寝贡。連接的釋放必須是一方主動釋放扒披,另一方被動釋放。以下為客戶端主動發(fā)起釋放連接的圖解:揮手之前主動釋放連接的客戶端結(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著淆、“四次揮手”的通俗理解
舉個栗子:把客戶端比作男孩劫狠,服務(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.抓包驗證
圖中顯示的就是完整的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ù)的“四次揮手”過程编振,與前面的分析相符缀辩。