摘要：狀態(tài)行包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語(yǔ)和版本。這種把實(shí)體主體分塊的功能稱為分塊傳輸編碼。如果服務(wù)器端無(wú)法響應(yīng)范圍請(qǐng)求，則會(huì)返回狀態(tài)碼和完整的實(shí)體內(nèi)容。

HTTP 通信過程包括從客戶端發(fā)往服務(wù)器端的請(qǐng)求及從服務(wù)器端返回 客戶端的響應(yīng)。

一. HTTP報(bào)文

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文。請(qǐng)求端（客戶端）的 HTTP 報(bào)文叫做請(qǐng)求報(bào)文，響應(yīng)端（服務(wù)器端）的叫做響應(yīng)報(bào)文。 HTTP 報(bào)文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本。

HTTP 報(bào)文大致可分為報(bào)文首部和報(bào)文主體兩塊。兩者由最初出現(xiàn)的空（CR+LF）來劃分。通常，并不一定要有報(bào)文主體。

HTTP報(bào)文結(jié)構(gòu)：

二. 請(qǐng)求報(bào)文及響應(yīng)報(bào)文的結(jié)構(gòu)

請(qǐng)求報(bào)文和響應(yīng)報(bào)文的結(jié)構(gòu)：

請(qǐng)求報(bào)文和響應(yīng)報(bào)文結(jié)構(gòu)舉例：

請(qǐng)求行：
包含用于請(qǐng)求的方法，請(qǐng)求 URI 和 HTTP 版本。
狀態(tài)行
包含表明響應(yīng)結(jié)果的狀態(tài)碼，原因短語(yǔ)和 HTTP 版本。
首部字段
包含表示請(qǐng)求和響應(yīng)的各種條件和屬性的各類首部。

一般有 4 種首部，分別是：通用首部、請(qǐng)求首部、響應(yīng)首部和實(shí)體首部。
其他可能包含 HTTP 的 RFC 里未定義的首部（Cookie 等）。

三. 編碼提升傳輸速率

HTTP 在傳輸數(shù)據(jù)時(shí)可以按照數(shù)據(jù)原貌直接傳輸，但也可以在傳輸過 程中通過編碼提升傳輸速率。通過在傳輸時(shí)編碼，能有效地處理大量 的訪問請(qǐng)求。但是，編碼的操作需要計(jì)算機(jī)來完成，因此會(huì)消耗更多 的 CPU 等資源。

1.報(bào)文主體和實(shí)體主體的差異：

報(bào)文（message）： 是 HTTP 通信中的基本單位，由 8 位組字節(jié)流（octet sequence， 其中 octet 為 8 個(gè)比特）組成，通過 HTTP 通信傳輸。
實(shí)體（entity）作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項(xiàng)）被傳輸，其內(nèi)容由實(shí)體首部和實(shí)體主體組成。

HTTP 報(bào)文的主體用于傳輸請(qǐng)求或響應(yīng)的實(shí)體主體。通常，報(bào)文主體等于實(shí)體主體。只有當(dāng)傳輸中進(jìn)行編碼操作時(shí)，實(shí)體主體的內(nèi)容發(fā)生變化，才導(dǎo)致它和報(bào)文主體產(chǎn)生差異。

2.壓縮傳輸?shù)膬?nèi)容編碼

向待發(fā)送郵件內(nèi)增加附件時(shí)，為了使郵件容量變小，我們會(huì)先用 ZIP 壓縮文件之后再添加附件發(fā)送。HTTP 協(xié)議中有一種被稱為內(nèi)容編碼的功能也能進(jìn)行類似的操作。內(nèi)容編碼指明應(yīng)用在實(shí)體內(nèi)容上的編碼格式，并保持實(shí)體信息原樣壓縮。內(nèi)容編碼后的實(shí)體由客戶端接收并負(fù)責(zé)解碼。

常用的內(nèi)容編碼有以下幾種。

gzip（GNU zip）
compress（UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮）
deflate（zlib）
identity（不進(jìn)行編碼）

3.分割發(fā)送的分塊傳輸編碼

在 HTTP 通信過程中，請(qǐng)求的編碼實(shí)體資源尚未全部傳輸完成之前， 瀏覽器無(wú)法顯示請(qǐng)求頁(yè)面。在傳輸大容量數(shù)據(jù)時(shí)，通過把數(shù)據(jù)分割成多塊，能夠讓瀏覽器逐步顯示頁(yè)面。這種把實(shí)體主體分塊的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

圖例：

分塊傳輸編碼會(huì)將實(shí)體主體分成多個(gè)部分（塊）。每一塊都會(huì)用十六進(jìn)制來標(biāo)記塊的大小，而實(shí)體主體的最后一塊會(huì)使用“0(CR+LF)”來標(biāo)記。

四.發(fā)送多種數(shù)據(jù)的多部分對(duì)象集合

