国产 无码 综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?

這篇具有很好參考價(jià)值的文章主要介紹了面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方,請(qǐng)大家不吝賜教,您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問(wèn)。

三次握手和四次揮手是各個(gè)公司常見(jiàn)的考點(diǎn),一個(gè)簡(jiǎn)單的問(wèn)題,卻能看出面試者對(duì)網(wǎng)絡(luò)協(xié)議的掌握程度,對(duì)問(wèn)題分析與解決能力,以及數(shù)據(jù)流管理理解和異常情況應(yīng)對(duì)能力。所以回答好一個(gè)tcp的三次握手和四次揮手的問(wèn)題對(duì)于我們的面試成功與否還是有著很大的影響。

接下來(lái)我們就回來(lái)好好回答一下tcp的三次握手和四次揮手。

  1. 三次握手
    三次握手(Three-way Handshake)其實(shí)就是指建立一個(gè)TCP連接時(shí),需要客戶端和服務(wù)器總共發(fā)送3個(gè)包。進(jìn)行三次握手的主要作用就是為了確認(rèn)雙方的接收能力和發(fā)送能力是否正常、指定自己的初始化序列號(hào)為后面的可靠性傳送做準(zhǔn)備。實(shí)質(zhì)上其實(shí)就是連接服務(wù)器指定端口,建立TCP連接,并同步連接雙方的序列號(hào)和確認(rèn)號(hào),交換TCP窗口大小信息。

剛開(kāi)始客戶端處于 Closed 的狀態(tài),服務(wù)端處于 Listen 狀態(tài)。 進(jìn)行三次握手:

第一次握手:客戶端給服務(wù)端發(fā)一個(gè) SYN 報(bào)文,并指明客戶端的初始化序列號(hào) ISN?。此時(shí)客戶端處于 SYN_SEND 狀態(tài)。

首部的同步位SYN=1,初始序號(hào)seq=x,SYN=1的報(bào)文段不能攜帶數(shù)據(jù),但要消耗掉一個(gè)序號(hào)。

第二次握手:服務(wù)器收到客戶端的 SYN 報(bào)文之后,會(huì)以自己的 SYN 報(bào)文作為應(yīng)答,并且也是指定了自己的初始化序列號(hào) ISN(s)。同時(shí)會(huì)把客戶端的 ISN + 1 作為ACK 的值,表示自己已經(jīng)收到了客戶端的 SYN,此時(shí)服務(wù)器處于 SYN_RCVD 的狀態(tài)。

在確認(rèn)報(bào)文段中SYN=1,ACK=1,確認(rèn)號(hào)ack=x+1,初始序號(hào)seq=y。

第三次握手:客戶端收到 SYN 報(bào)文之后,會(huì)發(fā)送一個(gè) ACK 報(bào)文,當(dāng)然,也是一樣把服務(wù)器的 ISN + 1 作為 ACK 的值,表示已經(jīng)收到了服務(wù)端的 SYN 報(bào)文,此時(shí)客戶端處于 ESTABLISHED 狀態(tài)。服務(wù)器收到 ACK 報(bào)文之后,也處于 ESTABLISHED 狀態(tài),此時(shí),雙方已建立起了連接。

確認(rèn)報(bào)文段ACK=1,確認(rèn)號(hào)ack=y+1,序號(hào)seq=x+1(初始為seq=x,第二個(gè)報(bào)文段所以要+1),ACK報(bào)文段可以攜帶數(shù)據(jù),不攜帶數(shù)據(jù)則不消耗序號(hào)。

發(fā)送第一個(gè)SYN的一端將執(zhí)行主動(dòng)打開(kāi)(active open),接收這個(gè)SYN并發(fā)回下一個(gè)SYN的另一端執(zhí)行被動(dòng)打開(kāi)(passive open)。

在socket編程中,客戶端執(zhí)行connect()時(shí),將觸發(fā)三次握手。
面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?,前端,網(wǎng)絡(luò)傳輸,面試,tcp/ip,職場(chǎng)和發(fā)展

三次握手.png
1.1 為什么需要三次握手,兩次不行嗎?
弄清這個(gè)問(wèn)題,我們需要先弄明白三次握手的目的是什么,能不能只用兩次握手來(lái)達(dá)到同樣的目的。

