3.1HTTP報文
用於HTTP協議交互的信息稱爲HTTP報文。請求端（客戶端）的HTTP報文叫做請求報文，相應端（服務器端）的叫做響應報文。HTTP報文本身是由多行（用CR+LF作換行符）數據構成的字符串文本。
HTTP報文大致可分爲報文首部和報文主體兩塊。兩者由最初出現的空行（CR+LF）來劃分。通常，並不一定要有報文主體。
CR+LF：CR（Carriage Return，回車符：16進制0x0d）和LF（Line Feed，換行符：16進制0x0a）
3.2請求報文和響應報文的結構
報文首部
空行（CR+LF）
報文主體
請求報文的報文首部分爲：
請求行
請求首部字段
通用首部字段
實體首部字段
其他
響應報文的報文首部爲：
狀態行
響應首部字段
通用首部字段
實體首部字段
其他
請求行：包含請求方法，請求URI和HTTP版本
狀態行：包含表明響應結果的狀態碼，原因短語和HTTP版本
首部字段：包含表示請求和響應的各種條件和屬性的各類首部
一般有4中首部,分別是：通用首部，請求首部，響應首部和實體首部
其他：包含HTTP的RFC裏未定義的首部（Cookie等）
3.3編碼提升傳輸速率
HTTP在傳輸數據時可以按照數據原貌直接傳輸，但是也可以按照在傳輸過程中通過編碼提升傳輸速率。通過在傳輸時編碼，能有效地處理大量的訪問請求。但是，編碼的操作需要計算機來完成，因此會消耗更多的CPU等資源。
3.3.1報文主體和實體主體的差異
報文（message）
是HTTP通信中的基本單位，由8個組字節流（octet sequence，其中octet是8個比特）組成，通過HTTP通信傳輸。
實體（entity）
作爲請求或者響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。
HTTP報文的主體用於傳輸請求或響應的實體主體
通常報文主體等於實體主體。只有當傳輸中進行編碼操作時，實體主體的內容才發生變化，才導致他和報文主體產生差異
3.3.2壓縮傳輸內容的編碼
向待發送的郵件內增加附件時，爲了使郵件容量變小，我們會先使用ZIP壓縮文件之後在添加附件發送。HTTP協議中有一種被稱爲內容編碼的功能也能進行類似操作。
內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。
常用的內容編碼：
gzip(GNU zip)
compress (UNIX 系統的標準壓縮)
deflate(zlib)
identity(不進行編碼)
3.3.3分割發送的分塊傳輸編碼
在HTTP通信過程中，請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器無法顯示請求頁面。在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。
這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。
分塊傳輸編碼會將實體主體分成多個部分（塊）。每一塊都會用16進制來標記塊的大小，而實體主體的最後一塊會使用“0(CR+LF)”來標記
使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。
HTTP/1.1中存在一種稱爲傳輸編碼（Transfer Coding）的機制，他可以在通信時按照某種編碼方式傳輸，但是定義作用於分塊傳輸編碼中。
3.4 發送多種數據的多部分對象集合
發送郵件時，我們可以在郵件裏寫入文字並添加多份附件。這是因爲採用了MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）機制，它允許郵件處理文本、圖片、視頻等多個不同類型的數據。例如，圖片等二進制數據以ASCII碼字符串編碼的方式指明，就是利用MIME來描述標記數據類型。而在MIME擴展中會使用一種稱爲多部分對象集合（Multipart）的方法，來容納多份不同類型的數據。
相應的，HTTP協議中也採納了多部分對象集合，發送的一份報文主體內可含有多類型實體。通常是在圖片或文本文件等上傳時使用的。
多部分對象集合包含的對象如下：
multipart/form-data
在web表單文件上傳時使用。
multipart/byteranges
狀態碼206（Partial Content，部分內容）響應報文包含了多個範圍的內容時使用。
在HTTP報文中使用多部分對象集合時，需要子啊首部字段裏面加上Content-type。
使用boundary字符串來劃分多對象集合指明的各類實體，boundary字符串制定的各個實體的起始行之前插入“--”標記，而在多部分對象集合對應的字符串最後插入“--”標記。
3.5獲取部分內容的範圍請求
爲了解決下載中斷問題，需要一種恢復機制。所謂恢復是指能從之前下載中斷處恢復下載。
要實現該功能需要指定下載的實體範圍。像這樣，指定範圍發送的請求叫做範圍請求（Range Request）.
執行範圍請求時，會用到首部字段Range來指定資源的byte範圍。byte範圍指定形式如下：
5001~10000字節
Range ：bytes=5001-1000
從5001字節後的全部
Range：bytes=5001-
從一開始到3000字節和5000到7000字節的多重範圍
Range：bytes=-3000,5000-7000
針對範圍請求，響應會返回狀態碼爲206Partial Content的響應報文。
另外對於多重範圍的範圍請求，響應會在首部字段Content—Type標明multipart/byteranges後返回響應報文
如果服務器無法響應範圍請求，則會返回狀態碼爲200 OK和完整的實體內容。
3.6內容協商返回最合適的內容
同一個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頁面上自動進行上述選擇。
透明協商（Transparent Negotiation）
是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端格子進行內容協商的一種方法
