網絡編程懶人入門(六)：深刻淺出，全面理解HTTP協議

本文引用了自簡書做者「滌生_Woo」的文章，內容有刪減，感謝原做者的分享。

一、前言

HTTP（全稱超文本傳輸協議，英文全稱HyperText Transfer Protocol）是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。

對於移動端即時通信（尤爲IM應用）來講，現今主流的數據通訊總結下來無外乎就是長鏈接+短鏈接的方式，而短鏈接在應用上講就是本文將要介紹的HTTP協議的應用，而而正確地理解HTTP協議對於寫好IM來講，是至關有益的（關於移動端的HTTP具體應用狀況，能夠閱讀《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》）。

本篇文章篇幅比較長，先來個思惟導圖預覽一下：

 

學習交流：

- 即時通信開發交流3羣：185926912[推薦]

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

（本文同步發佈於：http://www.52im.net/thread-1677-1-1.html）

二、「HTTP之父」其人

 

▲ 「HTTP之父」——Ted Nelson

 

▲ HTTP協議logo

1960年Ted Nelson構思了一種經過計算機處理文本信息的方法，並稱之爲超文本（hypertext）,這成爲了HTTP超文本傳輸協議標準架構的發展根基。

Ted Nelson組織協調萬維網協會（World Wide Web Consortium）和Internet工做小組（Internet Engineering Task Force）共同合做研究，最終發佈了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協議的咱們今天廣泛使用的一個版本——HTTP 1.1。

因爲Ted Nelson對HTTP技術的發展作出的突破性歷史貢獻，他被稱爲「HTTP之父」。

三、系列文章

本文是系列文章中的第6篇，本系列文章的大綱以下：

《網絡編程懶人入門(一)：快速理解網絡通訊協議（上篇）》

《網絡編程懶人入門(二)：快速理解網絡通訊協議（下篇）》

《網絡編程懶人入門(三)：快速理解TCP協議一篇就夠》

《網絡編程懶人入門(四)：快速理解TCP和UDP的差別》

《網絡編程懶人入門(五)：快速理解爲何說UDP有時比TCP更有優點》

《網絡編程懶人入門(六)：深刻淺出，全面理解HTTP協議》（本文）

若是您以爲本系列文章過於基礎，您可直接閱讀《鮮爲人知的網絡編程》系列文章，該系列目錄以下：

《鮮爲人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》

《鮮爲人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》

《鮮爲人知的網絡編程(三)：關閉TCP鏈接時爲何會TIME_WAIT、CLOSE_WAIT》

《鮮爲人知的網絡編程(四)：深刻研究分析TCP的異常關閉》

《鮮爲人知的網絡編程(五)：UDP的鏈接性和負載均衡》

《鮮爲人知的網絡編程(六)：深刻地理解UDP協議並用好它》

關於移動端網絡特性及優化手段的總結性文章請見：

《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》

《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》

《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》

四、參考資料

《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》

《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》

《TCP/IP詳解 - 第18章·TCP鏈接的創建與終止》

《TCP/IP詳解 - 第21章·TCP的超時與重傳》

《通俗易懂-深刻理解TCP協議（上）：理論基礎》

《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》

《理論經典：TCP協議的3次握手與4次揮手過程詳解》

《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計算機網絡通信協議關係圖（中文珍藏版）》

《高性能網絡編程(一)：單臺服務器併發TCP鏈接數到底能夠有多少》

《高性能網絡編程(二)：上一個10年，著名的C10K併發鏈接問題》

《高性能網絡編程(三)：下一個10年，是時候考慮C10M併發問題了》

《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》

《簡述傳輸層協議TCP和UDP的區別》

《爲何QQ用的是UDP協議而不是TCP協議？》

《移動端即時通信協議選擇：UDP仍是TCP？》

五、HTTP概述

5.1 計算機網絡體系結構分層

 

5.2 TCP/IP 通訊傳輸流

利用 TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則從鏈路層往上走。

TCP/IP 通訊傳輸流以下：

 

首先做爲發送端的客戶端在應用層（HTTP 協議）發出一個想看某個 Web 頁面的 HTTP 請求；

接着，爲了傳輸方便，在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號後轉發給網絡層；

在網絡層（IP 協議），增長做爲通訊目的地的 MAC 地址後轉發給鏈路層。這樣一來，發往網絡的通訊請求就準備齊全了；

接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP請求。

HTTP 請求以下圖所示：

 