第一次握手:客戶端發(fā)送網(wǎng)絡(luò)包,服務(wù)端收到了。 這樣服務(wù)端就能得出結(jié)論:客戶端的發(fā)送能力、服務(wù)端的接收能力是正常的。
第二次握手:服務(wù)端發(fā)包,客戶端收到了。 這樣客戶端就能得出結(jié)論:服務(wù)端的接收、發(fā)送能力,客戶端的接收、發(fā)送能力是正常的。不過(guò)此時(shí)服務(wù)器并不能確認(rèn)客戶端的接收能力是否正常。
第三次握手:客戶端發(fā)包,服務(wù)端收到了。 這樣服務(wù)端就能得出結(jié)論:客戶端的接收、發(fā)送能力正常,服務(wù)器自己的發(fā)送、接收能力也正常。
因此,需要三次握手才能確認(rèn)雙方的接收與發(fā)送能力是否正常。

試想如果是用兩次握手,則會(huì)出現(xiàn)下面這種情況:

如客戶端發(fā)出連接請(qǐng)求,但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn),于是客戶端再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn),建立了連接。數(shù)據(jù)傳輸完畢后,就釋放了連接,客戶端共發(fā)出了兩個(gè)連接請(qǐng)求報(bào)文段,其中第一個(gè)丟失,第二個(gè)到達(dá)了服務(wù)端,但是第一個(gè)丟失的報(bào)文段只是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了,延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端,此時(shí)服務(wù)端誤認(rèn)為客戶端又發(fā)出一次新的連接請(qǐng)求,于是就向客戶端發(fā)出確認(rèn)報(bào)文段,同意建立連接,不采用三次握手,只要服務(wù)端發(fā)出確認(rèn),就建立新的連接了,此時(shí)客戶端忽略服務(wù)端發(fā)來(lái)的確認(rèn),也不發(fā)送數(shù)據(jù),則服務(wù)端一致等待客戶端發(fā)送數(shù)據(jù),浪費(fèi)資源。

1.2 什么是半連接隊(duì)列?
服務(wù)器第一次收到客戶端的 SYN 之后,就會(huì)處于 SYN_RCVD 狀態(tài),此時(shí)雙方還沒(méi)有完全建立其連接,服務(wù)器會(huì)把此種狀態(tài)下請(qǐng)求連接放在一個(gè)隊(duì)列里,我們把這種隊(duì)列稱(chēng)之為半連接隊(duì)列。

當(dāng)然還有一個(gè)全連接隊(duì)列,就是已經(jīng)完成三次握手,建立起連接的就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿了就有可能會(huì)出現(xiàn)丟包現(xiàn)象。

這里在補(bǔ)充一點(diǎn)關(guān)于SYN-ACK 重傳次數(shù)的問(wèn)題: 服務(wù)器發(fā)送完SYN-ACK包,如果未收到客戶確認(rèn)包,服務(wù)器進(jìn)行首次重傳,等待一段時(shí)間仍未收到客戶確認(rèn)包,進(jìn)行第二次重傳。如果重傳次數(shù)超過(guò)系統(tǒng)規(guī)定的最大重傳次數(shù),系統(tǒng)將該連接信息從半連接隊(duì)列中刪除。 注意,每次重傳等待的時(shí)間不一定相同,一般會(huì)是指數(shù)增長(zhǎng),例如間隔時(shí)間為 1s,2s,4s,8s…

1.3 ISN(Initial Sequence Number)是固定的嗎?
當(dāng)一端為建立連接而發(fā)送它的SYN時(shí),它為連接選擇一個(gè)初始序號(hào)。ISN隨時(shí)間而變化,因此每個(gè)連接都將具有不同的ISN。ISN可以看作是一個(gè)32比特的計(jì)數(shù)器,每4ms加1 。這樣選擇序號(hào)的目的在于防止在網(wǎng)絡(luò)中被延遲的分組在以后又被傳送,而導(dǎo)致某個(gè)連接的一方對(duì)它做錯(cuò)誤的解釋。

三次握手的其中一個(gè)重要功能是客戶端和服務(wù)端交換 ISN(Initial Sequence Number),以便讓對(duì)方知道接下來(lái)接收數(shù)據(jù)的時(shí)候如何按序列號(hào)組裝數(shù)據(jù)。如果 ISN 是固定的,攻擊者很容易猜出后續(xù)的確認(rèn)號(hào),因此 ISN 是動(dòng)態(tài)生成的。