發(fā)送郵件時(shí)，我們可以在郵件里寫入文字并添加多份附件。這是因?yàn)椴捎昧薓IME（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴(kuò)展）機(jī)制，它允許郵件處理文本、圖片、視頻等多個(gè)不同類型的數(shù)據(jù)。例如，圖片等二進(jìn)制數(shù)據(jù)以 ASCII 碼字符串編碼的方式指明， 就是利用 MIME 來描述標(biāo)記數(shù)據(jù)類型。而在 MIME 擴(kuò)展中會(huì)使用一種稱為多部分對(duì)象集合（Multipart）的方法，來容納多份不同類型的數(shù)據(jù)。

相應(yīng)地，HTTP 協(xié)議中也采納了多部分對(duì)象集合，發(fā)送的一份報(bào)文主體內(nèi)可含有多類型實(shí)體。通常是在圖片或文本文件等上傳時(shí)使用。

多部分對(duì)象集合包含的對(duì)象如下。

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

multipart/byteranges
狀態(tài)碼 206（Partial Content，部分內(nèi)容）響應(yīng)報(bào)文包含了多個(gè)范圍的內(nèi)容時(shí)使用。

在 HTTP 報(bào)文中使用多部分對(duì)象集合時(shí)，需要在首部字段里加上 Content-type。使用boundary 字符串來劃分多部分對(duì)象集合指明的各類實(shí)體。在 boundary 字符串指定的各個(gè)實(shí)體的起始行之前插入“--”標(biāo)記（例如：-AaB03x、--THIS_STRING_SEPARATES），而在多部分對(duì)象集合對(duì) 應(yīng)的字符串的最后插入“--”標(biāo)記（例如：--AaB03x--、-THIS_STRING_SEPARATES--）作為結(jié)束。
多部分對(duì)象集合的每個(gè)部分類型中，都可以含有首部字段。另外，可 以在某個(gè)部分中嵌套使用多部分對(duì)象集合。有關(guān)多部分對(duì)象集合更詳 細(xì)的解釋，請(qǐng)參考 RFC2046。

五.獲取部分內(nèi)容的范圍請(qǐng)求

要實(shí)現(xiàn)該功能需要指定下載的實(shí)體范圍。像這樣，指定范圍發(fā)送的請(qǐng)求叫做范圍請(qǐng)求（Range Request）。

圖示：

解釋：針對(duì)范圍請(qǐng)求，響應(yīng)會(huì)返回狀態(tài)碼為 206 Partial Content 的響應(yīng)報(bào)文。另外，對(duì)于多重范圍的范圍請(qǐng)求，響應(yīng)會(huì)在首部字段 ContentType 標(biāo)明 multipart/byteranges 后返回響應(yīng)報(bào)文。如果服務(wù)器端無(wú)法響應(yīng)范圍請(qǐng)求，則會(huì)返回狀態(tài)碼 200 OK 和完整的實(shí)體內(nèi)容。

六.內(nèi)容協(xié)商返回最合適的內(nèi)容

問題：同一個(gè) Web 網(wǎng)站有可能存在著多份相同內(nèi)容的頁(yè)面。比如英語(yǔ)版和中文版的 Web 頁(yè)面，它們內(nèi)容上雖相同，但使用的語(yǔ)言卻不同。

定義：當(dāng)瀏覽器的默認(rèn)語(yǔ)言為英語(yǔ)或中文，訪問相同 URI 的 Web 頁(yè)面時(shí)， 則會(huì)顯示對(duì)應(yīng)的英語(yǔ)版或中文版的 Web 頁(yè)面。這樣的機(jī)制稱為內(nèi)容協(xié)商（Content Negotiation）

圖示：

包含在請(qǐng)求報(bào)文中的某些首部字段（如下）就是判斷的基準(zhǔn)。

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

內(nèi)容協(xié)商技術(shù)有以下 3 種類型。

服務(wù)器驅(qū)動(dòng)協(xié)商（Server-driven Negotiation）
由服務(wù)器端進(jìn)行內(nèi)容協(xié)商。以請(qǐng)求的首部字段為參考，在服務(wù)器端自 動(dòng)處理。但對(duì)用戶來說，以瀏覽器發(fā)送的信息作為判定的依據(jù)，并不 一定能篩選出最優(yōu)內(nèi)容。
客戶端驅(qū)動(dòng)協(xié)商（Agent-driven Negotiation）
由客戶端進(jìn)行內(nèi)容協(xié)商的方式。用戶從瀏覽器顯示的可選項(xiàng)列表中手 動(dòng)選擇。還可以利用 JavaScript 腳本在 Web 頁(yè)面上自動(dòng)進(jìn)行上述選 擇。比如按 OS 的類型或?yàn)g覽器類型，自行切換成 PC 版頁(yè)面或手機(jī) 版頁(yè)面。
透明協(xié)商（Transparent Negotiation）
是服務(wù)器驅(qū)動(dòng)和客戶端驅(qū)動(dòng)的結(jié)合體，是由服務(wù)器端和客戶端各自進(jìn) 行內(nèi)容協(xié)商的一種方法。