三次握手四次揮手

2022-09-04 03:36:10 字數 1669 閱讀 8058

描述一下三次握手的過程,回答不出基本上就game over了。

isn代表什麼?意義何在?

isn,傳送方的位元組資料編號的原點,讓對方生成乙個合法的接收視窗。

isn是固定不變的嗎?

動態隨機。

isn為何要動態隨機?

增加安全性,為了避免被第三方猜測到,從而被第三方偽造的rst報文reset。

還有嗎?

isn動態隨機使得每個tcp session的位元組序列號沒有重疊,如果出現tcp五元組衝突這種極小概率情況的發生,乙個session的資料也不會被誤認為是另乙個session的。

剛才你提到第三方可以偽造rst報文,需要滿足什麼條件才能得逞?

需要sequence number 位於對方的合法接收視窗內。 而由於isn是動態隨機的,猜出對方合法接收視窗難度加大。

如果isn = 0,那麼猜出的難度就大大降低。

三次握手的第一次可以攜帶資料嗎?為何?

不可以,三次握手還沒有完成。

對方難道不可以將資料快取下來,等握手成功再提交給應用程式?

這樣會放大syn flood攻擊。

如果攻擊者偽造了成千上萬的握手報文,攜帶了1k+ 位元組的資料,而接收方會開闢大量的快取來容納這些巨大資料,記憶體會很容易耗盡,從而拒絕服務。

第三次可以攜帶資料嗎?為何?

可以。能夠發出第三次握手報文的主機,肯定接收到第二次(伺服器)握手報文,對嗎?

因為偽造ip的主機是不會接收到第二次報文的。

所以,能夠發出第三次握手報文的,應該是合法的使用者。

儘管伺服器側的狀態還沒有「established」,接收到第三次握手的瞬間,狀態就會切換為「established」,裡面攜帶的資料按照正常流程走就好。

看到有人說,只看到過tcp狀態位為』fin +ack』,但從來沒有看過狀態位只有『fin』,你應該怎樣給他解釋?

rfc793明確規定,除了第乙個握手報文syn除外,其它所有報文必須將ack = 1。

很好,rfc規定的背後肯定有合理性的一面,能否深究一下原因?

tcp作為乙個可靠傳輸協議,其可靠性就是依賴於收到對方的資料,ack對方,這樣對方就可以釋放快取的資料,因為對方確信資料已經被接收到了。

但tcp報文是在ip網路上傳輸,丟包是家常便飯,接收方要抓住一切的機會,把訊息告訴傳送方。最方便的方式就是,任何我方傳送的tcp報文,都要捎帶著ack狀態位。

ack狀態位單獨能承擔這個訊息傳遞的任務嗎?

不能!需要有 acknowledge number配合才行。

如果我方發出的acknowledge number == 10001,那意味著序列號10000及之前的位元組已經成功接收。

如果對方佔據位元組序列號10000是應用層資料,那麼就是確認應用層資料。

如果對方佔據位元組序列號10000是』fin』狀態位,那麼就是確認接收到對方的』fin』。

這是一道aws面試題!

三次握手 四次揮手

1.tcp連線的建立 1 首先是伺服器初始化的過程,從 closed 關閉 狀態開始通過順序呼叫 socket bind listen 和accept 原語建立 socket 套接字,進入 listen 監聽 狀態,等待客戶端的 tcp傳輸連線請求。2 客戶端最開始也是從 closed 狀態開始呼叫...

三次握手,四次揮手

三次握手 three times handshake three way handshake 所謂的 三次握手 即對每次傳送的 資料量是怎樣跟蹤進行協商使 資料段的傳送和接收同步,根據所接收到的資料量而確定的資料確認數及資料傳送 接收完畢後何時撤消聯絡,並建立虛連線。為了提供可靠的傳送,tcp在傳送...

三次握手 四次揮手

在tcp ip 協議中,tcp 協議提供可靠的連線服務,採用三次握手建立乙個連線,如圖1所示。1 第一次握手 建立連線時,客戶端a 傳送syn 包 syn j 到伺服器b 並進入syn send 狀態,等待伺服器b 確認。2 第二次握手 伺服器b 收到syn 包,必須確認客戶a 的syn ack j...