1.4 三次握手過(guò)程中可以攜帶數(shù)據(jù)嗎?
其實(shí)第三次握手的時(shí)候,是可以攜帶數(shù)據(jù)的。但是,第一次、第二次握手不可以攜帶數(shù)據(jù)

為什么這樣呢?大家可以想一個(gè)問(wèn)題,假如第一次握手可以攜帶數(shù)據(jù)的話,如果有人要惡意攻擊服務(wù)器,那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)。因?yàn)楣粽吒揪筒焕矸?wù)器的接收、發(fā)送能力是否正常,然后瘋狂著重復(fù)發(fā) SYN 報(bào)文的話,這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。

也就是說(shuō),第一次握手不可以放數(shù)據(jù),其中一個(gè)簡(jiǎn)單的原因就是會(huì)讓服務(wù)器更加容易受到攻擊了。而對(duì)于第三次的話,此時(shí)客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)。對(duì)于客戶端來(lái)說(shuō),他已經(jīng)建立起連接了,并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了,所以能攜帶數(shù)據(jù)也沒(méi)啥毛病。

1.5 SYN攻擊是什么?
服務(wù)器端的資源分配是在二次握手時(shí)分配的,而客戶端的資源是在完成三次握手時(shí)分配的,所以服務(wù)器容易受到SYN洪泛攻擊。SYN攻擊就是Client在短時(shí)間內(nèi)偽造大量不存在的IP地址,并向Server不斷地發(fā)送SYN包,Server則回復(fù)確認(rèn)包,并等待Client確認(rèn),由于源地址不存在,因此Server需要不斷重發(fā)直至超時(shí),這些偽造的SYN包將長(zhǎng)時(shí)間占用未連接隊(duì)列,導(dǎo)致正常的SYN請(qǐng)求因?yàn)殛?duì)列滿而被丟棄,從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓。SYN 攻擊是一種典型的 DoS/DDoS 攻擊。

檢測(cè) SYN 攻擊非常的方便,當(dāng)你在服務(wù)器上看到大量的半連接狀態(tài)時(shí),特別是源IP地址是隨機(jī)的,基本上可以斷定這是一次SYN攻擊。在 Linux/Unix 上可以使用系統(tǒng)自帶的 netstats 命令來(lái)檢測(cè) SYN 攻擊。

1c
復(fù)制代碼
netstat -n -p TCP | grep SYN_RECV
常見(jiàn)的防御 SYN 攻擊的方法有如下幾種:

縮短超時(shí)(SYN Timeout)時(shí)間
增加最大半連接數(shù)
過(guò)濾網(wǎng)關(guān)防護(hù)
SYN cookies技術(shù)
2. 四次揮手
建立一個(gè)連接需要三次握手,而終止一個(gè)連接要經(jīng)過(guò)四次揮手(也有將四次揮手叫做四次握手的)。這由TCP的半關(guān)閉(half-close)造成的。所謂的半關(guān)閉,其實(shí)就是TCP提供了連接的一端在結(jié)束它的發(fā)送后還能接收來(lái)自另一端數(shù)據(jù)的能力。

TCP 的連接的拆除需要發(fā)送四個(gè)包,因此稱(chēng)為四次揮手(Four-way handshake),客戶端或服務(wù)器均可主動(dòng)發(fā)起揮手動(dòng)作。

剛開(kāi)始雙方都處于 ESTABLISHED 狀態(tài),假如是客戶端先發(fā)起關(guān)閉請(qǐng)求。四次揮手的過(guò)程如下:

第一次揮手:客戶端發(fā)送一個(gè) FIN 報(bào)文,報(bào)文中會(huì)指定一個(gè)序列號(hào)。此時(shí)客戶端處于 FIN_WAIT1 狀態(tài)。 即發(fā)出連接釋放報(bào)文段(FIN=1,序號(hào)seq=u),并停止再發(fā)送數(shù)據(jù),主動(dòng)關(guān)閉TCP連接,進(jìn)入FIN_WAIT1(終止等待1)狀態(tài),等待服務(wù)端的確認(rèn)。
第二次揮手:服務(wù)端收到 FIN 之后,會(huì)發(fā)送 ACK 報(bào)文,且把客戶端的序列號(hào)值 +1 作為 ACK 報(bào)文的序列號(hào)值,表明已經(jīng)收到客戶端的報(bào)文了,此時(shí)服務(wù)端處于 CLOSE_WAIT 狀態(tài)。 即服務(wù)端收到連接釋放報(bào)文段后即發(fā)出確認(rèn)報(bào)文段(ACK=1,確認(rèn)號(hào)ack=u+1,序號(hào)seq=v),服務(wù)端進(jìn)入CLOSE_WAIT(關(guān)閉等待)狀態(tài),此時(shí)的TCP處于半關(guān)閉狀態(tài),客戶端到服務(wù)端的連接釋放。客戶端收到服務(wù)端的確認(rèn)后,進(jìn)入FIN_WAIT2(終止等待2)狀態(tài),等待服務(wù)端發(fā)出的連接釋放報(bào)文段。
第三次揮手:如果服務(wù)端也想斷開(kāi)連接了,和客戶端的第一次揮手一樣,發(fā)給 FIN 報(bào)文,且指定一個(gè)序列號(hào)。此時(shí)服務(wù)端處于 LAST_ACK 的狀態(tài)。 即服務(wù)端沒(méi)有要向客戶端發(fā)出的數(shù)據(jù),服務(wù)端發(fā)出連接釋放報(bào)文段(FIN=1,ACK=1,序號(hào)seq=w,確認(rèn)號(hào)ack=u+1),服務(wù)端進(jìn)入LAST_ACK(最后確認(rèn))狀態(tài),等待客戶端的確認(rèn)。
第四次揮手:客戶端收到 FIN 之后,一樣發(fā)送一個(gè) ACK 報(bào)文作為應(yīng)答,且把服務(wù)端的序列號(hào)值 +1 作為自己 ACK 報(bào)文的序列號(hào)值,此時(shí)客戶端處于 TIME_WAIT 狀態(tài)。需要過(guò)一陣子以確保服務(wù)端收到自己的 ACK 報(bào)文之后才會(huì)進(jìn)入 CLOSED 狀態(tài),服務(wù)端收到 ACK 報(bào)文之后,就處于關(guān)閉連接了,處于 CLOSED 狀態(tài)。 即客戶端收到服務(wù)端的連接釋放報(bào)文段后,對(duì)此發(fā)出確認(rèn)報(bào)文段(ACK=1,seq=u+1,ack=w+1),客戶端進(jìn)入TIME_WAIT(時(shí)間等待)狀態(tài)。此時(shí)TCP未釋放掉,需要經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器設(shè)置的時(shí)間2MSL后,客戶端才進(jìn)入CLOSED狀態(tài)。
收到一個(gè)FIN只意味著在這一方向上沒(méi)有數(shù)據(jù)流動(dòng)??蛻舳藞?zhí)行主動(dòng)關(guān)閉并進(jìn)入TIME_WAIT是正常的,服務(wù)端通常執(zhí)行被動(dòng)關(guān)閉,不會(huì)進(jìn)入TIME_WAIT狀態(tài)。

在socket編程中,任何一方執(zhí)行close()操作即可產(chǎn)生揮手操作。
面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?,前端,網(wǎng)絡(luò)傳輸,面試,tcp/ip,職場(chǎng)和發(fā)展

image.png
2.1 揮手為什么需要四次?
因?yàn)楫?dāng)服務(wù)端收到客戶端的SYN連接請(qǐng)求報(bào)文后,可以直接發(fā)送SYN+ACK報(bào)文。其中ACK報(bào)文是用來(lái)應(yīng)答的,SYN報(bào)文是用來(lái)同步的。但是關(guān)閉連接時(shí),當(dāng)服務(wù)端收到FIN報(bào)文時(shí),很可能并不會(huì)立即關(guān)閉SOCKET,所以只能先回復(fù)一個(gè)ACK報(bào)文,告訴客戶端,“你發(fā)的FIN報(bào)文我收到了”。只有等到我服務(wù)端所有的報(bào)文都發(fā)送完了,我才能發(fā)送FIN報(bào)文,因此不能一起發(fā)送。故需要四次揮手。

2.2 2MSL等待狀態(tài)
TIME_WAIT狀態(tài)也成為2MSL等待狀態(tài)。每個(gè)具體TCP實(shí)現(xiàn)必須選擇一個(gè)報(bào)文段最大生存時(shí)間MSL(Maximum Segment Lifetime),它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長(zhǎng)時(shí)間。這個(gè)時(shí)間是有限的,因?yàn)門(mén)CP報(bào)文段以IP數(shù)據(jù)報(bào)在網(wǎng)絡(luò)內(nèi)傳輸,而IP數(shù)據(jù)報(bào)則有限制其生存時(shí)間的TTL字段。

