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

關(guān)于三次握手與四次揮手面試官想考我們什么?

網(wǎng)絡 通信技術(shù)
在面試中,三次握手和四次揮手可以說是問的最頻繁的一個知識點了,我相信大家也都看過很多關(guān)于三次握手與四次揮手的文章,今天的這篇文章,重點是圍繞著面試,我們應該掌握哪些比較重要的點,哪些是比較被面試官給問到的,我覺得如果你能把我下面列舉的一些點都記住、理解,我想就差不多了。

 在面試中,三次握手和四次揮手可以說是問的最頻繁的一個知識點了,我相信大家也都看過很多關(guān)于三次握手與四次揮手的文章,今天的這篇文章,重點是圍繞著面試,我們應該掌握哪些比較重要的點,哪些是比較被面試官給問到的,我覺得如果你能把我下面列舉的一些點都記住、理解,我想就差不多了。

[[262077]]

三次握手

當面試官問你為什么需要有三次握手、三次握手的作用、講講三次三次握手的時候,我想很多人會這樣回答:

首先很多人會先講下握手的過程:

1、第一次握手:客戶端給服務器發(fā)送一個 SYN 報文。

2、第二次握手:服務器收到 SYN 報文之后,會應答一個 SYN+ACK 報文。

3、第三次握手:客戶端收到 SYN+ACK 報文之后,會回應一個 ACK 報文。

4、服務器收到 ACK 報文之后,三次握手建立完成。

作用是為了確認雙方的接收與發(fā)送能力是否正常。

這里我順便解釋一下為啥只有三次握手才能確認雙方的接受與發(fā)送能力是否正常,而兩次卻不可以:

第一次握手:客戶端發(fā)送網(wǎng)絡包,服務端收到了。這樣服務端就能得出結(jié)論:客戶端的發(fā)送能力、服務端的接收能力是正常的。

第二次握手:服務端發(fā)包,客戶端收到了。這樣客戶端就能得出結(jié)論:服務端的接收、發(fā)送能力,客戶端的接收、發(fā)送能力是正常的。不過此時服務器并不能確認客戶端的接收能力是否正常。

第三次握手:客戶端發(fā)包,服務端收到了。這樣服務端就能得出結(jié)論:客戶端的接收、發(fā)送能力正常,服務器自己的發(fā)送、接收能力也正常。

因此,需要三次握手才能確認雙方的接收與發(fā)送能力是否正常。

這樣回答其實也是可以的,但我覺得,這個過程的我們應該要描述的更詳細一點,因為三次握手的過程中,雙方是由很多狀態(tài)的改變的,而這些狀態(tài),也是面試官可能會問的點。所以我覺得在回答三次握手的時候,我們應該要描述的詳細一點,而且描述的詳細一點意味著可以扯久一點。加分的描述我覺得應該是這樣:

剛開始客戶端處于 closed 的狀態(tài),服務端處于 listen 狀態(tài)。然后

1、第一次握手:客戶端給服務端發(fā)一個 SYN 報文,并指明客戶端的初始化序列號ISN(c)。此時客戶端處于 SYN_Send 狀態(tài)。

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

3、第三次握手:客戶端收到 SYN 報文之后,會發(fā)送一個 ACK 報文,當然,也是一樣把服務器的 ISN + 1 作為 ACK 的值,表示已經(jīng)收到了服務端的 SYN 報文,此時客戶端處于 establised 狀態(tài)。

4、服務器收到 ACK 報文之后,也處于 establised 狀態(tài),此時,雙方以建立起了鏈接。

 

三次握手的作用

三次握手的作用也是有好多的,多記住幾個,保證不虧。例如:

1、確認雙方的接受能力、發(fā)送能力是否正常。

2、指定自己的初始化序列號,為后面的可靠傳送做準備。

3、如果是 https 協(xié)議的話,三次握手這個過程,還會進行數(shù)字證書的驗證以及加密密鑰的生成到。

單單這樣還不足以應付三次握手,面試官可能還會問一些其他的問題,例如:

1、(ISN)是固定的嗎

三次握手的一個重要功能是客戶端和服務端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收數(shù)據(jù)的時候如何按序列號組裝數(shù)據(jù)。

如果ISN是固定的,攻擊者很容易猜出后續(xù)的確認號,因此 ISN 是動態(tài)生成的。

2、什么是半連接隊列

服務器第一次收到客戶端的 SYN 之后,就會處于 SYN_RCVD 狀態(tài),此時雙方還沒有完全建立其連接,服務器會把此種狀態(tài)下請求連接放在一個隊列里,我們把這種隊列稱之為半連接隊列。當然還有一個全連接隊列,就是已經(jīng)完成三次握手,建立起連接的就會放在全連接隊列中。如果隊列滿了就有可能會出現(xiàn)丟包現(xiàn)象。

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

3、三次握手過程中可以攜帶數(shù)據(jù)嗎

很多人可能會認為三次握手都不能攜帶數(shù)據(jù),其實第三次握手的時候,是可以攜帶數(shù)據(jù)的。也就是說,第一次、第二次握手不可以攜帶數(shù)據(jù),而第三次握手是可以攜帶數(shù)據(jù)的。