在網絡體系結構中，包含了衆多的網絡協議，這篇文章主要圍繞 HTTP 協議（HTTP/1.1版本）展開。

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

HTTP是客戶端瀏覽器或其餘程序與Web服務器之間的應用層通訊協議。在Internet上的Web服務器上存放的都是超文本信息，客戶機須要經過HTTP協議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不只可用於Web訪問，也能夠用於其餘因特網/內聯網應用系統之間的通訊，從而實現各種應用資源超媒體訪問的集成。

咱們在瀏覽器的地址欄裏輸入的網站地址叫作URL (Uniform Resource Locator，統一資源定位符)。就像每家每戶都有一個門牌地址同樣，每一個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級連接時，URL就肯定了要瀏覽的地址。瀏覽器經過超文本傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。

六、HTTP 工做過程

HTTP請求響應模型：

 

HTTP通訊機制是在一次完整的 HTTP 通訊過程當中，客戶端與服務器之間將完成下列7個步驟：

1）創建 TCP 鏈接：在HTTP工做開始以前，客戶端首先要經過網絡與服務器創建鏈接，該鏈接是經過 TCP 來完成的，該協議與 IP 協議共同構建 Internet，即著名的 TCP/IP 協議族，所以 Internet 又被稱做是 TCP/IP 網絡。HTTP 是比 TCP 更高層次的應用層協議，根據規則，只有低層協議創建以後，才能進行高層協議的鏈接，所以，首先要創建 TCP 鏈接，通常 TCP 鏈接的端口號是80；

2）客戶端向服務器發送請求命令：一旦創建了TCP鏈接，客戶端就會向服務器發送請求命令；

例如：GET/sample/hello.jsp HTTP/1.1；

3）客戶端發送請求頭信息：客戶端發送其請求命令以後，還要以頭信息的形式向服務器發送一些別的信息，以後客戶端發送了一空白行來通知服務器，它已經結束了該頭信息的發送；

4）服務器應答：客戶端向服務器發出請求後，服務器會客戶端返回響應；

例如： HTTP/1.1 200 OK

響應的第一部分是協議的版本號和響應狀態碼；

5）服務器返回響應頭信息：正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同響應向用戶發送關於它本身的數據及被請求的文檔；

6）服務器向客戶端發送數據：服務器向客戶端發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以 Content-Type 響應頭信息所描述的格式發送用戶所請求的實際數據；

7）服務器關閉 TCP 鏈接：通常狀況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 鏈接，而後若是客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 鏈接在發送後將仍然保持打開狀態，因而，客戶端能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

七、HTTP 協議基礎

7.1 經過請求和響應的交換達成通訊

應用 HTTP 協議時，一定是一端擔任客戶端角色，另外一端擔任服務器端角色。僅從一條通訊線路來講，服務器端和客服端的角色是肯定的。HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。

7.2 HTTP 是不保存狀態的協議

HTTP 是一種無狀態協議。協議自身不對請求和響應之間的通訊狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不作持久化處理。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。

但是隨着 Web 的不斷髮展，咱們的不少業務都須要對通訊狀態進行保存。因而咱們引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了。

7.3 使用 Cookie 的狀態管理

Cookie 技術經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

Cookie 的流程：

 

7.4 請求 URI 定位資源

HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。

7.5 告知服務器意圖的 HTTP 方法（HTTP/1.1）

 

7.6 持久鏈接

HTTP 協議的初始版本中，每進行一個 HTTP 通訊都要斷開一次 TCP 鏈接。好比使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無畏的 TCP 鏈接創建和斷開，增長通訊量的開銷。

爲了解決上述 TCP 鏈接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久鏈接的方法。其特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。旨在創建一次 TCP 鏈接後進行屢次請求和響應的交互。在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接。

7.7 管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。之前發送請求後需等待並接收到響應，才能發送下一個請求。管線化技術出現後，不用等待亦可發送下一個請求。這樣就能作到同時並行發送多個請求，而不須要一個接一個地等待響應了。

好比，當請求一個包含多張圖片的 HTML 頁面時，與挨個鏈接相比，用持久鏈接可讓請求更快結束。而管線化技術要比持久鏈接速度更快。請求數越多，時間差就越明顯。

八、HTTP 協議報文結構

8.1 HTTP 報文

