關於HTTP協議的簡和通訊過程

2021-10-09 14:55:33 字數 3571 閱讀 2710

1. http協議

首先http協議是乙個簡單的請求-響應協議, 也叫作超文字傳輸協議, 在早期專門用於傳輸超文字資料html, 但是隨著協議發展多元化, 開始不限制傳輸格式. 在tcp/ip協議棧當中, 它是執行在應用層上的協議. 它指定了客戶端可能傳送給伺服器什麼樣的訊息以及得到什麼樣的相應.

注意:這裡我們要注意的是應用層是直面我們程式設計師的一層, 因為應用程式使我們程式設計師自己寫的, 因此應用層的通訊協議可以有我們自己來制定, 而http就是一種知名的應用層通訊協議.

2. 關於http的發展歷程(http的協議版本)

http的發展目前經歷了四個版本階段:

-0.9版本:處於這個階段的http協議只是乙個簡單的交換資訊的無序協議, 並且資料的傳輸僅僅是文字, 這個時候還沒有形成固定完整的協議格式, 請求方法只有get

-1.0版本:1.0版本當中正式規定了http協議的協議格式, 並且增加了多種請求方法, 支援不同檔案格式的資料流.

-1.1版本:在1.0版本的基礎上增加了更多的請求方法以及頭資訊, 這個時候更加注重傳輸效能以及效率的提公升. 並且這個時候開始支援長連線以及管線化傳輸.

-2.0版本:2.0版本開始採用二進位製流傳輸, 並且進行多路復用, 並且允許服務端主動向客戶端推送資料.

3. http協議格式

http報文由從客戶端到服務端的請求 和 從服務端到客戶端的相應組成;

請求報文的格式如下:

首行:首行也叫作請求行, 會包含本次請求的請求方法, url, 協議版本資訊等

頭部:描述本次請求的關鍵字段資訊, 由key:val形式的鍵值對組成, 並且每個鍵值對以\r\n作為結尾 ----- key:val\r\nkey:val\r\n

其中一些請求的關鍵字段資訊一般有:

connection-控制長連線/短連線

cache-control-快取控制

user-agent-客戶端的屬性

accept-描述自己所能接收資料的屬性

content-length-描述正文長度

content-type-描述正文的資料型別

空行:空行主要是為了間隔頭部與正文

接收http資料的時候, 當連續接收兩個\r\n的時候, 認為頭部到此結束(即\r\n\r\n)

正文:正文則是提交給服務端的資料

響應報文的格式如下:

首行:也叫作狀態行, 能夠表示請求處理結果的狀態, 首行包含三個要素, 以空格進行間隔, 包含協議版本, 響應狀態碼, 狀態描述, 以\r\n作為結束.

例如: http/1.1 303 see other

頭部:關於本次響應的一些關鍵字段描述資訊, 以key:val鍵值對組成, 以\r\n作為結尾

其中一些相應的關鍵字段資訊一般有:

transfer-encoding: 實體正文的傳輸方式

expires: 快取過期的時間

location: 重定向的新位置

set-cookie: 服務端通過set-cookie向客戶端傳遞資訊, 會被儲存在客戶端瀏覽器的cookie檔案當中

cookie: 客戶端每次通訊從cookie檔案當中讀取資料, 通過cookie向服務端傳遞資訊

cookie的使用並不安全, 因此需要搭配session使用

session: 會話, 服務端會為每個登陸的客戶端建立乙個會話, 在服務端描述一些會話資訊(客戶端身份資訊, 狀態資訊), 將其儲存在服務端, 可以通過cookie將session id返回給客戶端, 客戶端每次通訊都會通過cookie帶有自己的session id.

cookie和session的區別

** cookie持續傳遞客戶端資訊狀態的字段, cookie是儲存在客戶端上的資料, 用於持續與服務端進行資訊傳遞的一種手段**

session是一種會話的控制, 服務端儲存的會話資訊包含客戶端的身份狀態資訊

