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

一文徹底搞懂 TCP三次握手、四次揮手過程及原理

新聞 前端
TCP建立連接為什么是三次握手,而不是兩次或四次?順便說一句,原則上任何數(shù)據(jù)傳輸都無法確保絕對可靠,三次握手只是確??煽康幕拘枰?。

 [[316859]]

背景

和女朋友異地戀一年多,為了保持感情我提議每天晚上視頻聊天一次。

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

從好上開始,到現(xiàn)在,一年多也算堅持下來了。

問題

有時候聊天的過程中,我的網(wǎng)絡(luò)或者她的網(wǎng)絡(luò)可能會不好,視頻就會卡住,聽不到對方的聲音,過一會兒之后才會恢復。

中間雙方可能就要不斷的確認網(wǎng)絡(luò)是否恢復,但是有時候會:

她:“你可以聽到了嗎?”

我:“可以了,你呢?”、

她:“喂喂,你可以聽到了嗎?”

我:“可以了,我可以聽到了,你呢?”

她:“你可以聽到了嗎?”

.....

這種情況很蛋疼,那么怎樣才能找一個簡單的辦法,讓兩個人都確認自己可以聽到對方的聲音,對方也可以聽到自己的聲音呢?

注:以下情節(jié)純屬虛構(gòu) 

方案

TCP建立連接為什么是三次握手,而不是兩次或四次?

TCP,名為傳輸控制協(xié)議,是一種可靠的傳輸層協(xié)議,IP協(xié)議號為6。

順便說一句,原則上任何數(shù)據(jù)傳輸都無法確保絕對可靠,三次握手只是確??煽康幕拘枰?。

舉個日常例子,打電話時我們對話如下:

 ä¸€æ–‡å½»åº•搞懂 TCP三次握手、四次挥手过程及原理

對應(yīng)為客戶端與服務(wù)器之間的通信:

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

于是有了如下對話:

我:1+1等于幾?

她:2,2+2等于幾?

我:4

首先兩個人約定協(xié)議

1.感覺網(wǎng)絡(luò)情況不對的時候,任何一方都可以發(fā)起詢問

2.任何情況下,若發(fā)起詢問后5秒還沒收到回復,則認為網(wǎng)絡(luò)不通

3.網(wǎng)絡(luò)不通的情況下等1min路由器之后再發(fā)起詢問

對于我而言,發(fā)起 “1+1等于幾”的詢問后

1. 若5s內(nèi)沒有收到回復,則認為網(wǎng)絡(luò)不通

2. 若收到回復,則我確認①我能聽到她的消息 ②她能聽到我的消息,然后回復她的問題的答案

對于她而言,當感覺網(wǎng)絡(luò)情況不對的時候

1. 若沒有收到我的詢問,則她發(fā)起詢問

2. 若收到“1+1等于幾”,則她確認 ①她可以聽到我的消息,然后回復我的問題的答案和她的問題“2,2+2等于幾”

3. 若5s內(nèi)沒有收到我的回復“4”,則她確認 ②我聽不見她的消息

4. 若5s內(nèi)收到了我的回復“4”,則她確認 ②我可以聽見她的消息

這樣,如果上面的對話得以完成,就證明雙方都可以確認自己可以聽到對方的聲音,對方也可以聽到自己的聲音!

這個故事可以解釋TCP為什么要三次握手嗎 ... 囧

關(guān)于四次揮手

先由客戶端向服務(wù)器端發(fā)送一個FIN,請求關(guān)閉數(shù)據(jù)傳輸。

當服務(wù)器接收到客戶端的FIN時,向客戶端發(fā)送一個ACK,其中ack的值等于FIN+SEQ。

然后服務(wù)器向客戶端發(fā)送一個FIN,告訴客戶端應(yīng)用程序關(guān)閉。

當客戶端收到服務(wù)器端的FIN是,回復一個ACK給服務(wù)器端。其中ack的值等于FIN+SEQ。

 ä¸€æ–‡å½»åº•搞懂 TCP三次握手、四次挥手过程及原理

為什么要4次揮手?

