概念：
用於 HTTP 協議交互的信息被稱爲 HTTP 報文。請求端（客戶端）的 HTTP 報文叫做請求報文，響應端（服
務器端）的叫做響應報文。HTTP 報文本身是由多行（用 CR+LF 作換行符）數據構成的字符串文本。
HTTP 報文大致可分爲報文首部和報文主體兩塊。兩者由最初出現的空行（CR+LF）來劃分。通常，並不一
定要有報文主體。
首部字段：包含表示請求和響應的各種條件和屬性的各類首部。
報文主體：作爲請求或響應傳輸的有效載荷數據(內容)。
1.請求報文及響應報文的結構:
2.請求報文（上）和響應報文（下）的實例
3.編碼提升傳輸速率
（1）HTTP 在傳輸數據時可以按照數據原貌直接傳輸，但也可以在傳輸過程中通過編碼提升傳輸速率。通過在傳
輸時編碼，能有效地處理大量的訪問請求。但是，編碼的操作需要計算機來完成，因此會消耗更多的 CPU 等
資源。常用的內容編碼有以下幾種。
①gzip（GNU zip）
②compress（UNIX 系統的標準壓縮）
③deflate（zlib）
④identity（不進行編碼）
（2）分割發送的分塊傳輸編碼
在 HTTP 通信過程中，請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器無法顯示請求頁面。在傳輸大容 量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。 這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。
4.內容協商返回最合適的內容
同一個 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）
是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。