空行:空行主要是為了間隔頭部與正文

接收http資料的時候, 當連續接收兩個\r\n的時候, 認為頭部到此結束(即\r\n\r\n)

正文:服務端響應的實體資源

4. http的通訊過程

由於http協議是在傳輸層基於tcp通訊實現, 因此http也是基於c/s模式的(客戶端/服務端模式), 並且是面向連線的.

典型的http通訊過程

-搭建tcp客戶端以及服務端程式, 並且建立連線

-客戶端組織http協議格式請求資料/資源, 向伺服器發出請求

等待伺服器的響應

-伺服器收到客戶端的請求, 按照規定的http協議格式對請求進行解析, 並根據請求組織響應資訊以及對應的實體資源

-服務端業務處理結束之後, 按照http協議格式組織資訊和資料對客戶端進行響應

5. 關於http協議當中的connection頭部字段

在http通訊當中, 長短連線的控制是通過通用頭部欄位connection欄位完成的.

connection: keep-alive

connection: close

connection一般用於控制網路連線是否保持開啟狀態, 當前事務結束之後, 如果傳送的值是keep-alive, 則說明連線是持久的並且不關閉, 從而允許客戶端對同一伺服器的後續請求完成

close 表示客戶端或伺服器想要關閉連線. 這是http/1.0請求的預設值

keep-alive 表示客戶端想要保持連線處於半開啟狀態. 持久連線是 http/1.1請求的預設值

短連線: http基於傳輸層tcp實現通訊, 每一次通訊都對應一次tcp連線的建立, 完成請求/響應的過程, 通訊完畢後斷開連線.

但是, 在http/1.0版本當中, 並沒有過多的考慮網際網路中最重要的速度和效率, 也正因為如此, 在http/1.1當中引入了管線化長連線的思想. 實現管線化長連線傳輸的目的是為了每一次建立連線, 能夠完成多個請求的通訊, 也就是說可以在建立連線之後一次性傳送多個請求, 伺服器在收到請求之後也可按照客戶端的請求順序依次進行響應, 通過這種方式減少連線建立以及斷開的次數, 這樣能夠大大避免tcp擁塞機制所造成的傳輸效率降低問題.

這就引出了長連線的思想.

長連線: 在一次通訊當中, 建立乙個連線, 可以連續傳送多次請求, 服務端按序進行響應進而減少連線建立以及斷開的次數.

知道了如上長短連線的思想, 接下來我們需要注意的是, 在http/1.1中的管線化長連線雖然在一定程度上提高了傳輸效率, 但是仍然存在著隊頭阻塞的問題, 因為服務端是按請求順序進行組織響應的(如果第一條請求處理比較慢, 會影響其他的響應無法及時到達客戶端, 必須要等待請求1的處理完成), 而這個問題在http/2.0中得到了解決.

HTTP協議通訊過程

http協議通訊過程 當我們在瀏覽器的位址列輸入 www.baidu.com 然後按回車,這之後發生了什麼事,我們直接看到的是開啟了對應的網頁,那麼內部客戶端和服務端是如何通訊的呢?1 1 url自動解析 http url包含了用於查詢某個資源的足夠資訊,基本格式如下 http host port ...

HTTP協議通訊過程

當我們在瀏覽器的位址列輸入 www.baidu.com 然後按回車,這之後發生了什麼事,我們直接看到的是開啟了對應的網頁,那麼內部客戶端和服務端是如何通訊的呢?1 1 url自動解析 http url包含了用於查詢某個資源的足夠資訊,基本格式如下 http host port abs path 其中...

HTTP協議通訊過程

當我們在瀏覽器的位址列輸入 www.baidu.com 然後按回車,這之後發生了什麼事,我們直接看到的是開啟了對應的網頁,那麼內部客戶端和服務端是如何通訊的呢?1 1 url自動解析 http url包含了用於查詢某個資源的足夠資訊,基本格式如下 http host port abs path 其中...