為什么這樣呢?大家可以想一個問題,假如第一次握手可以攜帶數(shù)據(jù)的話,如果有人要惡意攻擊服務器,那他每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù),因為攻擊者根本就不理服務器的接收、發(fā)送能力是否正常,然后瘋狂著重復發(fā) SYN 報文的話,這會讓服務器花費很多時間、內(nèi)存空間來接收這些報文。也就是說,第一次握手可以放數(shù)據(jù)的話,其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。

而對于第三次的話,此時客戶端已經(jīng)處于 established 狀態(tài),也就是說,對于客戶端來說,他已經(jīng)建立起連接了,并且也已經(jīng)知道服務器的接收、發(fā)送能力是正常的了,所以能攜帶數(shù)據(jù)頁沒啥毛病。

關(guān)于三次握手的,https 的認證過程能知道一下,不過我就不說了,留著寫 http 面試相關(guān)時的文章再說。

四次揮手

四次揮手也一樣,千萬不要對方一個 FIN 報文,我方一個 ACK 報文,再我方一個 FIN 報文,我方一個 ACK 報文。然后結(jié)束,說的詳細一點,例如想下面這樣就差不多了,要把每個階段的狀態(tài)記好,我上次面試就被問了幾個了,呵呵。我答錯了,還以為自己答對了,當時還解釋的頭頭是道,呵呵。

剛開始雙方都處于 establised 狀態(tài),假如是客戶端先發(fā)起關(guān)閉請求,則:

1、第一次揮手:客戶端發(fā)送一個 FIN 報文,報文中會指定一個序列號。此時客戶端處于CLOSED_WAIT1狀態(tài)。

2、第二次握手:服務端收到 FIN 之后,會發(fā)送 ACK 報文,且把客戶端的序列號值 + 1 作為 ACK 報文的序列號值,表明已經(jīng)收到客戶端的報文了,此時服務端處于CLOSE_WAIT2狀態(tài)。

3、第三次揮手:如果服務端也想斷開連接了,和客戶端的第一次揮手一樣,發(fā)給 FIN 報文,且指定一個序列號。此時服務端處于 LAST_ACK 的狀態(tài)。

4、第四次揮手:客戶端收到 FIN 之后,一樣發(fā)送一個 ACK 報文作為應答,且把服務端的序列號值 + 1 作為自己 ACK 報文的序列號值,此時客戶端處于 TIME_WAIT 狀態(tài)。需要過一陣子以確保服務端收到自己的 ACK 報文之后才會進入 CLOSED 狀態(tài)

5、服務端收到 ACK 報文之后,就處于關(guān)閉連接了,處于 CLOSED 狀態(tài)。

 

這里特別需要主要的就是TIME_WAIT這個狀態(tài)了,這個是面試的高頻考點,就是要理解,為什么客戶端發(fā)送 ACK 之后不直接關(guān)閉,而是要等一陣子才關(guān)閉。這其中的原因就是,要確保服務器是否已經(jīng)收到了我們的 ACK 報文,如果沒有收到的話,服務器會重新發(fā) FIN 報文給客戶端,客戶端再次收到 FIN 報文之后,就知道之前的 ACK 報文丟失了,然后再次發(fā)送 ACK 報文。

至于 TIME_WAIT 持續(xù)的時間至少是一個報文的來回時間。一般會設置一個計時,如果過了這個計時沒有再次收到 FIN 報文,則代表對方成功就是 ACK 報文,此時處于 CLOSED 狀態(tài)。

這里我給出每個狀態(tài)所包含的含義,有興趣的可以看看。

LISTEN - 偵聽來自遠方TCP端口的連接請求;

SYN-SENT -在發(fā)送連接請求后等待匹配的連接請求;

SYN-RECEIVED - 在收到和發(fā)送一個連接請求后等待對連接請求的確認;

ESTABLISHED- 代表一個打開的連接,數(shù)據(jù)可以傳送給用戶;

FIN-WAIT-1 - 等待遠程TCP的連接中斷請求,或先前的連接中斷請求的確認;

FIN-WAIT-2 - 從遠程TCP等待連接中斷請求;

CLOSE-WAIT - 等待從本地用戶發(fā)來的連接中斷請求;

CLOSING -等待遠程TCP對連接中斷的確認;

LAST-ACK - 等待原來發(fā)向遠程TCP的連接中斷請求的確認;

TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認;

CLOSED - 沒有任何連接狀態(tài);

最后,在放在三次握手與四次揮手的圖

 

責任編輯:武曉燕 來源: 苦逼的碼農(nóng)
相關(guān)推薦

2025-02-13 00:00:00

TCP網(wǎng)絡通信

2024-01-12 08:23:11

TCPACK服務器

2022-08-28 20:35:52

三次握手四次揮手TCP

2015-10-13 09:42:52

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

2019-06-12 11:26:37

TCP三次握手四次揮手

2020-02-17 10:10:43

TCP三次握手四次揮手

2024-05-07 08:15:33

TCP四次揮手三次握手

2019-01-25 09:21:30

2023-10-28 09:07:57

TCP面試三次握手

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

2023-10-24 15:22:09

TCPUDP

2021-05-28 09:08:20

TCP連接序列號

2015-11-09 09:58:56

2020-01-09 09:31:05

三次握手四次揮手 TCP

2021-02-18 07:43:25

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

2017-09-25 21:27:07

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

2023-03-07 08:38:23

三次握手四次揮手服務端
點贊
收藏

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