HTTP協議學習總結

2021-07-22 06:57:10 字數 4376 閱讀 4442

http 協議是網際網路的基礎協議,它是基於 tcp/ip 協議(傳輸層協議)的應用層協議,不涉及資料報傳輸,主要規定了客戶端和伺服器之間的通訊格式,預設使用80埠,是一種請求/響應式的協議,客戶端與伺服器建立連線後,傳送乙個請求給伺服器,伺服器接到請求後,給予相應的響應資訊。

###缺點###

http/1.0 版的主要缺點是:每個tcp連線只能傳送乙個請求。傳送資料完畢,連線就關閉,如果還要請求其他資源,就必須再新建乙個連線。

tcp連線的新建成本很高,因為需要客戶端和伺服器三次握手,並且開始時傳送速率較慢。所以,http 1.0版本的效能比較差。隨著網頁載入的外部資源越來越多,這個問題就愈發突出了。

為了解決這個問題,有些瀏覽器在請求時,用了乙個非標準的connection欄位。

connection: keep-alive
這個字段要求伺服器不要關閉tcp連線,以便其他請求復用。伺服器同樣回應這個字段。

connection: keep-alive
乙個可以復用的tcp連線就建立了,直到客戶端或伺服器主動關閉連線。但是,這不是標準字段,不同實現的行為可能不一致,因此不是根本的解決辦法。

###請求訊息結構###

由請求行、請求頭欄位、乙個空行和訊息主體構成。

####請求行####

請求訊息的第一行就是請求行。它指明使用的請求方法、資源標示符、和 http 版本。如:

get /demo.htm http/1.1
####請求方法####

請求方法用來定義操作資源的方式,http/1.1 協議中定義了八種請求方法:

狀態行

由http版本、狀態碼、狀態描述文字構成。如:

http/1.1 200 ok
####狀態碼###

http 狀態碼是用以表示網頁伺服器 http 響應狀態的3位數字**。 所有的狀態碼的第乙個數字代表了響應的五種狀態之一:

常見狀態碼有:

###響應頭欄位###

connection: close
目前,對於同乙個網域名稱,大多數瀏覽器允許同時建立6個持久連線。

###管道機制###

http1.1 版還引入了管道機制,即在同乙個tcp連線裡面,客戶端可以同時傳送多個請求。這樣就進一步改進了http協議的效率。

舉例來說:客戶端需要請求兩個資源。以前的做法是,在同乙個tcp連線裡面,先傳送a請求,然後等待伺服器做出回應,收到後再發出b請求。**管道機制則是:**允許瀏覽器同時發出a請求和b請求,但是伺服器還是按照順序,先回應a請求,完成後再回應b請求。

###content-length 字段###

乙個tcp連線現在可以傳送多個回應,勢必就要有一種機制,區分資料報是屬於哪乙個回應的。這就是content-length欄位的作用,宣告本次回應的資料長度。

content-length: 3495
上面**告訴瀏覽器,本次回應的長度是3495個位元組,後面的位元組就屬於下乙個回應了。

在1.0版中,content-length欄位不是必需的,因為瀏覽器發現伺服器關閉了tcp連線,就表明收到的資料報已經全了。

###分塊傳輸編碼###

使用content-length欄位的前提條件是,伺服器傳送回應之前,必須知道回應的資料長度。

對於一些很耗時的動態操作來說,這意味著,伺服器要等到所有操作完成,才能傳送資料,顯然這樣的效率不高。更好的處理方法是,產生一塊資料,就傳送一塊,採用"流模式"(stream)取代"快取模式"(buffer)。

因此,1.1版規定可以不使用content-length欄位,而使用"分塊傳輸編碼"。只要請求或回應的頭資訊有transfer-encoding欄位,就表明回應將由數量未定的資料塊組成。

transfer-encoding: chunked
###其他功能###

1.1版還新增了許多動詞方法:put、patch、head、 options、delete。

另外,客戶端請求的頭資訊新增了host欄位,用來指定伺服器的網域名稱。

host: www.example.com
有了host欄位,就可以將請求發往同一臺伺服器上的不同**,為虛擬主機的興起打下了基礎。

###缺點###

雖然1.1版允許復用tcp連線,但是同乙個tcp連線裡面,所有的資料通訊是按次序進行的。伺服器只有處理完乙個回應,才會進行下乙個回應。要是前面的回應特別慢,後面就會有許多請求排隊等著。這稱為"隊頭堵塞"。

為了避免這個問題,只有兩種方法:一是減少請求數,二是同時多開持久連線。這導致了很多的網頁優化技巧,比如合併指令碼和樣式表、將嵌入css**、網域名稱分片等等。如果http協議設計得更好一些,這些額外的工作是可以避免的。

