HTTP 封包
HTTP封包本身是有多行資料構成的字元串文本。用CR+LF換行。
HTTP封包大緻分為封包首部和封包主體兩塊。兩者由最初出現的CR+LF劃分。封包主體可以沒有。
請求封包及響應封包的結構
請求行：包含請求的方法、請求URI 以及 HTTP 版本
狀态行：包含表明響應結果的狀态碼，原因短語和 HTTP 版本
首部字段：包含表示請求和響應的各種條件和屬性的各類首部
一般有4種首部，分别是：通用首部、請求首部、響應首部和實體首部。
可能包含HTTP的RFC裡未定義的首部(Cookie 等)
編碼提升傳輸效率
HTTP在傳輸資料時，可以原貌傳輸資料，也能在傳輸過程中通過編碼提升傳輸速率(更多消耗CPU資源)，有效地處理大量的通路請求。
-
封包主體和實體主體的差異*
封包（message）
HTTP通信中的基本機關，由8位組位元組流組成。通過HTTP通信傳輸。
實體（entity）
由實體首部和實體主體組成，作為請求或響應的有效載荷資料被傳輸。
HTTP封包的主體 用于傳輸請求或響應的實體主體。
通常，封包主體 等于 主體實體 。隻有當傳輸中進行編碼操作時，實體主體的内容發生變化，才導緻他和封包主體産生差異。
-
壓縮傳輸的内容編碼
内容編碼是HTTP協定中的壓縮功能，能指明實體内容的編碼格式，并保持實體資訊原樣壓縮。用戶端把内容解析還原。
常見内容編碼：
gzip（GNU zip）
compress（UNIX 系統的标準壓縮）
deflate（zlib）
identity（不進行編碼）
-
分割發送的分塊傳輸編碼
在HTTP通信過程中，傳輸大容量資料時，通常把資料分割成多塊，能夠讓浏覽器逐漸顯示頁面。每一個塊用十六進制标記大小，實體主體的最後一個塊，使用 “0(CR+LF)” 标記。
用戶端收到分塊後，會解碼，恢複編碼前的實體主體。
HTTP/1.1 存在一種機制，稱為 傳輸編碼(Transfer Coding)。隻定義作用于分塊傳輸編碼中，可以在通信時按照某種編碼方式傳輸。
發送多種資料的多部分對象集合
HTTP協定中，采用多對象集合（Multipart）的方法，來容納多份不同類型的資料。
-
multipart/form-date
在web表單檔案上傳時使用
第三章 HTTP封包内的HTTP資訊 -
multipart/byteranges
狀态碼 206 (Partial Content，部分内容) 響應封包包含了多個範圍的内容時使用。
第三章 HTTP封包内的HTTP資訊 第三章 HTTP封包内的HTTP資訊 在 HTTP 封包中使用多部分對象集合時，需要在首部字段裡加上Content-type。
使用 boundary 字元串來劃分多部分集合指明的各類實體。在boundary 指定的各個實體的起始行之前插入 “–” 标記，在多部分對象集合對應的字元串的最後插入 “–” 标記結束。
多部分對象集合的每個部分類型中都可以有首部字段。
可以在某個部分中嵌套使用多部分對象集合。
擷取部分内容的範圍要求
因為網絡原因中斷的下載下傳，有一種恢複機制，能從之前下載下傳中斷處恢複下載下傳。
實作該功能需要指定下載下傳的實體範圍。指定範圍發送的請求，稱為範圍請求（Range Request）。
使用首部字段 Range 來指定資源的 byte 範圍。
針對範圍請求，響應會傳回狀态碼為 206 Partial Content 的響應封包。
另外，對于多重範圍的範圍請求，響應會在首部字段 Content-Type 标明 multipart/byteranges 後傳回響應封包。
如果伺服器端無法響應範圍請求，則會傳回狀态碼 200 OK 和完整的實體内容。
内容協商傳回最合适的内容
同一個網站可能存在多個相同内容的頁面（比如中英文版）。
根據浏覽器預設語言，顯示對應的頁面，這種機制稱為内容協商（Content Negotiation）。
内容協商會以響應資源的語言、字元集、編碼方式等作為判斷的基準。
包含在請求封包中的某些首部字段就是判斷的基準。
- Accept
- Accept-Charset
- Accept-Encoding
- Accept-Language
- Content-Language
内容協商技術有以下三種類型：
-
伺服器驅動協商
由伺服器端進行協商。
以請求的首部字段作為參考，在服務端自動處理。但以浏覽器發送的資訊作為判斷依據并不 一定能篩選出最優内容。
-
用戶端驅動協商
由用戶端進行内容協商的方式。
使用者從浏覽器顯示的可選項清單中手動選擇。還能利用JavaScript腳本在web頁面上進行自動選擇。比如按OS或浏覽器類型自動切換PC版或手機版。
-
透明協商
伺服器驅動和用戶端驅動的結合體，友伺服器和用戶端各自進行協商的一種方法。