成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

面試官,請別再問我3次握手與4次揮手了!

網(wǎng)絡 通信技術
在面試中,三次握手和四次揮手可以說是問的最頻繁的一個知識點了,我相信大家也都看過很多關于三次握手與四次揮手的文章。

在面試中,三次握手和四次揮手可以說是問的最頻繁的一個知識點了,我相信大家也都看過很多關于三次握手與四次揮手的文章。

[[270179]]

圖片來自包圖網(wǎng)

今天的這篇文章,重點是圍繞著面試,我們應該掌握哪些比較重要的點,哪些是比較多被面試官給問到的,我覺得如果你能把我下面列舉的一些點都記住、理解,我想就差不多了。

三次握手

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

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

  • 第一次握手:客戶端給服務器發(fā)送一個 SYN 報文。
  • 第二次握手:服務器收到 SYN 報文之后,會應答一個 SYN+ACK 報文。
  • 第三次握手:客戶端收到 SYN+ACK 報文之后,會回應一個 ACK 報文。
  • 服務器收到 ACK 報文之后,三次握手建立完成。

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

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

  • 第一次握手:客戶端發(fā)送網(wǎng)絡包,服務端收到了。

這樣服務端就能得出結論:客戶端的發(fā)送能力、服務端的接收能力是正常的。

  • 第二次握手:服務端發(fā)包,客戶端收到了。

這樣客戶端就能得出結論:服務端的接收、發(fā)送能力,客戶端的接收、發(fā)送能力是正常的。不過此時服務器并不能確認客戶端的接收能力是否正常。

  • 第三次握手:客戶端發(fā)包,服務端收到了。

這樣服務端就能得出結論:客戶端的接收、發(fā)送能力正常,服務器自己的發(fā)送、接收能力也正常。

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

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

所以我覺得在回答三次握手的時候,我們應該要描述的詳細一點,而且描述的詳細一點意味著可以扯久一點。

加分的描述我覺得應該是這樣:剛開始客戶端處于 Closed 的狀態(tài),服務端處于 Listen 狀態(tài)。

然后:

  • 第一次握手:客戶端給服務端發(fā)一個 SYN 報文,并指明客戶端的初始化序列號 ISN(c)。此時客戶端處于 SYN_Send 狀態(tài)。
  • 第二次握手:服務器收到客戶端的 SYN 報文之后,會以自己的 SYN 報文作為應答,并且也是指定了自己的初始化序列號 ISN(s)。

同時會把客戶端的 ISN + 1 作為 ACK 的值,表示自己已經(jīng)收到了客戶端的 SYN,此時服務器處于 SYN_REVD 的狀態(tài)。

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

三次握手的作用

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

  • 確認雙方的接受能力、發(fā)送能力是否正常。
  • 指定自己的初始化序列號,為后面的可靠傳送做準備。
  • 如果是 HTTPS 協(xié)議的話,三次握手這個過程,還會進行數(shù)字證書的驗證以及加密密鑰的生成。

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

①(ISN)是固定的嗎

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

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

②什么是半連接隊列

服務器第一次收到客戶端的 SYN 之后,就會處于 SYN_RCVD 狀態(tài),此時雙方還沒有完全建立其連接,服務器會把此種狀態(tài)下請求連接放在一個隊列里,我們把這種隊列稱之為半連接隊列。

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

這里在補充一點關于SYN-ACK 重傳次數(shù)的問題:

  • 服務器發(fā)送完SYN-ACK包,如果未收到客戶確認包,服務器進行首次重傳,等待一段時間仍未收到客戶確認包,進行第二次重傳。
  • 如果重傳次數(shù)超過系統(tǒng)規(guī)定的最大重傳次數(shù),系統(tǒng)將該連接信息從半連接隊列中刪除。

注意,每次重傳等待的時間不一定相同,一般會是指數(shù)增長,例如間隔時間為 1s,2s,4s,8s......

③三次握手過程中可以攜帶數(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ù)頁沒啥毛病。

關于三次握手的,HTTPS 的認證過程能知道一下更好,不過我就不說了,留著寫 HTTP 面試相關時的文章再說。

四次揮手

四次揮手也一樣,千萬不要對方一個 FIN 報文,我方一個 ACK 報文,再我方一個 FIN 報文,對方一個 ACK 報文。

