TCP/IP基礎總結性學習（3）

HTTP 報文內的 HTTP 信息

HTTP 通訊過程包括從客戶端發往服務器端的請求及從服務器端返回 客戶端的響應。

---

一. HTTP報文

• 用於 HTTP 協議交互的信息被稱爲 HTTP 報文。請求端（客戶端）的 HTTP 報文叫作請求報文，響應端（服務器端）的叫作響應報文。 HTTP 報文自己是由多行（用 CR+LF 做換行符）數據構成的字符串文本。
• HTTP 報文大體可分爲報文首部和報文主體兩塊。二者由最初出現的空（CR+LF）來劃分。一般，並不必定要有報文主體。
• HTTP報文結構：

---

二. 請求報文及響應報文的結構

• 請求報文和響應報文的結構：

• 請求報文和響應報文結構舉例：

請求行：
包含用於請求的方法，請求 URI 和 HTTP 版本。
狀態行
包含代表響應結果的狀態碼，緣由短語和 HTTP 版本。
首部字段
包含表示請求和響應的各類條件和屬性的各種首部。

通常有 4 種首部，分別是：通用首部、請求首部、響應首部和實體首部。
其餘可能包含 HTTP 的 RFC 裏未定義的首部（Cookie 等）。

---

三. 編碼提高傳輸速率

• HTTP 在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過 程中經過編碼提高傳輸速率。經過在傳輸時編碼，能有效地處理大量 的訪問請求。可是，編碼的操做須要計算機來完成，所以會消耗更多 的 CPU 等資源。

1.報文主體和實體主體的差別：

報文（message）： 是 HTTP 通訊中的基本單位，由 8 位組字節流（octet sequence， 其中 octet 爲 8 個比特）組成，經過 HTTP 通訊傳輸。
實體（entity）做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

• HTTP 報文的主體用於傳輸請求或響應的實體主體。一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別。

2.壓縮傳輸的內容編碼

• 向待發送郵件內增長附件時，爲了使郵件容量變小，咱們會先用 ZIP 壓縮文件以後再添加附件發送。HTTP 協議中有一種被稱爲內容編碼的功能也能進行相似的操做。內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。

• 經常使用的內容編碼有如下幾種。

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

3.分割發送的分塊傳輸編碼

• 在 HTTP 通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前， 瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。
• 圖例：

• 分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0(CR+LF)」來標記。

---

四.發送多種數據的多部分對象集合

• 發送郵件時，咱們能夠在郵件裏寫入文字並添加多份附件。這是由於採用了MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）機制，它容許郵件處理文本、圖片、視頻等多個不一樣類型的數據。例如，圖片等二進制數據以 ASCII 碼字符串編碼的方式指明， 就是利用 MIME 來描述標記數據類型。而在 MIME 擴展中會使用一種稱爲多部分對象集合（Multipart）的方法，來容納多份不一樣類型的數據。
• 相應地，HTTP 協議中也採納了多部分對象集合，發送的一份報文主體內可含有多類型實體。一般是在圖片或文本文件等上傳時使用。
• 多部分對象集合包含的對象以下。

multipart/form-data
在 Web 表單文件上傳時使用。

multipart/byteranges
狀態碼 206（Partial Content，部份內容）響應報文包含了多個範圍的內容時使用。

在 HTTP 報文中使用多部分對象集合時，須要在首部字段里加上 Content-type。使用boundary 字符串來劃分多部分對象集合指明的各種實體。在 boundary 字符串指定的各個實體的起始行以前插入「--」標記（例如：-AaB03x、--THIS_STRING_SEPARATES），而在多部分對象集合對 應的字符串的最後插入「--」標記（例如：--AaB03x--、-THIS_STRING_SEPARATES--）做爲結束。
多部分對象集合的每一個部分類型中，均可以含有首部字段。另外，可 以在某個部分中嵌套使用多部分對象集合。有關多部分對象集合更詳 細的解釋，請參考 RFC2046。

---

五.獲取部份內容的範圍請求

• 要實現該功能須要指定下載的實體範圍。像這樣，指定範圍發送的請求叫作範圍請求（Range Request）。
• 圖示：

• 解釋：針對範圍請求，響應會返回狀態碼爲 206 Partial Content 的響應報文。另外，對於多重範圍的範圍請求，響應會在首部字段 ContentType 標明 multipart/byteranges 後返回響應報文。若是服務器端沒法響應範圍請求，則會返回狀態碼 200 OK 和完整的實體內容。

---

六.內容協商返回最合適的內容

• 問題：同一個 Web 網站有可能存在着多份相同內容的頁面。好比英語版和中文版的 Web 頁面，它們內容上雖相同，但使用的語言卻不一樣。
• 定義：當瀏覽器的默認語言爲英語或中文，訪問相同 URI 的 Web 頁面時， 則會顯示對應的英語版或中文版的 Web 頁面。這樣的機制稱爲內容協商（Content Negotiation）
• 圖示：

• 包含在請求報文中的某些首部字段（以下）就是判斷的基準。

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

• 內容協商技術有如下 3 種類型。

服務器驅動協商（Server-driven Negotiation）由服務器端進行內容協商。以請求的首部字段爲參考，在服務器端自 動處理。但對用戶來講，以瀏覽器發送的信息做爲斷定的依據，並不 必定能篩選出最優內容。客戶端驅動協商（Agent-driven Negotiation）由客戶端進行內容協商的方式。用戶從瀏覽器顯示的可選項列表中手 動選擇。還能夠利用 JavaScript 腳本在 Web 頁面上自動進行上述選 擇。好比按 OS 的類型或瀏覽器類型，自行切換成 PC 版頁面或手機 版頁面。透明協商（Transparent Negotiation）是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進 行內容協商的一種方法。