2023年,谷歌公開了自行研發的 spdy 協議,主要解決 http/1.1 效率不高的問題。

這個協議在chrome瀏覽器上證明可行以後,就被當作 http/2 的基礎,主要特性都在 http/2 之中得到繼承。

###二進位制協議###

http/1.1 版的頭資訊肯定是文字(ascii編碼),資料體可以是文字,也可以是二進位制。http/2 則是乙個徹底的二進位制協議,頭資訊和資料體都是二進位制,並且統稱為"幀"(frame):頭資訊幀和資料幀。

二進位制協議的乙個好處是,可以定義額外的幀。http/2 定義了近十種幀,為將來的高階應用打好了基礎。如果使用文字實現這種功能,解析資料將會變得非常麻煩,二進位制解析則方便得多。

###多工###

http/2 復用tcp連線,在乙個連線裡,客戶端和瀏覽器都可以同時傳送多個請求或回應,而且不用按照順序一一對應,這樣就避免了"隊頭堵塞"。

舉例來說,在乙個tcp連線裡面,伺服器同時收到了a請求和b請求,於是先回應a請求,結果發現處理過程非常耗時,於是就傳送a請求已經處理好的部分, 接著回應b請求,完成後,再傳送a請求剩下的部分。

這樣雙向的、實時的通訊,就叫做多工(multiplexing)。

###資料流###

因為 http/2 的資料報是不按順序傳送的,同乙個連線裡面連續的資料報,可能屬於不同的回應。因此,必須要對資料報做標記,指出它屬於哪個回應。

http/2 將每個請求或回應的所有資料報,稱為乙個資料流。每個資料流都有乙個獨一無二的編號。資料報傳送的時候,都必須標記資料流id,用來區分它屬於哪個資料流。另外還規定,客戶端發出的資料流,id一律為奇數,伺服器發出的,id為偶數。

資料流傳送到一半的時候,客戶端和伺服器都可以傳送訊號(rst_stream幀),取消這個資料流。1.1版取消資料流的唯一方法,就是關閉tcp連線。這就是說,http/2 可以取消某一次請求,同時保證tcp連線還開啟著,可以被其他請求使用。

客戶端還可以指定資料流的優先順序。優先順序越高,伺服器就會越早回應。

###頭資訊壓縮###

http 協議不帶有狀態,每次請求都必須附上所有資訊。所以,請求的很多欄位都是重複的,比如cookie和user agent,一模一樣的內容,每次請求都必須附帶,這會浪費很多頻寬,也影響速度

http/2 對這一點做了優化,引入了頭資訊壓縮機制(header compression)。一方面,頭資訊使用gzip或compress壓縮後再傳送;另一方面,客戶端和伺服器同時維護一張頭資訊表,所有欄位都會存入這個表,生成乙個索引號,以後就不傳送同樣欄位了,只傳送索引號,這樣就提高速度了。

###伺服器推送###

http/2 允許伺服器未經請求,主動向客戶端傳送資源,這叫做伺服器推送(server push)。

常見場景是客戶端請求乙個網頁,這個網頁裡面包含很多靜態資源。正常情況下,客戶端必須收到網頁後,解析html原始碼,發現有靜態資源,再發出靜態資源請求。其實,伺服器可以預期到客戶端請求網頁後,很可能會再請求靜態資源,所以就主動把這些靜態資源隨著網頁一起發給客戶端了。

http 協議入門

https 公升級指南

http,http2.0,spdy,https你應該知道的一些事

http 協議簡介

超文字傳輸協議(http)介紹

HTTP協議學習總結

http 協議是網際網路的基礎協議,它是基於 tcp ip 協議 傳輸層協議 的應用層協議,不涉及資料報傳輸,主要規定了客戶端和伺服器之間的通訊格式,預設使用80埠,是一種請求 響應式的協議,客戶端與伺服器建立連線後,傳送乙個請求給伺服器,伺服器接到請求後,給予相應的響應資訊。http 1.0 版的...

HTTP協議總結

http協議是一種物件導向的協議,其簡單,快捷,方便,實用與分布式資訊網路管理系統 http協議的特點有 1.支援 c s和b s 支援客戶 伺服器模式 2.簡單快捷 向服務端請求時只需傳遞請求的方式 post,get,head,delete等 3.靈活 在傳遞時只需要在content type中定...

HTTP協議總結

http是應用層協議,由http客戶端發起乙個請求,建立乙個到伺服器指定埠的tcp連線。http 伺服器則在埠監聽客戶端的請求,一旦受到請求就會向客戶端返回乙個狀態 200,500等 以及返回內容。注 http是乙個無狀態的協議,通過伺服器認證後成功請求了乙個資源後再次請求這一資源時,伺服器仍舊會要...