確保數(shù)據(jù)能夠完整傳輸。

當被動方收到主動方的FIN報文通知時,它僅僅表示主動方?jīng)]有數(shù)據(jù)再發(fā)送給被動方了。

但未必被動方所有的數(shù)據(jù)都完整的發(fā)送給了主動方,所以被動方不會馬上關(guān)閉SOCKET,它可能還需要發(fā)送一些數(shù)據(jù)給主動方后,

再發(fā)送FIN報文給主動方,告訴主動方同意關(guān)閉連接,所以這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的。

一、TCP報文格式

TCP報文格式圖:

  ä¸€æ–‡å½»åº•搞懂 TCP三次握手、四次挥手过程及原理

上圖中有幾個字段需要重點介紹下:

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

  (2)確認序號:Ack序號,占32位,只有ACK標志位為1時,確認序號字段才有效,Ack=Seq+1。

  (3)標志位:共6個,即URG、ACK、PSH、RST、SYN、FIN等,具體含義如下:

  (A)URG:緊急指針(urgent pointer)有效。

  (B)ACK:確認序號有效。

  (C)PSH:接收方應(yīng)該盡快將這個報文交給應(yīng)用層。

  (D)RST:重置連接。

  (E)SYN:發(fā)起一個新連接。

  (F)FIN:釋放一個連接。

 需要注意的是:

  (A)不要將確認序號Ack與標志位中的ACK搞混了。

  (B)確認方Ack=發(fā)起方Req+1,兩端配對。 

二、三次握手

TCP(Transmission Control Protocol) 傳輸控制協(xié)議

TCP是主機對主機層的傳輸控制協(xié)議,提供可靠的連接服務(wù),采用三次握手確認建立一個連接

位碼即tcp標志位,有6種標示:

SYN(synchronous建立聯(lián)機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結(jié)束)

RST(reset重置)

URG(urgent緊急)

Sequence number(順序號碼)

Acknowledge number(確認號碼) 

establish  建立,創(chuàng)建 

所謂三次握手(Three-Way Handshake)即建立TCP連接,是指建立一個TCP連接時,需要客戶端和服務(wù)端總共發(fā)送3個包以確認連接的建立。在socket編程中,這一過程由客戶端執(zhí)行connect來觸發(fā),整個流程如下圖所示:

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

  (1)第一次握手:Client將標志位SYN置為1,隨機產(chǎn)生一個值seq=J,并將該數(shù)據(jù)包發(fā)送給Server,Client進入SYN_SENT狀態(tài),等待Server確認。

  (2)第二次握手:Server收到數(shù)據(jù)包后由標志位SYN=1知道Client請求建立連接,Server將標志位SYN和ACK都置為1,ack (number )=J+1,隨機產(chǎn)生一個值seq=K,并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求,Server進入SYN_RCVD狀態(tài)。

  (3)第三次握手:Client收到確認后,檢查ack是否為J+1,ACK是否為1,如果正確則將標志位ACK置為1,ack=K+1,并將該數(shù)據(jù)包發(fā)送給Server,Server檢查ack是否為K+1,ACK是否為1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態(tài),完成三次握手,隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

 ä¸€æ–‡å½»åº•搞懂 TCP三次握手、四次挥手过程及原理

SYN攻擊:

在三次握手過程中,Server發(fā)送SYN-ACK之后,收到Client的ACK之前的TCP連接稱為半連接(half-open connect),此時Server處于SYN_RCVD狀態(tài),當收到ACK后,Server轉(zhuǎn)入ESTABLISHED狀態(tài)。

SYN攻擊就是Client在短時間內(nèi)偽造大量不存在的IP地址,并向Server不斷地發(fā)送SYN包,Server回復確認包,并等待Client的確認,由于源地址是不存在的,因此,Server需要不斷重發(fā)直至超時,這些偽造的SYN包將長時間占用未連接隊列,導致正常的SYN請求因為隊列滿而被丟棄,從而引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓。

