三次握手,四次揮手

2021-10-10 22:40:40 字數 2187 閱讀 8895

為了能夠使瀏覽器和伺服器通訊,瀏覽器和伺服器之間通過三次握手,來建立tcp連線。通過四次揮手,來結束tcp連線。

過程

客戶端主動向服務端發起請求(準備開始進行第一次握手)

客戶端向伺服器發起tcp連線請求報文,請求報文中將同步位syn置為1,隨機生成乙個序列號seq(第一次握手)

伺服器收到請求後發回乙個確認報文,確認報文中同步位syn和確認位ack置為1,隨機生成乙個序列號seq和返回確認編號ack(第二次握手)

客戶端收到伺服器的確認報文後,返回給伺服器乙個確認報文,將確認位ack置為1,seq為第一次握手隨機生成的x+1ack為伺服器確認報文的序列號+1y+1(第三次握手)

雙方開始通訊

大白話

客戶端想要傳送資料,告訴伺服器他想要建立tcp連線(第一次握手),伺服器收到請求後,和客戶端說你可以傳送資料(第二次握手),客戶端得到伺服器的確認後和伺服器說那我要開始傳送資料了(第三次握手),然後雙方愉快的開始通訊

為什麼需要三次握手

第一種說法

確保伺服器和客戶端都知道對方的序列號還讓他們雙方都互相知道對方知道,第一次握手是伺服器知道客戶端的序列號,第二次握手是客戶端知道伺服器的序列號並且讓客戶端知道,伺服器知道客戶端的序列號;第三次握手是讓伺服器知道,客戶端知道伺服器的序列號。(雙方套娃)

第二種說法

防止已失效的連線請求報文突然又傳送到伺服器端(謝希仁計算機網路)

如果客戶端第一次傳送請求連線報文,這個報文因為某種情況發生了滯留,客戶端又重新傳送請求連線報文到伺服器端,雙方建立連線,傳輸完資料後斷開了連線。如果這時,滯留的第一次連線請求報文到達了服務端,伺服器會誤認為客戶端又重新發起連線請求,返回確認報文,可是客戶端不知道自己傳送了連線請求,就不會理睬客戶端的確認,造成伺服器端白白等著,造成資源浪費。

雙方其實都可以釋放tcp連線,以客戶端為例

過程

客戶端向伺服器端傳送釋放報文段,並停止傳送資料。在報文段首部,將終止控制位fin置為1,隨機生成序列號seq為u(第一次揮手)

伺服器端收到客戶端的釋放報文段後立即發出確認,確認號ack為u+1,隨機生成序列號seq為v,確認字段ack為1(第二次揮手)

當伺服器端不需要傳送資料時,向客戶端傳送釋放報文段,將終止控制位fin置為1,隨機生成序列號seq為w(第三次揮手)

客戶端收到請求後立即返回確認,並等待2msl時間後才進入close狀態(第四次揮手)

大白話

客戶端傳送完資料後就發生乙個釋放報文段告訴伺服器端我資料發完了,我們可以斷開連線了;伺服器端收到請求後會立刻告訴客戶端,我收到請求了,但是你要等我處理完資料;服務端處理完資料之後,傳送釋放報文段給客戶端,我資料處理完畢了,我們斷開連線吧。客戶端收到服務端的釋放報文段後給伺服器乙個確認報文,等待2msl後進入close狀態;伺服器收到客戶端的確認報文後立即進入close狀態

為什麼要等待2msl

確保客戶端的最後一次報文能夠到達伺服器

報文段可能在傳送的過程中丟失,伺服器端沒收到客戶端的確認報文,會超時重傳結束連線報文段,如果客戶端傳送完確認報文段就進入close,那麼服務端就一直拿不到客戶端的確認報文,白白等待浪費資源

保證在本次連線過程中的所有報文段從網路中消失,不會影響到下一次連線

tips:

msl是最長報文段壽命

三次握手 四次揮手

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...