對(duì)一個(gè)具體實(shí)現(xiàn)所給定的MSL值,處理的原則是:當(dāng)TCP執(zhí)行一個(gè)主動(dòng)關(guān)閉,并發(fā)回最后一個(gè)ACK,該連接必須在TIME_WAIT狀態(tài)停留的時(shí)間為2倍的MSL。這樣可讓TCP再次發(fā)送最后的ACK以防這個(gè)ACK丟失(另一端超時(shí)并重發(fā)最后的FIN)。

這種2MSL等待的另一個(gè)結(jié)果是這個(gè)TCP連接在2MSL等待期間,定義這個(gè)連接的插口(客戶的IP地址和端口號(hào),服務(wù)器的IP地址和端口號(hào))不能再被使用。這個(gè)連接只能在2MSL結(jié)束后才能再被使用。

2.3 四次揮手釋放連接時(shí),等待2MSL的意義?
MSL是Maximum Segment Lifetime的英文縮寫(xiě),可譯為“最長(zhǎng)報(bào)文段壽命”,它是任何報(bào)文在網(wǎng)絡(luò)上存在的最長(zhǎng)時(shí)間,超過(guò)這個(gè)時(shí)間報(bào)文將被丟棄。

為了保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)器。因?yàn)檫@個(gè)ACK有可能丟失,從而導(dǎo)致處在LAST-ACK狀態(tài)的服務(wù)器收不到對(duì)FIN-ACK的確認(rèn)報(bào)文。服務(wù)器會(huì)超時(shí)重傳這個(gè)FIN-ACK,接著客戶端再重傳一次確認(rèn),重新啟動(dòng)時(shí)間等待計(jì)時(shí)器。最后客戶端和服務(wù)器都能正常的關(guān)閉。假設(shè)客戶端不等待2MSL,而是在發(fā)送完ACK之后直接釋放關(guān)閉,一但這個(gè)ACK丟失的話,服務(wù)器就無(wú)法正常的進(jìn)入關(guān)閉連接狀態(tài)。

兩個(gè)理由:
保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)端。 這個(gè)ACK報(bào)文段有可能丟失,使得處于LAST-ACK狀態(tài)的B收不到對(duì)已發(fā)送的FIN+ACK報(bào)文段的確認(rèn),服務(wù)端超時(shí)重傳FIN+ACK報(bào)文段,而客戶端能在2MSL時(shí)間內(nèi)收到這個(gè)重傳的FIN+ACK報(bào)文段,接著客戶端重傳一次確認(rèn),重新啟動(dòng)2MSL計(jì)時(shí)器,最后客戶端和服務(wù)端都進(jìn)入到CLOSED狀態(tài),若客戶端在TIME-WAIT狀態(tài)不等待一段時(shí)間,而是發(fā)送完ACK報(bào)文段后立即釋放連接,則無(wú)法收到服務(wù)端重傳的FIN+ACK報(bào)文段,所以不會(huì)再發(fā)送一次確認(rèn)報(bào)文段,則服務(wù)端無(wú)法正常進(jìn)入到CLOSED狀態(tài)。
防止“已失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。 客戶端在發(fā)送完最后一個(gè)ACK報(bào)文段后,再經(jīng)過(guò)2MSL,就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失,使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。
2.4 為什么TIME_WAIT狀態(tài)需要經(jīng)過(guò)2MSL才能返回到CLOSE狀態(tài)?
理論上,四個(gè)報(bào)文都發(fā)送完畢,就可以直接進(jìn)入CLOSE狀態(tài)了,但是可能網(wǎng)絡(luò)是不可靠的,有可能最后一個(gè)ACK丟失。所以TIME_WAIT狀態(tài)就是用來(lái)重發(fā)可能丟失的ACK報(bào)文。

  1. 總結(jié)
    《TCP/IP詳解 卷1:協(xié)議》有一張TCP狀態(tài)變遷圖,很具有代表性,有助于大家理解三次握手和四次揮手的狀態(tài)變化。如下圖所示,粗的實(shí)線箭頭表示正常的客戶端狀態(tài)變遷,粗的虛線箭頭表示正常的服務(wù)器狀態(tài)變遷。

面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?,前端,網(wǎng)絡(luò)傳輸,面試,tcp/ip,職場(chǎng)和發(fā)展文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-643160.html