SYN攻擊時一種典型的DDOS攻擊,檢測SYN攻擊的方式非常簡單,即當Server上有大量半連接狀態(tài)且源IP地址是隨機的,則可以斷定遭到SYN攻擊了,使用如下命令可以讓之現(xiàn)行:

  1. #netstat -nap | grep SYN_RECV  

三、四次揮手

三次握手耳熟能詳,四次揮手估計就..所謂四次揮手(Four-Way Wavehand)即終止TCP連接,就是指斷開一個TCP連接時,需要客戶端和服務(wù)端總共發(fā)送4個包以確認連接的斷開。在socket編程中,這一過程由客戶端或服務(wù)端任一方執(zhí)行close來觸發(fā),整個流程如下圖所示:

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

由于TCP連接時全雙工的,因此,每個方向都必須要單獨進行關(guān)閉,這一原則是當一方完成數(shù)據(jù)發(fā)送任務(wù)后,發(fā)送一個FIN來終止這一方向的連接,收到一個FIN只是意味著這一方向上沒有數(shù)據(jù)流動了,即不會再收到數(shù)據(jù)了,但是在這個TCP連接上仍然能夠發(fā)送數(shù)據(jù),直到這一方向也發(fā)送了FIN。首先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉,而另一方則執(zhí)行被動關(guān)閉,上圖描述的即是如此。

(1)第一次揮手:Client發(fā)送一個FIN,用來關(guān)閉Client到Server的數(shù)據(jù)傳送,Client進入FIN_WAIT_1狀態(tài)。

(2)第二次揮手:Server收到FIN后,發(fā)送一個ACK給Client,確認序號為收到序號+1(與SYN相同,一個FIN占用一個序號),Server進入CLOSE_WAIT狀態(tài)。

(3)第三次揮手:Server發(fā)送一個FIN,用來關(guān)閉Server到Client的數(shù)據(jù)傳送,Server進入LAST_ACK狀態(tài)。

(4)第四次揮手:Client收到FIN后,Client進入TIME_WAIT狀態(tài),接著發(fā)送一個ACK給Server,確認序號為收到序號+1,Server進入CLOSED狀態(tài),完成四次揮手。

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

上面是一方主動關(guān)閉,另一方被動關(guān)閉的情況,實際中還會出現(xiàn)同時發(fā)起主動關(guān)閉的情況,具體流程如下圖:

一文彻底搞懂 TCP三次握手、四次挥手过程及原理

流程和狀態(tài)在上圖中已經(jīng)很明了了,在此不再贅述,可以參考前面的四次揮手解析步驟。

四、附注

關(guān)于三次握手與四次揮手通常都會有典型的面試題,在此提出供有需求的XDJM們參考:

  (1)三次握手是什么或者流程?四次握手呢?答案前面分析就是。

  (2)為什么建立連接是三次握手,而關(guān)閉連接卻是四次揮手呢?

這是因為服務(wù)端在LISTEN狀態(tài)下,收到建立連接請求的SYN報文后,把ACK和SYN放在一個報文里發(fā)送給客戶端。而關(guān)閉連接時,當收到對方的FIN報文時,僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù),己方也未必全部數(shù)據(jù)都發(fā)送給對方了,所以己方可以立即close,也可以發(fā)送一些數(shù)據(jù)給對方后,再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接,因此,己方ACK和FIN一般都會分開發(fā)送。 

 

責任編輯:張燕妮 來源: 高效運維
相關(guān)推薦

2020-01-09 09:31:05

三次握手四次揮手 TCP

2015-10-13 09:42:52

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

2019-06-12 11:26:37

TCP三次握手四次揮手

2017-09-25 21:27:07

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

2023-10-24 15:22:09

TCPUDP

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é)議

2020-02-17 10:10:43

TCP三次握手四次揮手

2021-08-04 08:01:28

Linux 三次握手Linux 系統(tǒng)

2021-05-28 09:08:20

TCP連接序列號

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三次握手四次揮手

2014-09-19 09:46:46

TCPIP

2023-10-17 15:44:19

TCP四次揮手

2023-11-01 08:04:08

WiresharkTCP協(xié)議
點贊
收藏

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