Http 協議的三次握手,四次揮手

2021-10-10 04:08:25 字數 1381 閱讀 5468

關於http協議,了解也不多。原來就知道其請求方式有get/post 這兩種,其餘的都不太了解。但是最近,正好被問到關於http協議中的三次握手,四次揮手。自己下來了解學習了。下面分享,其中有不足。也希望大家提出:

問什麼要三次握手,四次揮手:

其實http協議本質上就是為了讓客戶端和服務端能夠建立安全可靠的鏈結,從而來實現資料的安全傳輸。而要建立安全的鏈結,就要保證客戶端傳送的建立鏈結的請求在與伺服器請求的返回上面好保證是一致的(客戶端發出的多條請求)。而四次揮手就是在伺服器在想客戶端對應的請求返回資料的時候。要保證客戶端接收到全部的伺服器裡面的資料之後,才能夠關閉鏈結。

三次握手:

三次握手,就想有兩個人a(小弟),b(大佬)。當兩個人相遇的時候。小弟看到大佬是不是要去主動打招呼,所以客戶端就是小弟a,而伺服器就是大佬b。而小弟的主動打招呼就是第一次握手;小弟向大佬打了招呼,大佬是不是要回應小弟,而大佬的回應就是第二次握手;而大佬回應了,小弟是不是也要給到老乙個反應,不可能什麼都不做,就扭頭就離開。所以小弟對大佬的反饋,就是第三次握手。在這三次握手中,客戶端和伺服器,還是有相關的狀態的變化,如圖:

正如圖中所示:客戶端先會發生器請求:這是第一次握手,帶有序列號(syn)到服務端,此時客戶端的狀態為syn-send狀態

而服務端在之前一直是listen狀態,在被動等待接收客戶端的請求資訊。當其收到

客戶端發起建立連線的請求之後。服務端就會向客戶端返回一定帶有序列號(syn)

,確認碼(ack)的訊息。而服務端的狀態變為syn-recv 。客戶端在收到服務的返回

資訊之後。狀態變為established ,然後向服務發生乙個帶有確認碼(ack)的資訊,

伺服器收到客戶端帶有確認碼(ack)的資訊之後,狀態也變為established。

四次揮手

上面已經提到過,為了保證服務端的資料完整的傳送到客戶端。所以,才會有四次揮手的情況。在客戶端,服務端之間的連線建立好之後。客戶端會主動向服務端傳送一段帶有結束碼(fin)的詢問資訊(大致就像問服務端,你資料傳送完了嗎,我要關閉連線了)給服務端這是第一次揮手;服務端就會回應客戶端乙個資訊(我還沒有傳完了,不能關閉連線),帶有確認碼(ack)這是第二次揮手;當伺服器傳完資料之後,就會向客戶端傳送乙個帶有結束碼(fin)的訊息(我資料傳輸完了,可以關閉連線),這是第三次揮手;客戶端收到服務端的訊息之後,會返回服務乙個帶有確認碼(ack)的訊息(好的,我知道了,那就關閉連線),這是第四次揮手。這之後,整個連線就關閉了。

http協議 三次握手 四次揮手

1.第一次握手 客戶端向伺服器傳送建立 客戶端向伺服器通道的請求 2.第二次握手 伺服器同意建立連線 並傳送 建立伺服器向客戶端建立連線的請求 3.第三次握手 客戶端同意建立連線 1.第一握手 客戶端在傳送資料完成之後,向伺服器傳送斷開客戶端向的連線請求 2.第二次握手 伺服器同意客戶端斷開連線請求...

http三次握手 HTTP三次握手,四次揮手。

三次握手 首先解析伺服器dns,找到ip,然後開始建立連線 1.第一次握手 建立連線,客戶端a傳送syn 1 隨機產生seq client isn的資料報到伺服器b,等待伺服器確認。2.第二次握手 伺服器b收到請求後確認聯機 可以接受資料 發起第二次握手請求,ack a的seq 1 syn 1,隨機...

http三次握手,四次揮手

本文經過借鑑書籍資料 他人部落格總結出的知識點,歡迎提問 序列號seq 佔4個位元組,用來標記資料段的順序,tcp把連線中傳送的所有資料位元組都編上乙個序號,第乙個位元組的編號由本地隨機產生 給位元組編上序號後,就給每乙個報文段指派乙個序號 序列號seq就是這個報文段中的第乙個位元組的資料編號。確認...