《圖解HTTP》學習筆記（三）：HTTP報文內的HTTP信息

時間 2019-12-13

原文原文鏈接

HTTP報文

用於HTTP協議交互的信息被稱做爲HTTP報文。請求端和服務端分別被叫作請求報文和響應報文。HTTP報文由報文首部和報文主體組成，首部和主體之間由【CR+LF】換行分割，一個HTTP報文不必定須要報文主體。
請求報文首部：請求行、請求首部字段、通用首部字段、實體首部字段、其餘。
響應報文首部：狀態行、響應首部字段、通用首部字段、實體首部字段、其餘。

請求報文：html

GET / HTTP/1.1  --請求行
Host:www.baidu.com
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Accept-Encoding:gzip, deflate, br
Upgrade-Insecure-Requests:1
Cache-Control:max-age=0
Connection:keep-alive                --各類首部字段
(CR-LF) --空行

響應報文：git

HTTP/1.1 200 OK -- 狀態行
Bdpagetype:2
Bdqid:0xb377d200000097b1
Bduserid:1270621848
Cache-Control:private
Connection:Keep-Alive
Content-Encoding:gzip
Content-Type:text/html;charset=utf-8
Date:Wed, 18 Oct 2017 05:57:28 GMT
Expires:Wed, 18 Oct 2017 05:57:28 GMT
Server:BWS/1.1
Set-Cookie:BDSVRTM=187; path=/
Set-Cookie:BD_HOME=1; path=/
Set-Cookie:H_PS_PSSID=1450_21119_20929; path=/; domain=.baidu.com
Strict-Transport-Security:max-age=172800
Transfer-Encoding:chunked
X-Ua-Compatible:IE=Edge,chrome=1    -- 各類首部字段
(CR-LF) -- 空行
<!Doctype html>
<html xmlns=http://www.w3.org/1999/xhtml>
<head>
...                                 -- 響應主體

請求報文和響應報文的首部內容由如下數據組成：github
- 請求行：包含用於請求的方法，請求的URI和HTTP版本
- 狀態行：包含表面闡述響應結果的狀態碼，緣由短語和HTTP版本
- 首部字段：包含表示請求和響應結果的各類條件和屬性的各種首部。通常有4中首部，分別是：通用首部、請求首部、響應首部、實體首部。
- 其餘：可能包含HTTP的RFC裏沒有定義的首部（Cookie等）。
編碼提高傳輸效率web

經過在傳輸時編碼，能有效地處理大量的訪問請求。可是，編碼的操做須要計算機來完成，所以會消耗更多的CPU等資源。chrome
- 報文主體和實體主體的差別瀏覽器
  - 報文
    是HTTP通訊中的基本你單位，由8位字節流組成，經過HTTP通訊傳輸。網絡
  - 實體
    做爲請求或響應的有效載荷數據被傳輸，其內容由實體首部和實體主體組成。app

HTTP報文的主體用於傳輸請求或響應的實體主體。

一般，報文主體等於實體主體，只有在傳輸中進行編碼操做，實體主體的內容會發生變化，才致使它和報文主體產生差別。

壓縮傳輸的內容編碼dom

HTTP協議中有一種被稱爲內容編碼的功能也能進行類型的操做，內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。ide

經常使用的內容編碼有如下幾種

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

分割發送的分塊傳輸編碼

在HTTP通訊過程當中，請求的編碼實體在沒有所有傳輸完成以前，瀏覽器是沒法顯示請求頁面的。因此在傳輸大量數據時，一般會把數據分割成多塊。將這種技術稱爲分塊傳輸編碼。

使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。

發送多種數據的多部分對象集合

發送郵件時，咱們能夠在郵件裏寫入文字並添加多發附件。這是由於採用了MIME（Multipurpose Internet Mail Extensions，多用途因特網郵件擴展）機制，它容許郵件處理文本、圖片、視頻等多個不一樣類型的數據。

HTTP協議中也採納了多部分對象集合，發送的一份報文主體內可含多類型實體。一般是在圖片或文本文件等上傳時使用。

多部分對象集合包含的對象以下：

multipart/form-data
在Web表單文件上傳使用
multipart/byteranges
狀態碼206響應報文包含了多個範圍的內容時使用。

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
Date: Fri, 13 Jul 2012 02:45:26 GMT
Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...（範圍指定的數據）...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...（範圍指定的數據）...
--THIS_STRING_SEPARATES--

獲取部份內容的範圍請求

之前的用戶帶寬不夠，下載一個尺寸稍大的圖片或者文件就會很吃力。若是下載過程當中遇到網絡問題中斷了下載，那麼就須要從頭開始。爲了解決上述問題，就產生了一種叫範圍請求的功能。

對於一份10000字節大小的資源，若是使用範圍請求，能夠只請求5001~10000字節內的資源。

執行範圍請求時，會用到首部字段Range來指定資源的byte範圍：

Range: bytes=5001-10000 // 5001-10000字節之間

Range: bytes=5001- // 從5001字節以後所有

Range: bytes=1-3000,5000-10000 // 多範圍指定

針對範圍請求，響應會返回206狀態碼。對於多重範圍請求，響應會在首部字段Content-Type代表multipart/byteranges後返回響應報文

若是服務端沒法響應範圍請求，則會返回狀態碼200 OK而後返回完整的實體內容。

github 歡迎Star，歡迎討論

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。