圖解 HTTP 筆記（三）—— HTTP 報文內的 HTTP 信息

本章主要講解請求和響應是如何運做的

1、HTTP 報文

用於 HTTP 協議交互的信息被稱爲 HTTP 報文，客戶端的 HTTP 報文叫作請求報文，服務器端的叫作響應報文。

HTTP 報文大體可分爲報文首部和報文主體兩塊，二者經過空行劃分（CR + LF），一般並不必定要有報文主體

CR：Carriage Return，回車符，16 進制的 0x0d

LF：Line Feed，換行符，16 進制的 0x0a

下圖展現了請求報文和響應報文的結構：

其中：

• 請求行 包含用於請求的方法，請求 URL 和 HTTP 版本。
• 狀態行 包含代表響應結果的狀態碼，緣由短語和 HTTP 版本。
• 首部字段 包含表示請求和響應的各類條件和屬性的各種首部。通常包括通用首部、請求首部、響應首部和實體首部。
• 其餘 包含一些未在 RFC 中定義的首部（Cookie 等）。

2、經過編碼提高傳輸速率

HTTP 在傳輸時能夠按照原始數據直接傳輸，也能夠預先將數據進行壓縮後再傳輸。編碼壓縮後能夠減小傳輸的數據量，可以提高傳輸速率，可是會壓縮過程會消耗更多的 CPU 資源。

2.1 報文主體和實體主體的差別

• 報文（message） 是 HTTP 通訊過程當中的基本單位，由八位組字節流組成，經過 HTTP 傳輸。
• 實體（entity） 做爲請求或者響應的有效載荷數據被傳輸，其內容由實體首部和實體主體構成。

HTTP 報文的主體用於傳輸實體的主體（請求或者響應的）。

一般狀況下，報文主體就是實體主體。可是在進行編碼壓縮時，實體主體部分會被編碼，致使與報文主體不一樣。

2.2 壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮，壓縮以後的內容在客戶端被接受以後會進行解碼還原。

經常使用的內容編碼有一下幾種：

• gzip（GNU zip）
• compress（UNIX 系統的標準壓縮）
• deflate（zlib）
• identity（不進行編碼）

如今還有一種新興的優秀算法——Brotli，可是目前尚未被普遍採用。

2.3 分塊傳輸編碼

在傳送大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。這種功能成爲分塊傳輸編碼（Chunked Transfer Coding）。

分塊傳輸會將實體主體分割成多個塊（chunk）來傳輸，每一塊都用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0（CR+LF）」來標記。

3、發送多種數據的多部分對象集合

郵件附件可以同時傳送多種內容的數據，是由於採用了 MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）機制，它容許郵件處理文本、圖片、視頻等多種類型的數據。相應的，HTTP 也採納了部分多部分對象集合。

多部分對象集合包含的對象以下：

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

咱們經過指定 Content-Type 請求頭來使用多部分對象結合。

4、獲取部份內容的範圍請求

指定範圍發送的請求叫作範圍請求（Range Request）。

對於一份 10000 字節大小的資源，能夠經過範圍請求一次只請求 5001 ～ 10000 字節的資源。

執行範圍請求時，會經過 Range 首部字段來指定資源的 byte 範圍，好比：

• 5000 - 10000 字節：

  Range: bytes=5001-10000
  複製代碼

• 5000 字節以後的全部內容：

  Range: bytes=5000-
  複製代碼

• 從一開始到 3000 字節和 5000 字節到 7000 字節的內容：

  Range: bytes=0-3000,5000-7000
  複製代碼

針對範圍請求，響應會返回狀態碼爲 206 Partial Content 的響應報文。

對於多重範圍的範圍請求，響應會在首部字段 Content-Type 代表 multipart/byteranges 後返回。

5、內容協商返回最合適的內容

內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲合適的資源。

內容協商會以語言、字符集、編碼方式等爲基準判斷響應的資源。

包含在請求報文中的一些首部字段就是服務端響應的判斷標準：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language