用於 HTTP 協議交互的信息被稱爲 HTTP 報文。請求端（客戶端）的 HTTP 報文叫作請求報文；響應端（服務器端）的叫作響應報文。HTTP 報文自己是由多行（用 CR+LF 做換行符）數據構成的字符串文本。

8.2 HTTP 報文結構

HTTP 報文大體可分爲報文首部和報文主體兩部分。二者由最初出現的空行（CR+LF）來劃分。一般，並不必定有報文主體。

HTTP 報文結構以下：

 

 

8.3 請求報文結構

 

請求報文的首部內容由如下數據組成：

請求行 —— 包含用於請求的方法、請求 URI 和 HTTP 版本；

首部字段 —— 包含表示請求的各類條件和屬性的各種首部。（通用首部、請求首部、實體首部以及RFC裏未定義的首部如 Cookie 等）。

請求報文的示例，以下：

 

8.4 響應報文結構

 

響應報文的首部內容由如下數據組成：

狀態行 —— 包含代表響應結果的狀態碼、緣由短語和 HTTP 版本；

首部字段 —— 包含表示請求的各類條件和屬性的各種首部。（通用首部、響應首部、實體首部以及RFC裏未定義的首部如 Cookie 等）。

響應報文的示例，以下：

 

九、HTTP 報文首部之首部字段（重點分析）

9.1 首部字段概述

先來回顧一下首部字段在報文的位置，HTTP 報文包含報文首部和報文主體，報文首部包含請求行（或狀態行）和首部字段。

在報文衆多的字段當中，HTTP 首部字段包含的信息最爲豐富。首部字段同時存在於請求和響應報文內，並涵蓋 HTTP 報文相關的內容信息。使用首部字段是爲了給客服端和服務器端提供報文主體大小、所使用的語言、認證信息等內容。

9.2 首部字段結構

HTTP 首部字段是由首部字段名和字段值構成的，中間用冒號「：」分隔。

另外，字段值對應單個 HTTP 首部字段能夠有多個值。

當 HTTP 報文首部中出現了兩個或以上具備相同首部字段名的首部字段時，這種狀況在規範內還沒有明確，根據瀏覽器內部處理邏輯的不一樣，優先處理的順序可能不一樣，結果可能並不一致。

 

9.3首部字段類型

首部字段根據實際用途被分爲如下4種類型：

 

9.4通用首部字段（HTTP/1.1）

 

9.5請求首部字段（HTTP/1.1）

 

9.6響應首部字段（HTTP/1.1）

 

9.7實體首部字段（HTTP/1.1）

 

9.8爲 Cookie 服務的首部字段

 

十、其餘首部字段

HTTP 首部字段是能夠自行擴展的。因此在 Web 服務器和瀏覽器的應用上，會出現各類非標準的首部字段。如下是最爲經常使用的首部字段。

X-Frame-Options：

X-Frame-Options: DENY 首部字段 X-Frame-Options 屬於 HTTP 響應首部，用於控制網站內容在其餘 Web 網站的 Frame 標籤內的顯示問題。其主要目的是爲了防止點擊劫持（clickjacking）攻擊。首部字段 X-Frame-Options 有如下兩個可指定的字段值：

DENY：拒絕；

SAMEORIGIN：僅同源域名下的頁面（Top-level-browsing-context）匹配時許可。（好比，當指定 http://sample.com/sample.html 頁面爲 SAMEORIGIN 時，那麼 sample.com 上全部頁面的 frame 都被容許可加載該頁面，而 example.com 等其餘域名的頁面就不行了）。

X-XSS-Protection：

X-XSS-Protection: 1 首部字段 X-XSS-Protection 屬於 HTTP 響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防禦機制的開關。首部字段 X-XSS-Protection 可指定的字段值以下:

0 ：將 XSS 過濾設置成無效狀態

1 ：將 XSS 過濾設置成有效狀態

DNT：

DNT: 1 首部字段 DNT 屬於 HTTP 請求首部，其中 DNT 是 Do Not Track 的簡稱，意爲拒絕我的信息被收集，是表示拒絕被精準廣告追蹤的一種方法。首部字段 DNT 可指定的字段值以下：

0 ：贊成被追蹤

1 ：拒絕被追蹤

因爲首部字段 DNT 的功能具有有效性，因此 Web 服務器須要對 DNT作對應的支持。

P3P：

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND 首部字段 P3P 屬於 HTTP 響應首部，經過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術，可讓 Web 網站上的我的隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的目的。

