HTTP報文
用于HTTP協(xié)議交互的信息被稱作為HTTP報文。請求端和服務端分別被叫做請求報文和響應報文。HTTP報文由報文首部和報文主體組成，首部和主體之間由【CR+LF】換行分割，一個HTTP報文不一定需要報文主體。
請求報文首部：請求行、請求首部字段、通用首部字段、實體首部字段、其他。
響應報文首部：狀態(tài)行、響應首部字段、通用首部字段、實體首部字段、其他。
-
請求報文：
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) --空行 -
響應報文：
HTTP/1.1 200 OK -- 狀態(tài)行 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> ... -- 響應主體 -
請求報文和響應報文的首部內(nèi)容由以下數(shù)據(jù)組成：
- 請求行： 包含用于請求的方法，請求的URI和HTTP版本
- 狀態(tài)行： 包含表面闡述響應結果的狀態(tài)碼，原因短語和HTTP版本
- 首部字段：包含表示請求和響應結果的各種條件和屬性的各類首部。一般有4中首部，分別是：通用首部、請求首部、響應首部、實體首部。
- 其他： 可能包含HTTP的RFC里沒有定義的首部（Cookie等）。
-
編碼提升傳輸效率
通過在傳輸時編碼，能有效地處理大量的訪問請求。但是，編碼的操作需要計算機來完成，因此會消耗更多的CPU等資源。
-
報文主體和實體主體的差異
-
報文
是HTTP通信中的基本你單位，由8位字節(jié)流組成，通過HTTP通信傳輸。
-
實體
作為請求或響應的有效載荷數(shù)據(jù)被傳輸，其內(nèi)容由實體首部和實體主體組成。
HTTP報文的主體用于傳輸請求或響應的實體主體。
通常，報文主體等于實體主體，只有在傳輸中進行編碼操作，實體主體的內(nèi)容會發(fā)生變化，才導致它和報文主體產(chǎn)生差異。
-
-
-
壓縮傳輸?shù)膬?nèi)容編碼
HTTP協(xié)議中有一種被稱為內(nèi)容編碼的功能也能進行類型的操作，內(nèi)容編碼指明應用在實體內(nèi)容上的編碼格式，并保持實體信息原樣壓縮。內(nèi)容編碼后的實體由客戶端接收并負責解碼。
- 壓縮并解碼.png
常用的內(nèi)容編碼有以下幾種
gzip（GNU zip）
compress （UNIX 系統(tǒng)的標準壓縮）
deflate （zlib）
identity （不進行編碼）
-
分割發(fā)送的分塊傳輸編碼
- 分塊編碼傳輸.png
在HTTP通信過程中，請求的編碼實體在沒有全部傳輸完成之前，瀏覽器是無法顯示請求頁面的。所以在傳輸大量數(shù)據(jù)時，通常會把數(shù)據(jù)分割成多塊。將這種技術稱為 分塊傳輸編碼。
使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。
-
發(fā)送多種數(shù)據(jù)的多部分對象集合
發(fā)送郵件時，我們可以在郵件里寫入文字并添加多發(fā)附件。這是因為采用了MIME（Multipurpose Internet Mail Extensions，多用途因特網(wǎng)郵件擴展）機制，它允許郵件處理文本、圖片、視頻等多個不同類型的數(shù)據(jù)。
HTTP協(xié)議中也采納了多部分對象集合，發(fā)送的一份報文主體內(nèi)可含多類型實體。通常是在圖片或文本文件等上傳時使用。
多部分對象集合包含的對象如下：
-
multipart/form-data
在Web表單文件上傳使用
-
multipart/byteranges
狀態(tài)碼206響應報文包含了多個范圍的內(nèi)容時使用。
-
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的數(shù)據(jù)）... --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 ...（范圍指定的數(shù)據(jù)）... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000 ...（范圍指定的數(shù)據(jù)）... --THIS_STRING_SEPARATES--
-
-
獲取部分內(nèi)容的范圍請求
以前的用戶帶寬不夠，下載一個尺寸稍大的圖片或者文件就會很吃力。如果下載過程中遇到網(wǎng)絡問題中斷了下載，那么就需要從頭開始。為了解決上述問題，就產(chǎn)生了一種叫范圍請求的功能。
對于一份10000字節(jié)大小的資源，如果使用范圍請求，可以只請求5001~10000字節(jié)內(nèi)的資源。
- 范圍請求.png
執(zhí)行范圍請求時，會用到首部字段Range來指定資源的byte范圍：
Range: bytes=5001-10000 // 5001-10000字節(jié)之間
Range: bytes=5001- // 從5001字節(jié)之后全部
Range: bytes=1-3000,5000-10000 // 多范圍指定
針對范圍請求，響應會返回206狀態(tài)碼。對于多重范圍請求，響應會在首部字段Content-Type表明multipart/byteranges后返回響應報文
如果服務端無法響應范圍請求，則會返回狀態(tài)碼200 OK然后返回完整的實體內(nèi)容。
github 歡迎Star，歡迎討論
