寫在前面：本文僅供個人學習使用，如有侵權，請聯系刪除。文章中所用圖片絕大多數來源于《圖解HTTP》，請讀者支持原版。

文章目錄

• 第3章 HTTP報文內的HTTP信息
• • 3.1 HTTP報文
  • 3.2 請求報文及響應報文的結構
  • 3.3 編碼提升傳輸效率
  • • 3.3.1 報文主體和實體主體的差異
    • 3.3.2 壓縮傳輸的內容編碼
    • 3.3.3分割發送的分塊傳輸編碼
  • 3.4 發送多種數據的多部分對象集合
  • 3.5 獲取部分內容的范圍請求
  • 3.6 內容協商返回最合適的內容

HTTP通信過程包括從客戶端發往服務器端的請求以及從服務器端返回客戶端的響應。本章就讓我們來了解一下請求和響應是怎樣運作的。

第3章 HTTP報文內的HTTP信息

3.1 HTTP報文

用于HTTP協議交互的信息被稱為HTTP報文。請求端(客戶端)的HTTP報文叫做請求報文，響應端(服務器端)的叫做響應報文。http報文本身是由多行(用CR+LF作換行符)數據構成的字符串文本。

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

3.2 請求報文及響應報文的結構

我們來看一下請求報文和響應報文的結構

請求報文和響應報文的首部內容由以下數據組成。現在出現的各種首部字段及狀態碼稍后會進行闡述。

請求行
包含用于請求的方法，請求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)。

分塊傳輸編碼會將實體主體分成多個部分(塊).每一塊都會用十六進制來標記塊的大小，而實體主體的最后一塊會使用“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,部分內容)響應報文包含了多個范圍的內容時使用。

multipart/form-data

Content-Type:multipart/form-data; boundary=AaB03x--AaB03x Content-Disposition:form-data; name="field1"Joe Blow --AaB03x Content-Disposition:form-data;name="pics"; filename="file1.txt" Content-Type:text/plain...(file1.txt的數據)...--AaB03x--

multipart/byteranges

后面的內容如下
HTTP/1.1 206 Partial Content

在HTTP報文中使用多部分對象集合時，需要在首部字段里加上Content-Type。有關這個首部字段，我們稍后講解。

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

多部分對象集合的每個部分類型中，都可以含有首部字段。另外，可以在某個部分中嵌套使用多部分對象集合。

3.5 獲取部分內容的范圍請求

以前，用戶不能使用現在這種高速的帶寬訪問互聯網，當時，下載一個尺寸稍大的圖片或文件就已經很吃力了。如果下載過程中遇到網絡中斷的情況，那就必須從頭開始。為了解決上述問題，需要一種可恢復的機制。所謂恢復是指能從之前下載中斷處恢復下載。

要實現該功能需要指定下載的實體范圍。像這樣，指定范圍發送的請求叫做范圍請求(Range Request)。

對10000字節大小的資源，如果使用范圍請求，可以只請求5000~10000字節內的資源。

執行范圍請求時，會用到首部字段Range來指定資源的byte范圍。byte范圍的指定形式如下。

5001~10000字節

Range:bytes=5001-10000

從5001字節之后全部的

Range:bytes=5001-

從一開始到3000字節和5000~7000字節的多重范圍

Range:bytes=0-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頁面上自動進行上述選擇。比如按OS的類型或瀏覽器類型，自行切換成PC版頁面或手機版頁面。

透明協商(Transparent Negotiation)

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

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的《图解HTTP》读书笔记--第3章HTTP报文内的HTTP信息的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。