HTTP協議圖--HTTP 報文實體

1. HTTP 報文實體概述

 

HTTP 報文結構

大家請仔細看看上面示例中,各個組成部分對應的內容。
接着,我們來看看報文和實體的概念。如果把 HTTP 報文想象成因特網貨運系統中的箱子,那麼 HTTP 實體就是報文中實際的貨物。

  • 報文:是網絡中交換和傳輸的數據單元,即站點一次性要發送的數據塊。報文包含了將要發送的完整的數據信息,其長短很不一致,長度不限且可變。
  • 實體:作爲請求或響應的有效載荷數據(補充項)被傳輸,其內容由實體首部和實體主體組成。(實體首部相關內容在上面第六點中已有闡述。)

我們可以看到,上面示例右圖中深紅色框的內容就是報文的實體部分,而藍色框的兩部分內容分別就是實體首部和實體主體。而左圖中粉紅框內容就是報文主體。
通常,報文主體等於實體主體。只有當傳輸中進行編碼操作時,實體主體的內容發生變化,才導致它和報文主體產生差異。

2. 內容編碼

  • HTTP 應用程序有時在發送之前需要對內容進行編碼。例如,在把很大的 HTML 文檔發送給通過慢速連接上來的客戶端之前,服務器可能會對其進行壓縮,這樣有助於減少傳輸實體的時間。服務器還可以把內容攪亂或加密,以此來防止未授權的第三方看到文檔的內容。
  • 這種類型的編碼是在發送方應用到內容之上的。當內容經過內容編碼後,編好碼的數據就放在實體主體中,像往常一樣發送給接收方。

內容編碼類型:

編碼方式 描述
gzip 表明實體採用 GNU zip 編碼
compress 表明實體採用 Unix 的文件壓縮程序
deflate 表明實體採用 zlib 的格式壓縮的
identity 表明沒有對實體進行編碼,當沒有 Content-Encoding 首部字段時,默認採用此編碼方式

3. 傳輸編碼

內容編碼是對報文的主體進行的可逆變換,是和內容的具體格式細節緊密相關的。
傳輸編碼也是作用在實體主體上的可逆變換,但使用它們是由於架構方面的原因,同內容的格式無關。使用傳輸編碼是爲了改變報文中的數據在網絡上傳輸的方式。

 

 

內容編碼和傳輸編碼的對比

4. 分塊編碼

分塊編碼把報文分割成若干已知大小的塊。塊之間是緊挨着發送的,這樣就不需要在發送之前知道整個報文的大小了。分塊編碼是一種傳輸編碼,是報文的屬性。

分塊編碼與持久連接
若客戶端與服務器端之間不是持久連接,客戶端就不需要知道它在讀取的主體的長度,而只需要讀取到服務器關閉主體連接爲止。
當使用持久連接時,在服務器寫主體之前,必須知道它的大小並在 Content-Length 首部中發送。如果服務器動態創建內容,就可能在發送之前無法知道主體的長度。
分塊編碼爲這種困難提供瞭解決方案,只要允許服務器把主體分塊發送,說明每塊的大小就可以了。因爲主體是動態創建的,服務器可以緩衝它的一部分,發送其大小和相應的塊,然後在主體發送完之前重複這個過程。服務器可以用大小爲 0 的塊作爲主體結束的信號,這樣就可以繼續保持連接,爲下一個響應做準備。
來看看一個分塊編碼的報文示例:

 

分塊編碼的報文

 

5.多部分媒體類型

MIME 中的 multipart(多部分)電子郵件報文中包含多個報文,它們合在一起作爲單一的複雜報文發送。每一部分都是獨立的,有各自的描述其內容的集,不同部分之間用分界字符串連接在一起。
相應得,HTTP 協議中也採納了多部分對象集合,發送的一份報文主體內可包含多種類型實體。
多部分對象集合包含的對象如下:

  • multipart/form-data:在 Web 表單文件上傳時使用。
  • multipart/byteranges:狀態碼 206 Partial Content 響應報文包含了多個範圍的內容時使用。

6. 範圍請求

假設你正在下載一個很大的文件,已經下了四分之三,忽然網絡中斷了,那下載就必須重頭再來一遍。爲了解決這個問題,需要一種可恢復的機制,即能從之前下載中斷處恢復下載。要實現該功能,這就要用到範圍請求。
有了範圍請求, HTTP 客戶端可以通過請求曾獲取失敗的實體的一個範圍(或者說一部分),來恢復下載該實體。當然這有一個前提,那就是從客戶端上一次請求該實體到這一次發出範圍請求的時間段內,該對象沒有改變過。例如:

GET  /bigfile.html  HTTP/1.1
Host: www.sample.com
Range: bytes=20224-
···

 

                                    實體範圍請求示例

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章