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

六張圖帶你搞懂 TCP 為什么是三次握手,而不是兩次或四次?

系統(tǒng) Linux
下面正經(jīng)地來回答下這個問題,要搞清楚這個問題,首先得了解TCP究竟是如何保證可靠傳輸?shù)摹?/div>

 1三次握手

2兩次握手(情況1)

3兩次握手(情況2)

OK,下面正經(jīng)地來回答下這個問題,要搞清楚這個問題,首先得了解TCP究竟是如何保證可靠傳輸?shù)摹?/p>

PS:TCP協(xié)議中,主動發(fā)起請求的一端稱為『客戶端』,被動連接的一端稱為『服務(wù)端』。不管是客戶端還是服務(wù)端,TCP連接建立完后都能發(fā)送和接收數(shù)據(jù)。

起初,服務(wù)器和客戶端都為CLOSED狀態(tài)。在通信開始前,雙方都得創(chuàng)建各自的傳輸控制塊(TCB)。服務(wù)器創(chuàng)建完TCB后遍進(jìn)入LISTEN狀態(tài),此時準(zhǔn)備接收客戶端發(fā)來的連接請求。

第一次握手

客戶端向服務(wù)端發(fā)送連接請求報文段。該報文段的頭部中SYN=1,ACK=0,seq=x。請求發(fā)送后,客戶端便進(jìn)入SYN-SENT狀態(tài)。

  •  PS1:SYN=1,ACK=0表示該報文段為連接請求報文。
  •  PS2:x為本次TCP通信的字節(jié)流的初始序號。TCP規(guī)定:SYN=1的報文段不能有數(shù)據(jù)部分,但要消耗掉一個序號。

第二次握手

服務(wù)端收到連接請求報文段后,如果同意連接,則會發(fā)送一個應(yīng)答:SYN=1,ACK=1,seq=y,ack=x+1。該應(yīng)答發(fā)送完成后便進(jìn)入SYN-RCVD狀態(tài)。

  •  PS1:SYN=1,ACK=1表示該報文段為連接同意的應(yīng)答報文。
  •  PS2:seq=y表示服務(wù)端作為發(fā)送者時,發(fā)送字節(jié)流的初始序號。
  •  PS3:ack=x+1表示服務(wù)端希望下一個數(shù)據(jù)報發(fā)送序號從x+1開始的字節(jié)。

第三次握手

當(dāng)客戶端收到連接同意的應(yīng)答后,還要向服務(wù)端發(fā)送一個確認(rèn)報文段,表示:服務(wù)端發(fā)來的連接同意應(yīng)答已經(jīng)成功收到。該報文段的頭部為:ACK=1,seq=x+1,ack=y+1??蛻舳税l(fā)完這個報文段后便進(jìn)入ESTABLISHED狀態(tài),服務(wù)端收到這個應(yīng)答后也進(jìn)入ESTABLISHED狀態(tài),此時連接的建立完成!

4 為什么連接建立需要三次握手,而不是兩次握手?

防止失效的連接請求報文段被服務(wù)端接收,從而產(chǎn)生錯誤。

PS:失效的連接請求:若客戶端向服務(wù)端發(fā)送的連接請求丟失,客戶端等待應(yīng)答超時后就會再次發(fā)送連接請求,此時,上一個連接請求就是『失效的』。

若建立連接只需兩次握手,客戶端并沒有太大的變化,仍然需要獲得服務(wù)端的應(yīng)答后才進(jìn)入ESTABLISHED狀態(tài),而服務(wù)端在收到連接請求后就進(jìn)入ESTABLISHED狀態(tài)。

此時如果網(wǎng)絡(luò)擁塞,客戶端發(fā)送的連接請求遲遲到不了服務(wù)端,客戶端便超時重發(fā)請求,如果服務(wù)端正確接收并確認(rèn)應(yīng)答,雙方便開始通信,通信結(jié)束后釋放連接。此時,如果那個失效的連接請求抵達(dá)了服務(wù)端,由于只有兩次握手,服務(wù)端收到請求就會進(jìn)入ESTABLISHED狀態(tài),等待發(fā)送數(shù)據(jù)或主動發(fā)送數(shù)據(jù)。但此時的客戶端早已進(jìn)入CLOSED狀態(tài),服務(wù)端將會一直等待下去,這樣浪費服務(wù)端連接資源。

5TCP四次揮手

TCP連接的釋放一共需要四步,因此稱為『四次揮手』。

