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

TCP的三次握手和四次揮手

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理
TCP(Transmission Control Protocol 傳輸控制協(xié)議)是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議,由IETF的RFC 793定義。

三次握手

TCP連接是通過(guò)三次握手來(lái)連接的。

[[151774]]

***次握手

當(dāng)客戶(hù)端向服務(wù)器發(fā)起連接請(qǐng)求時(shí),客戶(hù)端會(huì)發(fā)送同步序列標(biāo)號(hào)SYN到服務(wù)器,在這里我們?cè)O(shè)SYN為m,等待服務(wù)器確認(rèn),這時(shí)客戶(hù)端的狀態(tài)為SYN_SENT。

第二次握手

當(dāng)服務(wù)器收到客戶(hù)端發(fā)送的SYN后,服務(wù)器要做的是確認(rèn)客戶(hù)端發(fā)送過(guò)來(lái)的SYN,在這里服務(wù)器發(fā)送確認(rèn)包ACK,這里的ACK為m+1,意思是說(shuō)“我收到了你發(fā)送的SYN了”,同時(shí),服務(wù)器也會(huì)向客戶(hù)端發(fā)送一個(gè)SYN包,這里我們?cè)O(shè)SYN為n。這時(shí)服務(wù)器的狀態(tài)為SYN_RECV。

一句話,服務(wù)器端發(fā)送SYN和ACK兩個(gè)包。

第三次握手

客戶(hù)端收到服務(wù)器發(fā)送的SYN和ACK包后,需向服務(wù)器發(fā)送確認(rèn)包ACK,“我也收到你發(fā)送的SYN了,我這就給你發(fā)個(gè)確認(rèn)過(guò)去,然后我們即能合體了”,這里的ACK為n+1,發(fā)送完畢后,客戶(hù)端和服務(wù)器的狀態(tài)為ESTABLISH,即TCP連接成功。

在三次握手中,客戶(hù)端和服務(wù)器端都發(fā)送兩個(gè)包SYN和ACK,只不過(guò)服務(wù)器端的兩個(gè)包是一次性發(fā)過(guò)來(lái)的,客戶(hù)端的兩個(gè)包是分兩次發(fā)送的。

三次握手示意圖如下(純手繪,見(jiàn)諒見(jiàn)諒):

 

四次揮手

當(dāng)A端和B端要斷開(kāi)連接時(shí),需要四次握手,這里稱(chēng)為四次揮手。

斷開(kāi)連接請(qǐng)求可以由客戶(hù)端發(fā)出,也可以由服務(wù)器端發(fā)出,在這里我們稱(chēng)A端向B端請(qǐng)求斷開(kāi)連接。

***次揮手

A端向B端請(qǐng)求斷開(kāi)連接時(shí)會(huì)向B端發(fā)送一個(gè)帶有FIN標(biāo)記的報(bào)文段,這里的FIN是FINish的意思。

第二次揮手

B端收到A發(fā)送的FIN后,B段現(xiàn)在可能現(xiàn)在還有數(shù)據(jù)沒(méi)有傳完,所以B端并不會(huì)馬上向A端發(fā)送FIN,而是先發(fā)送一個(gè)確認(rèn)序號(hào)ACK,意思是說(shuō)“你發(fā)的斷開(kāi)連接請(qǐng)求我收到了,但是我現(xiàn)在還有數(shù)據(jù)沒(méi)有發(fā)完,請(qǐng)稍等一下唄”。

第三次揮手

當(dāng)B端的事情忙完了,那么此時(shí)B端就可以斷開(kāi)連接了,此時(shí)B端向A端發(fā)送FIN序號(hào),意思是這次可以斷開(kāi)連接了。

第四次揮手

A端收到B端發(fā)送的FIN后,會(huì)向B端發(fā)送確認(rèn)ACK,然后經(jīng)過(guò)兩個(gè)MSL時(shí)長(zhǎng)后斷開(kāi)連接。

MSL是Maximum Segment Lifetime,***報(bào)文段生存時(shí)間,2個(gè)MSL是報(bào)文段發(fā)送和接收的最長(zhǎng)時(shí)間。

四次揮手示意圖如下(純手繪,見(jiàn)諒見(jiàn)諒):

 

兩次握手可以么?

TCP連接時(shí)是三次握手,那么兩次握手可行嗎?

在《計(jì)算機(jī)網(wǎng)絡(luò)》中是這樣解釋的:已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下:client發(fā)出的***個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失,而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了,以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來(lái)這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請(qǐng)求報(bào)文段后,就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求。于是就向client發(fā)出確認(rèn)報(bào)文段,同意建立連接。假設(shè)不采用“三次握手”,那么只要server發(fā)出確認(rèn),新的連接就建立了。由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求,因此不會(huì)理睬server的確認(rèn),也不會(huì)向server發(fā)送ACK包。這樣就會(huì)白白浪費(fèi)資源。

而經(jīng)過(guò)三次握手,客戶(hù)端和服務(wù)器都有應(yīng)有答,這樣可以確保TCP正確連接。

為什么TCP連接是三次,揮手確是四次?

在TCP連接中,服務(wù)器端的SYN和ACK向客戶(hù)端發(fā)送是一次性發(fā)送的,而在斷開(kāi)連接的過(guò)程中,B端向A端發(fā)送的ACK和FIN是是分兩次發(fā)送的。因?yàn)樵贐端接收到A端的FIN后,B端可能還有數(shù)據(jù)要傳輸,所以先發(fā)送ACK,等B端處理完自己的事情后就可以發(fā)送FIN斷開(kāi)連接了。

為什么在第四次揮手后會(huì)有2個(gè)MSL的延時(shí)?

前文說(shuō)到

MSL是Maximum Segment Lifetime,***報(bào)文段生存時(shí)間,2個(gè)MSL是報(bào)文段發(fā)送和接收的最長(zhǎng)時(shí)間。

假定網(wǎng)絡(luò)不可靠,那么第四次發(fā)送的ACK可能丟失,即B端無(wú)法收到這個(gè)ACK,如果B端收不到這個(gè)確認(rèn)ACK,B端會(huì)定時(shí)向A端重復(fù)發(fā)送FIN,直到B端收到A的確認(rèn)ACK。所以這個(gè)2MSL就是用來(lái)處理這個(gè)可能丟失的ACK的。

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

2023-10-24 15:22:09

TCPUDP

2021-01-29 06:11:08

TCP通信三次握手

2021-05-18 12:27:40

TCP控制協(xié)議

2024-01-12 08:23:11

TCPACK服務(wù)器

2019-06-12 11:26:37

TCP三次握手四次揮手

2017-09-25 21:27:07

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

2019-02-01 09:38:16

2021-07-03 17:47:25

TCP控制協(xié)議

2020-02-17 10:10:43

TCP三次握手四次揮手

2023-10-28 09:07:57

TCP面試三次握手

2021-05-28 09:08:20

TCP連接序列號(hào)

2020-06-29 14:50:47

TCP狀態(tài)ACK

2014-09-19 09:46:46

TCPIP

2023-11-01 08:04:08

WiresharkTCP協(xié)議

2015-11-09 09:58:56

2022-11-17 10:20:49

TCP三次握手四次揮手

2023-10-17 15:44:19

TCP四次揮手

2023-03-07 08:38:23

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

2019-12-13 07:31:04

TCP三次握手四次揮手

2018-08-10 09:23:19

TCP考點(diǎn)數(shù)據(jù)
點(diǎn)贊
收藏

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