要進行 P3P 的設定，需按如下操做步驟進行：

步驟 1：建立 P3P 隱私

步驟 2：建立 P3P 隱私對照文件後，保存命名在 /w3c/p3p.xml

步驟 3：從 P3P 隱私中新建 Compact policies 後，輸出到 HTTP 響應中

十一、HTTP 響應狀態碼

消息

描述

100 Continue

服務器僅接收到部分請求，可是一旦服務器並無拒絕該請求，客戶端應該繼續發送其他的請求。

101 Switching Protocols

服務器轉換協議：服務器將聽從客戶的請求轉換到另一種協議。

消息

描述

200 OK

請求成功（其後是對GET和POST請求的應答文檔。）

201 Created

請求被建立完成，同時新的資源被建立。

202 Accepted

供處理的請求已被接受，可是處理未完成。

203 Non-authoritative Information

文檔已經正常地返回，但一些應答頭可能不正確，由於使用的是文檔的拷貝。

204 No Content

沒有新文檔。瀏覽器應該繼續顯示原來的文檔。若是用戶按期地刷新頁面，而Servlet能夠肯定用戶文檔足夠新，這個狀態代碼是頗有用的。

205 Reset Content

沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。

206 Partial Content

客戶發送了一個帶有Range頭的GET請求，服務器完成了它。

消息

描述

300 Multiple Choices

多重選擇。連接列表。用戶能夠選擇某連接到達目的地。最多容許五個地址。

301 Moved Permanently

所請求的頁面已經轉移至新的url。

302 Found

所請求的頁面已經臨時轉移至新的url。

303 See Other

所請求的頁面可在別的url下被找到。

304 Not Modified

未按預期修改文檔。客戶端有緩衝的文檔併發出了一個條件性的請求（通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務器告訴客戶，原來緩衝的文檔還能夠繼續使用。

305 Use Proxy

客戶請求的文檔應該經過Location頭所指明的代理服務器提取。

306 Unused

此代碼被用於前一版本。目前已再也不使用，可是代碼依然被保留。

307 Temporary Redirect

被請求的頁面已經臨時移至新的url。

消息

描述

400 Bad Request

服務器未能理解請求。

401 Unauthorized

被請求的頁面須要用戶名和密碼。

401.1

登陸失敗。

401.2

服務器配置致使登陸失敗。

401.3

因爲 ACL 對資源的限制而未得到受權。

401.4

篩選器受權失敗。

401.5

ISAPI/CGI 應用程序受權失敗。

401.7

訪問被 Web 服務器上的 URL 受權策略拒絕。這個錯誤代碼爲 IIS 6.0 所專用。

402 Payment Required

此代碼尚沒法使用。

403 Forbidden

對被請求頁面的訪問被禁止。

403.1

執行訪問被禁止。

403.2

讀訪問被禁止。

403.3

寫訪問被禁止。

403.4

要求 SSL。

403.5

要求 SSL 128。

403.6

IP 地址被拒絕。

403.7

要求客戶端證書。

403.8

站點訪問被拒絕。

403.9

用戶數過多。

403.10

配置無效。

403.11

密碼更改。

403.12

拒絕訪問映射表。

403.13

客戶端證書被吊銷。

403.14

拒絕目錄列表。

403.15

超出客戶端訪問許可。

403.16

客戶端證書不受信任或無效。

403.17

客戶端證書已過時或還沒有生效。

403.18

在當前的應用程序池中不能執行所請求的 URL。這個錯誤代碼爲 IIS 6.0 所專用。

403.19

不能爲這個應用程序池中的客戶端執行 CGI。這個錯誤代碼爲 IIS 6.0 所專用。

403.20

Passport 登陸失敗。這個錯誤代碼爲 IIS 6.0 所專用。

404 Not Found

服務器沒法找到被請求的頁面。

404.0

（無）–沒有找到文件或目錄。

404.1

沒法在所請求的端口上訪問 Web 站點。

404.2

Web 服務擴展鎖定策略阻止本請求。

404.3

MIME 映射策略阻止本請求。

405 Method Not Allowed

請求中指定的方法不被容許。

406 Not Acceptable

服務器生成的響應沒法被客戶端所接受。

407 Proxy Authentication Required

用戶必須首先使用代理服務器進行驗證，這樣請求才會被處理。

408 Request Timeout

請求超出了服務器的等待時間。

409 Conflict

因爲衝突，請求沒法被完成。

