HTTP報文

HTTP報文：用於HTTP協議互動的資訊

• HTTP報文大致可分為報文首部和報文主體兩塊。由空行(CR+LF)來劃分。
  

• 請求報文和響應報文

  • 請求行：包含用於請求的方法，請求URI和HTTP版本
  • 狀態行：包括表明響應結果的狀態碼，原因短語和HTTP版本
  • 首部欄位：包含表示請求和響應的各種條件和屬性的各類首部。

例項：

編碼提升傳輸速率

• 報文主體和實體主體：

  • 報文 ：HTTP通訊的基本單位，由8位組位元組流組成
  • 實體：作為請求或響應的有效載荷資料，由實體首部和實體主體組成
  • HTTP報文的主體用於傳輸請求或響應的實體主體，報文主體=實體主體，只有進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異。

• 壓縮傳輸的內容編碼
  內容編碼指明應用在實體內容上的編碼格式，並保持實體資訊原樣壓縮。
  內容編碼後的實體由客戶端接收並負責解碼
  常用的內容編碼：gzip、compress、deflate、identity

• 分割傳送的分塊傳輸編碼
  把實體主體分成多個部分，每一塊都會用16進位制來標記塊的大小，而實體主體最後一塊會使用0(CR+LF)來標記。

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

MEME機制：Multipurpose Internet Mail Extensions，多用途因特網郵件擴充套件機制，它允許郵件處理文字、圖片、視訊等多個不同型別的資料。

• 多部分物件集合的物件如下：
  
  • multipart/form-data 在Web表單檔案上傳時使用
  • multipart/byteranges 狀態碼206(Partial Content，部分內容)響應報文包含了多個範圍的內容時使用

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

獲取部分內容的範圍請求

範圍請求(Range Request)：指定下載實體範圍的請求。
使用首部欄位Range：bytes= -3000來指定資源的byte範圍。

內容協商返回最合適的內容

• 內容協商機制(Content Negotiation)：指客戶端和伺服器端就響應的資源內容進行交涉，然後提供給客戶端最為適合的資源。內容協商會以資源的語言、字符集、編碼方式等作為判斷的基準。

• 這些請求首部欄位就是判斷的標準：

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

• 內容協商的技術型別：

  • 伺服器驅動協商(Server-driven Negotiation)：由服務端進行內容協商，以請求的首部欄位為參考，在服務端自動處理。但對使用者來說，以瀏覽器傳送的資訊作為判定依據，並不一定能篩選出最優內容。
  • 客戶端驅動協商(Agent-driven Negotiation)：由客戶端進行內容協商的方式。使用者從瀏覽器顯示的可選項列表中手動選擇，或者通過JS在Web頁面上自動進行上述選擇，比較按OS的型別或瀏覽器型別，自動切換PC或H5。
  • 透明協商(Transparent Negotiation)：是伺服器驅動和客戶端驅動的結合體，是由伺服器端和客戶端各自進行內容協商的一種方法。