我們知道,TCP連接是雙向的,因此在四次揮手中,前兩次揮手用于斷開一個方向的連接,后兩次揮手用于斷開另一方向的連接。

第一次揮手

若A認(rèn)為數(shù)據(jù)發(fā)送完成,則它需要向B發(fā)送連接釋放請求。該請求只有報文頭,頭中攜帶的主要參數(shù)為:FIN=1,seq=u。此時,A將進(jìn)入FIN-WAIT-1狀態(tài)。

  •  PS1:FIN=1表示該報文段是一個連接釋放請求。
  •  PS2:seq=u,u-1是A向B發(fā)送的最后一個字節(jié)的序號。

第二次揮手

B收到連接釋放請求后,會通知相應(yīng)的應(yīng)用程序,告訴它A向B這個方向的連接已經(jīng)釋放。此時B進(jìn)入CLOSE-WAIT狀態(tài),并向A發(fā)送連接釋放的應(yīng)答,其報文頭包含:ACK=1,seq=v,ack=u+1。

  •  PS1:ACK=1:除TCP連接請求報文段以外,TCP通信過程中所有數(shù)據(jù)報的ACK都為1,表示應(yīng)答。
  •  PS2:seq=v,v-1是B向A發(fā)送的最后一個字節(jié)的序號。
  •  PS3:ack=u+1表示希望收到從第u+1個字節(jié)開始的報文段,并且已經(jīng)成功接收了前u個字節(jié)。

A收到該應(yīng)答,進(jìn)入FIN-WAIT-2狀態(tài),等待B發(fā)送連接釋放請求。

第二次揮手完成后,A到B方向的連接已經(jīng)釋放,B不會再接收數(shù)據(jù),A也不會再發(fā)送數(shù)據(jù)。但B到A方向的連接仍然存在,B可以繼續(xù)向A發(fā)送數(shù)據(jù)。

第三次揮手

當(dāng)B向A發(fā)完所有數(shù)據(jù)后,向A發(fā)送連接釋放請求,請求頭:FIN=1,ACK=1,seq=w,ack=u+1。B便進(jìn)入LAST-ACK狀態(tài)。

第四次揮手

A收到釋放請求后,向B發(fā)送確認(rèn)應(yīng)答,此時A進(jìn)入TIME-WAIT狀態(tài)。該狀態(tài)會持續(xù)2MSL時間,若該時間段內(nèi)沒有B的重發(fā)請求的話,就進(jìn)入CLOSED狀態(tài),撤銷TCB。當(dāng)B收到確認(rèn)應(yīng)答后,也便進(jìn)入CLOSED狀態(tài),撤銷TCB。

6為什么 A 要先進(jìn)入TIME-WAIT狀態(tài),等待2MSL時間后才進(jìn)入CLOSED狀態(tài)

為了保證B能收到A的確認(rèn)應(yīng)答。若A發(fā)完確認(rèn)應(yīng)答后直接進(jìn)入CLOSED狀態(tài),那么如果該應(yīng)答丟失,B等待超時后就會重新發(fā)送連接釋放請求,但此時A已經(jīng)關(guān)閉了,不會作出任何響應(yīng),因此B永遠(yuǎn)無法正常關(guān)閉。 

 

責(zé)任編輯:龐桂玉 來源: 奇妙的Linux世界
相關(guān)推薦

2019-05-14 10:09:06

TCP連接握手

2021-04-30 13:32:17

TCP三次握手網(wǎng)絡(luò)協(xié)議

2024-10-16 08:38:37

TCP編號信息

2021-07-26 08:08:56

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

2021-05-28 09:08:20

TCP連接序列號

2023-10-24 15:22:09

TCPUDP

2024-01-12 08:23:11

TCPACK服務(wù)器

2015-10-13 09:42:52

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

2019-06-12 11:26:37

TCP三次握手四次揮手

2018-08-10 09:23:19

TCP考點數(shù)據(jù)

2021-01-29 06:11:08

TCP通信三次握手

2019-02-01 09:38:16

2021-05-18 12:27:40

TCP控制協(xié)議

2021-07-03 17:47:25

TCP控制協(xié)議

2014-09-19 09:46:46

TCPIP

2017-09-25 21:27:07

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

2020-02-17 10:10:43

TCP三次握手四次揮手

2023-09-07 16:46:54

TCP數(shù)據(jù)傳遞

2020-03-02 14:41:04

運維架構(gòu)技術(shù)

2015-11-09 09:58:56

點贊
收藏

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