410 Gone

被請求的頁面不可用。

411 Length Required

"Content-Length" 未被定義。若是無此內容，服務器不會接受請求。

412 Precondition Failed

請求中的前提條件被服務器評估爲失敗。

413 Request Entity Too Large

因爲所請求的實體的太大，服務器不會接受請求。

414 Request-url Too Long

因爲url太長，服務器不會接受請求。當post請求被轉換爲帶有很長的查詢信息的get請求時，就會發生這種狀況。

415 Unsupported Media Type

因爲媒介類型不被支持，服務器不會接受請求。

416 Requested Range Not Satisfiable

服務器不能知足客戶在請求中指定的Range頭。

417 Expectation Failed

執行失敗。

423

鎖定的錯誤。

消息

描述

500 Internal Server Error

請求未完成。服務器遇到不可預知的狀況。

500.12

應用程序正忙於在 Web 服務器上從新啓動。

500.13

Web 服務器太忙。

500.15

不容許直接請求 Global.asa。

500.16

UNC 受權憑據不正確。這個錯誤代碼爲 IIS 6.0 所專用。

500.18

URL 受權存儲不能打開。這個錯誤代碼爲 IIS 6.0 所專用。

500.100

內部 ASP 錯誤。

501 Not Implemented

請求未完成。服務器不支持所請求的功能。

502 Bad Gateway

請求未完成。服務器從上游服務器收到一個無效的響應。

502.1

CGI 應用程序超時。　·

502.2

CGI 應用程序出錯。

503 Service Unavailable

請求未完成。服務器臨時過載或當機。

504 Gateway Timeout

網關超時。

505 HTTP Version Not Supported

服務器不支持請求中指明的HTTP協議版本。

十二、HTTP 報文實體

12.1HTTP 報文實體概述

 

 

你們請仔細看看上面示例中，各個組成部分對應的內容。

接着，咱們來看看報文和實體的概念。若是把 HTTP 報文想象成因特網貨運系統中的箱子，那麼 HTTP 實體就是報文中實際的貨物。

報文：是網絡中交換和傳輸的數據單元，即站點一次性要發送的數據塊。報文包含了將要發送的完整的數據信息，其長短很不一致，長度不限且可變；

實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。（實體首部相關內容在上面第六點中已有闡述。）

咱們能夠看到，上面示例右圖中深紅色框的內容就是報文的實體部分，而藍色框的兩部份內容分別就是實體首部和實體主體。而左圖中粉紅框內容就是報文主體。

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

12.2內容編碼

HTTP 應用程序有時在發送以前須要對內容進行編碼。例如，在把很大的 HTML 文檔發送給經過慢速鏈接上來的客戶端以前，服務器可能會對其進行壓縮，這樣有助於減小傳輸實體的時間。服務器還能夠把內容攪亂或加密，以此來防止未受權的第三方看到文檔的內容。

這種類型的編碼是在發送方應用到內容之上的。當內容通過內容編碼後，編好碼的數據就放在實體主體中，像往常同樣發送給接收方。

內容編碼類型：

 

 

12.3傳輸編碼

內容編碼是對報文的主體進行的可逆變換，是和內容的具體格式細節緊密相關的。

傳輸編碼也是做用在實體主體上的可逆變換，但使用它們是因爲架構方面的緣由，同內容的格式無關。使用傳輸編碼是爲了改變報文中的數據在網絡上傳輸的方式。

 

 

12.4分塊編碼

分塊編碼把報文分割成若干已知大小的塊。塊之間是緊挨着發送的，這樣就不須要在發送以前知道整個報文的大小了。分塊編碼是一種傳輸編碼，是報文的屬性。

若客戶端與服務器端之間不是持久鏈接，客戶端就不須要知道它在讀取的主體的長度，而只須要讀取到服務器關閉主體鏈接爲止。

當使用持久鏈接時，在服務器寫主體以前，必須知道它的大小並在 Content-Length 首部中發送。若是服務器動態建立內容，就可能在發送以前沒法知道主體的長度。

分塊編碼爲這種困難提供瞭解決方案，只要容許服務器把主體分塊發送，說明每塊的大小就能夠了。由於主體是動態建立的，服務器能夠緩衝它的一部分，發送其大小和相應的塊，而後在主體發送完以前重複這個過程。服務器能夠用大小爲 0 的塊做爲主體結束的信號，這樣就能夠繼續保持鏈接，爲下一個響應作準備。