然后結束,要說的詳細一點,例如像下面這樣就差不多了,要把每個階段的狀態(tài)記好,我上次面試就被問了幾個了,呵呵。我答錯了,還以為自己答對了,當時還解釋的頭頭是道,呵呵。

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

  • 第一次揮手:客戶端發(fā)送一個 FIN 報文,報文中會指定一個序列號。此時客戶端處于 FIN_WAIT1 狀態(tài)。
  • 第二次握手:服務端收到 FIN 之后,會發(fā)送 ACK 報文,且把客戶端的序列號值 +1 作為 ACK 報文的序列號值,表明已經(jīng)收到客戶端的報文了,此時服務端處于 CLOSE_WAIT 狀態(tài)。
  • 第三次揮手:如果服務端也想斷開連接了,和客戶端的第一次揮手一樣,發(fā)給 FIN 報文,且指定一個序列號。此時服務端處于 LAST_ACK 的狀態(tài)。
  • 第四次揮手:客戶端收到 FIN 之后,一樣發(fā)送一個 ACK 報文作為應答,且把服務端的序列號值 +1 作為自己 ACK 報文的序列號值,此時客戶端處于 TIME_WAIT 狀態(tài)。

需要過一陣子以確保服務端收到自己的 ACK 報文之后才會進入 CLOSED 狀態(tài)

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

這里特別需要注意的就是 TIME_WAIT 這個狀態(tài)了,這個是面試的高頻考點,就是要理解,為什么客戶端發(fā)送 ACK 之后不直接關閉,而是要等一陣子才關閉。

這其中的原因就是,要確保服務器是否已經(jīng)收到了我們的 ACK 報文,如果沒有收到的話,服務器會重新發(fā) FIN 報文給客戶端,客戶端再次收到 ACK 報文之后,就知道之前的 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)
相關推薦

2020-04-16 08:22:11

HTTPS加解密協(xié)議

2019-05-28 10:45:07

TCP3次握手數(shù)據(jù)傳輸

2018-09-28 05:25:53

TopK算法代碼

2019-04-11 10:10:01

2018-11-01 13:49:23

桶排序排序面試

2018-10-28 22:37:00

計數(shù)排序排序面試

2024-04-07 00:02:00

TCP連接通道

2025-02-13 00:00:00

TCP網(wǎng)絡通信

2022-08-28 20:35:52

三次握手四次揮手TCP

2020-12-11 09:24:19

Elasticsear存儲數(shù)據(jù)

2020-09-24 14:40:55

Python 開發(fā)編程語言

2024-05-07 08:15:33

TCP四次揮手三次握手

2020-04-22 11:19:07

貪心算法動態(tài)規(guī)劃

2024-01-12 08:23:11

TCPACK服務器

2021-01-22 10:09:23

簡歷求職者面試

2018-11-06 11:40:19

時間復雜度面試算法

2015-02-13 10:42:31

前端工具Dreamweaver

2022-11-23 07:41:52

JDKStream關鍵字

2021-11-24 10:10:32

axios前端攔截器

2023-10-28 09:07:57

TCP面試三次握手
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 日韩有码在线播放 | 日韩成人在线免费观看 | 久久久久久久久久久一区二区 | 91九色视频在线 | 国产精品1区2区 | 国产精品一区二区三区在线 | 欧美一区二区三区久久精品视 | 中文字幕国产一区 | 国产精品毛片无码 | 日韩美女一区二区三区在线观看 | 国产乱码精品1区2区3区 | 欧美日韩高清一区 | 亚洲九九| 亚洲国产一区在线 | 成人av一区二区三区 | 国产视频一区二区 | 国产中文一区二区三区 | 一区精品国产欧美在线 | 免费午夜电影 | 黑人巨大精品欧美黑白配亚洲 | 精品欧美在线观看 | 日韩在线观看一区二区三区 | 91超碰在线观看 | 成人免费一区二区三区视频网站 | www亚洲精品 | 北条麻妃一区二区三区在线视频 | www.亚洲一区| 亚洲情侣视频 | 国产欧美一区二区三区免费 | 国产高清区 | 亚洲精品美女 | 久久91精品国产一区二区三区 | 欧美一区二区三区精品免费 | 日韩精品视频一区二区三区 | 黄色大片免费网站 | 成人性生交a做片 | 久久久久久精 | 国产一级一级毛片 | 日韩精品在线看 | 中文字幕高清视频 | 国产精品久久久久久久久久久久久 |