HTTP報文內的資訊

用於 HTTP 協議互動的資訊被稱為 HTTP 報文。請求端（客戶端）的 HTTP 報文叫做請求報文，響應端（服
務器端）的叫做響應報文。HTTP 報文字身是由多行（用 CR+LF 作換行符）資料構成的字串文字。

HTTP 報文大致可分為報文首部和報文主體兩塊。兩者由最初出現的空行（CR+LF）來劃分。通常，並不一
定要有報文主體

請求報文及相應報文

例項

• 請求行：包含用於請求的方法，請求URL和HTTP版本
• 狀態行：包含表明響應結果的狀態碼，原因短語和HTTP版本

• 首部欄位：包含表示請求和響應的各種條件和屬性的各類首部。
  一般有 4 種首部，分別是：通用首部、請求首部、響應首部和實體首部。

• 其他：可能包含HTTP的RFC裡未定義的首部(Cookie)

編碼提升傳輸速率

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

• 報文： 是 HTTP 通訊中的基本單位，由 8 位組位元組流（octet sequence，其中 octet 為 8 個位元）組成，通過
  HTTP 通訊傳輸。

• 實體：作為請求或響應的有效載荷資料（補充項）被傳輸，其內容由實體首部和實體主體組成。

通常，報文主體等於實體主體。只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文
主體產生差異

壓縮傳輸的內容編碼

壓縮傳輸

內容編碼指明應用在實體內容上的編碼格式，並保持實體資訊原樣壓縮。內容編碼後的實體由客戶端接收並
負責解碼。

常用的內容編碼有以下幾種

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

分割傳送的分塊傳輸編碼

在傳輸大容
量資料時，通過把資料分割成多塊，能夠讓瀏覽器逐步顯示頁面。
這種把實體主體分塊的功能稱為分塊傳輸編碼（Chunked Transfer Coding）。

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

傳送多資料的多部分物件集合

HTTP 協議中也採納了多部分物件集合，傳送的一份報文主體內可含有多型別實體。通常是在圖片
或文字檔案等上傳時使用。
多部分物件集合包含的物件如下。

• multipart/form-data：
  在Web表單檔案上傳時使用

• multipart/byteranges: 狀態碼206

在HTTP報文中使用多部分物件集合時，需要在首部欄位里加上Content-type

使用 boundary 字串來劃分多部分物件集合指明的各類實體。在 boundary 字串指定的各個實體的起始行
之前插入“–”標記（例如：–AaB03x、–THIS_STRING_SEPARATES），而在多部分物件集合對應的字串
的最後插入“–”標記（例如：–AaB03x–、–THIS_STRING_SEPARATES–）作為結束。

獲取部分內容的範圍請求

以前，使用者不能使用現在這種高速的頻寬訪問網際網路，當時，下載一個尺寸稍大的圖片或檔案就已經很吃力
了。如果下載過程中遇到網路中斷的情況，那就必須重頭開始。為了解決上述問題，需要一種可恢復的機
制。所謂恢復是指能從之前下載中斷處恢復下載。
要實現該功能需要指定下載的實體範圍。像這樣，指定範圍傳送的請求叫做範圍請求（Range Request）。

執行範圍請求時，會用到首部欄位 Range 來指定資源的 byte 範圍。

針對範圍請求，響應會返回狀態碼為 206 Partial Content 的響應報文。另外，對於多重範圍的範圍請求，響
應會在首部欄位 Content-Type 標明 multipart/byteranges 後返回響應報文。
如果伺服器端無法響應範圍請求，則會返回狀態碼 200 OK 和完整的實體內容。

內容協商

• 伺服器驅動協商：由伺服器端進行內容協商。以請求的首部欄位為參考，在伺服器端自動處理。但對使用者來說，以瀏覽器傳送
  的資訊作為判定的依據，並不一定能篩選出最優內容。

• 客戶端驅動協商：由客戶端進行內容協商的方式。使用者從瀏覽器顯示的可選項列表中手動選擇。還可以利用 JavaScript 指令碼在
  Web 頁面上自動進行上述選擇。比如按 OS 的型別或瀏覽器型別，自行切換成 PC 版頁面或手機版頁面

• 透明協商：是伺服器驅動和客戶端驅動的結合體，是由伺服器端和客戶端各自進行內容協商的一種方法。