來看看一個分塊編碼的報文示例：

 

 

12.5多部分媒體類型

MIME 中的 multipart（多部分）電子郵件報文中包含多個報文，它們合在一塊兒做爲單一的複雜報文發送。每一部分都是獨立的，有各自的描述其內容的集，不一樣部分之間用分界字符串鏈接在一塊兒。

相應得，HTTP 協議中也採納了多部分對象集合，發送的一份報文主體內可包含多種類型實體。

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

multipart/form-data：在 Web 表單文件上傳時使用；

multipart/byteranges：狀態碼 206 Partial Content 響應報文包含了多個範圍的內容時使用。

12.6範圍請求

假設你正在下載一個很大的文件，已經下了四分之三，突然網絡中斷了，那下載就必須重頭再來一遍。爲了解決這個問題，須要一種可恢復的機制，即能從以前下載中斷處恢復下載。要實現該功能，這就要用到範圍請求。

有了範圍請求， HTTP 客戶端能夠經過請求曾獲取失敗的實體的一個範圍（或者說一部分），來恢復下載該實體。固然這有一個前提，那就是從客戶端上一次請求該實體到這一次發出範圍請求的時間段內，該對象沒有改變過。例如：

GET  /bigfile.html  HTTP/1.1

Host: [url=http://www.sample.com]www.sample.com[/url]

Range: bytes=20224-

···

 

 

上面示例中，客戶端請求的是文檔開頭20224字節以後的部分。

1三、與 HTTP 協做的 Web 服務器

HTTP 通訊時，除客戶端和服務器外，還有一些用於協助通訊的應用程序。以下列出比較重要的幾個：代理、緩存、網關、隧道、Agent 代理。

13.1代理

 

 

HTTP 代理服務器是 Web 安全、應用集成以及性能優化的重要組成模塊。代理位於客戶端和服務器端之間，接收客戶端全部的 HTTP 請求，並將這些請求轉發給服務器（可能會對請求進行修改以後再進行轉發）。對用戶來講，這些應用程序就是一個代理，表明用戶訪問服務器。

出於安全考慮，一般會將代理做爲轉發全部 Web 流量的可信任中間節點使用。代理還能夠對請求和響應進行過濾，安全上網或綠色上網。

13.2緩存

瀏覽器第一次請求：

 

 

瀏覽器再次請求：

 

 

Web 緩存或代理緩存是一種特殊的 HTTP 代理服務器，能夠將通過代理傳輸的經常使用文檔複製保存起來。下一個請求同一文檔的客戶端就能夠享受緩存的私有副本所提供的服務了。客戶端從附近的緩存下載文檔會比從遠程 Web 服務器下載快得多。

13.3網關

 

 

網關是一種特殊的服務器，做爲其餘服務器的中間實體使用。一般用於將 HTTP 流量轉換成其餘的協議。網關接收請求時就好像本身是資源的源服務器同樣。客戶端可能並不知道本身正在跟一個網關進行通訊。

13.4隧道

 

 

隧道是會在創建起來以後，就會在兩條鏈接之間對原始數據進行盲轉發的 HTTP 應用程序。HTTP 隧道一般用來在一條或多條 HTTP 鏈接上轉發非 HTTP 數據，轉發時不會窺探數據。

HTTP 隧道的一種常見用途就是經過 HTTP 鏈接承載加密的安全套接字層（SSL）流量，這樣 SSL 流量就能夠穿過只容許 Web 流量經過的防火牆了。

13.5Agent 代理

 

 

Agent 代理是表明用戶發起 HTTP 請求的客戶端應用程序。全部發布 Web 請求的應用程序都是 HTTP Agent 代理。

（原文連接：https://www.jianshu.com/p/6e9e4156ece3）

附錄：更多網絡編程資料

《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》

《UDP中一個包的大小最大能多大？》

《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》

《NIO框架入門(一)：服務端基於Netty4的UDP雙向通訊Demo演示》

《NIO框架入門(二)：服務端基於MINA2的UDP雙向通訊Demo演示》

《NIO框架入門(三)：iOS與MINA二、Netty4的跨平臺UDP雙向通訊實戰》

《NIO框架入門(四)：Android與MINA二、Netty4的跨平臺UDP雙向通訊實戰》

《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》

《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》

《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》

《通俗易懂：快速理解P2P技術中的NAT穿透原理》

>> 更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-1677-1-1.html）