到了這里,關(guān)于面試常問(wèn):tcp的三次握手和四次揮手你了解嗎?的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!

本文來(lái)自互聯(lián)網(wǎng)用戶投稿,該文觀點(diǎn)僅代表作者本人,不代表本站立場(chǎng)。本站僅提供信息存儲(chǔ)空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載,請(qǐng)注明出處: 如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符,請(qǐng)點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋,一經(jīng)查實(shí),立即刪除!

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

相關(guān)文章

  • TCP的三次握手和四次揮手······詳解

    TCP的三次握手和四次揮手······詳解

    三次握手是 建立連接 的過(guò)程 如圖大致為三次握手的流程圖: 當(dāng)客戶端對(duì)服務(wù)端發(fā)起連接時(shí),會(huì) 先發(fā)一個(gè)包 連接請(qǐng)求數(shù)據(jù),去詢問(wèn)能否建立連接,該數(shù)據(jù)包稱(chēng)為 “SYN”包 然后,如果對(duì)方同意連接,那么對(duì)方將會(huì)回復(fù)一個(gè) “SYN+ACK”包 客戶端收到后,回復(fù)一個(gè) “ACK”包 ,連

    2024年02月09日
    瀏覽(25)
  • TCP中的三次握手和四次揮手

    TCP中的三次握手和四次揮手

    TCP中的連接和斷開(kāi)可以說(shuō)是在面試中經(jīng)常被問(wèn)到的問(wèn)題之一,正好有空就總結(jié)一下,首先回顧一下TCP的相關(guān)知識(shí)點(diǎn) 1.1 TCP的基本概念 我們知道TCP是運(yùn)輸層的面向連接的可靠的傳輸協(xié)議。 面向連接的 ,指的就是在兩個(gè)進(jìn)程發(fā)送數(shù)據(jù)之前,必須先相互“握手”,確保兩進(jìn)程可以

    2024年02月03日
    瀏覽(21)
  • TCP協(xié)議的三次握手和四次揮手

    TCP協(xié)議的三次握手和四次揮手

    完整的TCP內(nèi)容,請(qǐng)參考RFC 9293 TCP協(xié)議為應(yīng)用提供可靠的、有序的的字節(jié)流服務(wù)。TCP是面向連接的,提供了全雙工的通信。TCP使用端口號(hào)來(lái)識(shí)別應(yīng)用程序服務(wù)并在主機(jī)之間復(fù)用不同的流。 TCP header也像IP header一樣,在header中提供了一些專(zhuān)門(mén)用于TCP的信息,TCP header之后就是用戶數(shù)

    2024年02月06日
    瀏覽(20)
  • 詳解TCP/IP的三次握手和四次揮手

    詳解TCP/IP的三次握手和四次揮手

    本文章講解TCP/IP協(xié)議的三次握手和四次揮手的流程。 三次握手:為了對(duì)每次發(fā)送的數(shù)據(jù)量進(jìn)行跟蹤與協(xié)商,確保數(shù)據(jù)段的發(fā)送和接收同步,根據(jù)所接收到的數(shù)據(jù)量而確認(rèn)數(shù)據(jù)發(fā)送、接收完畢后何時(shí)撤消聯(lián)系,并建立虛連接。 TCP協(xié)議位于傳輸層,作用是提供可靠的字節(jié)流服務(wù)

    2024年02月09日
    瀏覽(27)
  • 【計(jì)算機(jī)網(wǎng)絡(luò)】TCP 的三次握手和四次揮手

    【計(jì)算機(jī)網(wǎng)絡(luò)】TCP 的三次握手和四次揮手

    TCP 是面向連接的,面向連接就是數(shù)據(jù)通訊的時(shí)候需要進(jìn)行三次握手,斷開(kāi)通訊的時(shí)候需要進(jìn)行四次揮手。 1.seq(sequence number),序列號(hào),隨機(jī)生成的 2.ack(acknowledgement number),確認(rèn)號(hào),ack=seq+1 3.ACK(acknowledgement),確定序列號(hào)有效 4.SYN(synchronous),發(fā)起新連接 5.FIN(FINISH),完成 TCP三次

    2024年02月10日
    瀏覽(23)
  • 【Linux 網(wǎng)絡(luò)】 傳輸層協(xié)議之TCP協(xié)議 && TCP的三次握手和四次揮手

    【Linux 網(wǎng)絡(luò)】 傳輸層協(xié)議之TCP協(xié)議 && TCP的三次握手和四次揮手

    傳輸控制協(xié)議(TCP,Transmission Control Protocol)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議 基于TCP應(yīng)用層協(xié)議 HTTP HTTPS SSH Telnet FTP SMTP 源/目的端口號(hào): 表示數(shù)據(jù)是從哪個(gè)進(jìn)程來(lái), 到哪個(gè)進(jìn)程去 32位序號(hào)/確認(rèn)序號(hào):TCP的確認(rèn)應(yīng)答機(jī)制要使用到的字段,保證TCP的可靠

    2024年02月14日
    瀏覽(25)
  • 數(shù)通王國(guó)歷險(xiǎn)記之TCP協(xié)議的三次握手和四次揮手

    數(shù)通王國(guó)歷險(xiǎn)記之TCP協(xié)議的三次握手和四次揮手

    目錄 前言 ?一、TCP我們稱(chēng)之為可靠的傳輸層協(xié)議,為什么稱(chēng)它為可靠呢? 二、TCP的建立——三次握手 1,提前知道TCP協(xié)議報(bào)文中都有些啥? 2.第一次握手 總的來(lái)說(shuō):就是PC1向PC2發(fā)出一個(gè)同步報(bào)文說(shuō),我想和你建立連接 3,第二次握手 總的來(lái)說(shuō):就是PC2同意和PC1建立連接,同時(shí)確

    2024年02月11日
    瀏覽(19)
  • 計(jì)算機(jī)網(wǎng)絡(luò):TCP協(xié)議的三次握手和四次揮手與UDP協(xié)議區(qū)別.

    計(jì)算機(jī)網(wǎng)絡(luò):TCP協(xié)議的三次握手和四次揮手與UDP協(xié)議區(qū)別.

    TCP協(xié)議: UDP協(xié)議: TCP協(xié)議與UDP協(xié)議都工作在傳輸層. TCP協(xié)議與UDP協(xié)議它們的目標(biāo): TCP協(xié)議與UDP協(xié)議的最大區(qū)別: TCP協(xié)議保持連接的三個(gè)關(guān)鍵步驟: UDP協(xié)議: TCP協(xié)議與UDP協(xié)議主要區(qū)別: 傳輸控制協(xié)議(TCP,Transmission Control Protocol)是一種面向連接的、可靠的、基于字節(jié)流的

    2023年04月15日
    瀏覽(26)
  • 【計(jì)算機(jī)網(wǎng)絡(luò)經(jīng)典面試題】簡(jiǎn)述 TCP 三次握手和四次揮手的過(guò)程

    【計(jì)算機(jī)網(wǎng)絡(luò)經(jīng)典面試題】簡(jiǎn)述 TCP 三次握手和四次揮手的過(guò)程

    1)第一次握手:建立連接時(shí),客戶端向服務(wù)器發(fā)送SYN包(seq=x),請(qǐng)求建立連接,等待確認(rèn) 2)第二次握手:服務(wù)端收到客戶端的SYN包,回一個(gè)ACK包(ACK=x+1)確認(rèn)收到,同時(shí)發(fā)送一個(gè)SYN包(seq=y)給客戶端 3)第三次握手:客戶端收到SYN+ACK包,再回一個(gè)ACK包(ACK=y+1)告訴服務(wù)

    2024年04月08日
    瀏覽(16)
  • TCP的三次握手,四次揮手,面試必會(huì)

    TCP的三次握手,四次揮手,面試必會(huì)

    目錄 一、TCP三次握手(建立連接) 二、TCP三次握手細(xì)節(jié) 三、TCP(四次揮手)斷開(kāi)連接 四、TCP非常重要的協(xié)議 ????握手,單純就是發(fā)一個(gè)打招呼的數(shù)據(jù),不攜帶業(yè)務(wù)信息 那么為什么叫三次握手呢,因?yàn)锽的中間兩次可以合并成一次。 為什么我們要合并呢????? 因?yàn)槲覀兊?/p>

    2024年02月09日
    瀏覽(29)

覺(jué)得文章有用就打賞一下文章作者

支付寶掃一掃打賞

博客贊助

微信掃一掃打賞

請(qǐng)作者喝杯咖啡吧~博客贊助

支付寶掃一掃領(lǐng)取紅包,優(yōu)惠每天領(lǐng)

二維碼1

領(lǐng)取紅包

二維碼2

領(lǐng)紅包