本文引用了自簡(jiǎn)書作者“滌生_Woo”的文章，內(nèi)容有刪減，感謝原作者的分享。

1、前言

HTTP（全稱超文本傳輸協(xié)議，英文全稱HyperText Transfer Protocol）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

對(duì)于移動(dòng)端即時(shí)通訊（尤其IM應(yīng)用）來(lái)說(shuō)，現(xiàn)今主流的數(shù)據(jù)通信總結(jié)下來(lái)無(wú)外乎就是長(zhǎng)連接+短連接的方式，而短連接在應(yīng)用上講就是本文將要介紹的HTTP協(xié)議的應(yīng)用，而而正確地理解HTTP協(xié)議對(duì)于寫好IM來(lái)說(shuō)，是相當(dāng)有益的（關(guān)于移動(dòng)端的HTTP具體應(yīng)用情況，可以閱讀《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》）。

本篇文章篇幅比較長(zhǎng)，先來(lái)個(gè)思維導(dǎo)圖預(yù)覽一下：

學(xué)習(xí)交流：

- 即時(shí)通訊開發(fā)交流3群：185926912[推薦]

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-1677-1-1.html）

2、“HTTP之父”其人

▲ “HTTP之父”——Ted Nelson

▲ HTTP協(xié)議logo

1960年Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。

Ted Nelson組織協(xié)調(diào)萬(wàn)維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和Internet工作小組（Internet Engineering Task Force）共同合作研究，最終發(fā)布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定義了HTTP協(xié)議的我們今天普遍使用的一個(gè)版本——HTTP 1.1。

由于Ted Nelson對(duì)HTTP技術(shù)的發(fā)展做出的突破性歷史貢獻(xiàn)，他被稱為“HTTP之父”。

3、系列文章

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

《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說(shuō)UDP有時(shí)比TCP更有優(yōu)勢(shì)》

《網(wǎng)絡(luò)編程懶人入門(六)：深入淺出，全面理解HTTP協(xié)議》（本文）

如果您覺得本系列文章過于基礎(chǔ)，您可直接閱讀《不為人知的網(wǎng)絡(luò)編程》系列文章，該系列目錄如下：

《不為人知的網(wǎng)絡(luò)編程(一)：淺析TCP協(xié)議中的疑難雜癥(上篇)》

《不為人知的網(wǎng)絡(luò)編程(二)：淺析TCP協(xié)議中的疑難雜癥(下篇)》

《不為人知的網(wǎng)絡(luò)編程(三)：關(guān)閉TCP連接時(shí)為什么會(huì)TIME_WAIT、CLOSE_WAIT》

《不為人知的網(wǎng)絡(luò)編程(四)：深入研究分析TCP的異常關(guān)閉》

《不為人知的網(wǎng)絡(luò)編程(五)：UDP的連接性和負(fù)載均衡》

《不為人知的網(wǎng)絡(luò)編程(六)：深入地理解UDP協(xié)議并用好它》

關(guān)于移動(dòng)端網(wǎng)絡(luò)特性及優(yōu)化手段的總結(jié)性文章請(qǐng)見：

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《移動(dòng)端IM開發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

4、參考資料

《TCP/IP詳解 - 第11章·UDP：用戶數(shù)據(jù)報(bào)協(xié)議》

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

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

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

《通俗易懂-深入理解TCP協(xié)議（上）：理論基礎(chǔ)》

《通俗易懂-深入理解TCP協(xié)議（下）：RTT、滑動(dòng)窗口、擁塞處理》

《理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過程詳解》

《理論聯(lián)系實(shí)際：Wireshark抓包分析TCP 3次握手、4次揮手過程》

《計(jì)算機(jī)網(wǎng)絡(luò)通訊協(xié)議關(guān)系圖（中文珍藏版）》

《高性能網(wǎng)絡(luò)編程(一)：?jiǎn)闻_(tái)服務(wù)器并發(fā)TCP連接數(shù)到底可以有多少》

《高性能網(wǎng)絡(luò)編程(二)：上一個(gè)10年，著名的C10K并發(fā)連接問題》

《高性能網(wǎng)絡(luò)編程(三)：下一個(gè)10年，是時(shí)候考慮C10M并發(fā)問題了》

《高性能網(wǎng)絡(luò)編程(四)：從C10K到C10M高性能網(wǎng)絡(luò)應(yīng)用的理論探索》

《簡(jiǎn)述傳輸層協(xié)議TCP和UDP的區(qū)別》

《為什么QQ用的是UDP協(xié)議而不是TCP協(xié)議？》

《移動(dòng)端即時(shí)通訊協(xié)議選擇：UDP還是TCP？》

5、HTTP概述

5.1 計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)分層

5.2 TCP/IP 通信傳輸流

利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過分層順序與對(duì)方進(jìn)行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。

TCP/IP 通信傳輸流如下：

首先作為發(fā)送端的客戶端在應(yīng)用層（HTTP 協(xié)議）發(fā)出一個(gè)想看某個(gè) Web 頁(yè)面的 HTTP 請(qǐng)求；

接著，為了傳輸方便，在傳輸層（TCP 協(xié)議）把從應(yīng)用層處收到的數(shù)據(jù)（HTTP 請(qǐng)求報(bào)文）進(jìn)行分割，并在各個(gè)報(bào)文上打上標(biāo)記序號(hào)及端口號(hào)后轉(zhuǎn)發(fā)給網(wǎng)絡(luò)層；

在網(wǎng)絡(luò)層（IP 協(xié)議），增加作為通信目的地的 MAC 地址后轉(zhuǎn)發(fā)給鏈路層。這樣一來(lái)，發(fā)往網(wǎng)絡(luò)的通信請(qǐng)求就準(zhǔn)備齊全了；

接收端的服務(wù)器在鏈路層接收到數(shù)據(jù)，按序往上層發(fā)送，一直到應(yīng)用層。當(dāng)傳輸?shù)綉?yīng)用層，才能算真正接收到由客戶端發(fā)送過來(lái)的 HTTP請(qǐng)求。

HTTP 請(qǐng)求如下圖所示：

在網(wǎng)絡(luò)體系結(jié)構(gòu)中，包含了眾多的網(wǎng)絡(luò)協(xié)議，這篇文章主要圍繞 HTTP 協(xié)議（HTTP/1.1版本）展開。

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡(luò)傳輸減少。它不僅保證計(jì)算機(jī)正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。

HTTP是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議。在Internet上的Web服務(wù)器上存放的都是超文本信息，客戶機(jī)需要通過HTTP協(xié)議傳輸所要訪問的超文本信息。HTTP包含命令和傳輸信息，不僅可用于Web訪問，也可以用于其他因特網(wǎng)/內(nèi)聯(lián)網(wǎng)應(yīng)用系統(tǒng)之間的通信，從而實(shí)現(xiàn)各類應(yīng)用資源超媒體訪問的集成。

我們?cè)跒g覽器的地址欄里輸入的網(wǎng)站地址叫做URL (Uniform Resource Locator，統(tǒng)一資源定位符)。就像每家每戶都有一個(gè)門牌地址一樣，每個(gè)網(wǎng)頁(yè)也都有一個(gè)Internet地址。當(dāng)你在瀏覽器的地址框中輸入一個(gè)URL或是單擊一個(gè)超級(jí)鏈接時(shí)，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協(xié)議(HTTP)，將Web服務(wù)器上站點(diǎn)的網(wǎng)頁(yè)代碼提取出來(lái)，并翻譯成漂亮的網(wǎng)頁(yè)。

6、HTTP 工作過程

HTTP請(qǐng)求響應(yīng)模型：

HTTP通信機(jī)制是在一次完整的 HTTP 通信過程中，客戶端與服務(wù)器之間將完成下列7個(gè)步驟：

1）建立 TCP 連接：在HTTP工作開始之前，客戶端首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過 TCP 來(lái)完成的，該協(xié)議與 IP 協(xié)議共同構(gòu)建 Internet，即著名的 TCP/IP 協(xié)議族，因此 Internet 又被稱作是 TCP/IP 網(wǎng)絡(luò)。HTTP 是比 TCP 更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后，才能進(jìn)行高層協(xié)議的連接，因此，首先要建立 TCP 連接，一般 TCP 連接的端口號(hào)是80；

2）客戶端向服務(wù)器發(fā)送請(qǐng)求命令：一旦建立了TCP連接，客戶端就會(huì)向服務(wù)器發(fā)送請(qǐng)求命令；

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

3）客戶端發(fā)送請(qǐng)求頭信息：客戶端發(fā)送其請(qǐng)求命令之后，還要以頭信息的形式向服務(wù)器發(fā)送一些別的信息，之后客戶端發(fā)送了一空白行來(lái)通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送；

4）服務(wù)器應(yīng)答：客戶端向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器會(huì)客戶端返回響應(yīng)；

例如： HTTP/1.1 200 OK

響應(yīng)的第一部分是協(xié)議的版本號(hào)和響應(yīng)狀態(tài)碼；

5）服務(wù)器返回響應(yīng)頭信息：正如客戶端會(huì)隨同請(qǐng)求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會(huì)隨同響應(yīng)向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請(qǐng)求的文檔；

6）服務(wù)器向客戶端發(fā)送數(shù)據(jù)：服務(wù)器向客戶端發(fā)送頭信息后，它會(huì)發(fā)送一個(gè)空白行來(lái)表示頭信息的發(fā)送到此為結(jié)束，接著，它就以 Content-Type 響應(yīng)頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)；

7）服務(wù)器關(guān)閉 TCP 連接：一般情況下，一旦服務(wù)器向客戶端返回了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉 TCP 連接，然后如果客戶端或者服務(wù)器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 連接在發(fā)送后將仍然保持打開狀態(tài)，于是，客戶端可以繼續(xù)通過相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬。

7、HTTP 協(xié)議基礎(chǔ)

7.1 通過請(qǐng)求和響應(yīng)的交換達(dá)成通信

應(yīng)用 HTTP 協(xié)議時(shí)，必定是一端擔(dān)任客戶端角色，另一端擔(dān)任服務(wù)器端角色。僅從一條通信線路來(lái)說(shuō)，服務(wù)器端和客服端的角色是確定的。HTTP 協(xié)議規(guī)定，請(qǐng)求從客戶端發(fā)出，最后服務(wù)器端響應(yīng)該請(qǐng)求并返回。換句話說(shuō)，肯定是先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)。

7.2 HTTP 是不保存狀態(tài)的協(xié)議

HTTP 是一種無(wú)狀態(tài)協(xié)議。協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說(shuō)在 HTTP 這個(gè)級(jí)別，協(xié)議對(duì)于發(fā)送過的請(qǐng)求或響應(yīng)都不做持久化處理。這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的。

可是隨著 Web 的不斷發(fā)展，我們的很多業(yè)務(wù)都需要對(duì)通信狀態(tài)進(jìn)行保存。于是我們引入了 Cookie 技術(shù)。有了 Cookie 再用 HTTP 協(xié)議通信，就可以管理狀態(tài)了。

7.3 使用 Cookie 的狀態(tài)管理

Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來(lái)控制客戶端的狀態(tài)。Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的首部字段信息，通知客戶端保存Cookie。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出去。服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來(lái)的 Cookie 后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來(lái)的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。

Cookie 的流程：

7.4 請(qǐng)求 URI 定位資源

HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。

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

7.6 持久連接

HTTP 協(xié)議的初始版本中，每進(jìn)行一個(gè) HTTP 通信都要斷開一次 TCP 連接。比如使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)，在發(fā)送請(qǐng)求訪問 HTML 頁(yè)面資源的同時(shí)，也會(huì)請(qǐng)求該 HTML 頁(yè)面里包含的其他資源。因此，每次的請(qǐng)求都會(huì)造成無(wú)畏的 TCP 連接建立和斷開，增加通信量的開銷。

為了解決上述 TCP 連接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久連接的方法。其特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。旨在建立一次 TCP 連接后進(jìn)行多次請(qǐng)求和響應(yīng)的交互。在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接。

7.7 管線化

持久連接使得多數(shù)請(qǐng)求以管線化方式發(fā)送成為可能。以前發(fā)送請(qǐng)求后需等待并接收到響應(yīng)，才能發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后，不用等待亦可發(fā)送下一個(gè)請(qǐng)求。這樣就能做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。

比如，當(dāng)請(qǐng)求一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)，與挨個(gè)連接相比，用持久連接可以讓請(qǐng)求更快結(jié)束。而管線化技術(shù)要比持久連接速度更快。請(qǐng)求數(shù)越多，時(shí)間差就越明顯。

8、HTTP 協(xié)議報(bào)文結(jié)構(gòu)

8.1 HTTP 報(bào)文

用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文。請(qǐng)求端（客戶端）的 HTTP 報(bào)文叫做請(qǐng)求報(bào)文；響應(yīng)端（服務(wù)器端）的叫做響應(yīng)報(bào)文。HTTP 報(bào)文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本。

8.2 HTTP 報(bào)文結(jié)構(gòu)

HTTP 報(bào)文大致可分為報(bào)文首部和報(bào)文主體兩部分。兩者由最初出現(xiàn)的空行（CR+LF）來(lái)劃分。通常，并不一定有報(bào)文主體。

HTTP 報(bào)文結(jié)構(gòu)如下：

8.3 請(qǐng)求報(bào)文結(jié)構(gòu)

請(qǐng)求報(bào)文的首部?jī)?nèi)容由以下數(shù)據(jù)組成：

請(qǐng)求行 —— 包含用于請(qǐng)求的方法、請(qǐng)求 URI 和 HTTP 版本；

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

請(qǐng)求報(bào)文的示例，如下：

8.4 響應(yīng)報(bào)文結(jié)構(gòu)

響應(yīng)報(bào)文的首部?jī)?nèi)容由以下數(shù)據(jù)組成：

狀態(tài)行 —— 包含表明響應(yīng)結(jié)果的狀態(tài)碼、原因短語(yǔ)和 HTTP 版本；

首部字段 —— 包含表示請(qǐng)求的各種條件和屬性的各類首部。（通用首部、響應(yīng)首部、實(shí)體首部以及RFC里未定義的首部如 Cookie 等）。

響應(yīng)報(bào)文的示例，如下：

9、HTTP 報(bào)文首部之首部字段（重點(diǎn)分析）

9.1 首部字段概述

先來(lái)回顧一下首部字段在報(bào)文的位置，HTTP 報(bào)文包含報(bào)文首部和報(bào)文主體，報(bào)文首部包含請(qǐng)求行（或狀態(tài)行）和首部字段。

在報(bào)文眾多的字段當(dāng)中，HTTP 首部字段包含的信息最為豐富。首部字段同時(shí)存在于請(qǐng)求和響應(yīng)報(bào)文內(nèi)，并涵蓋 HTTP 報(bào)文相關(guān)的內(nèi)容信息。使用首部字段是為了給客服端和服務(wù)器端提供報(bào)文主體大小、所使用的語(yǔ)言、認(rèn)證信息等內(nèi)容。

9.2 首部字段結(jié)構(gòu)

HTTP 首部字段是由首部字段名和字段值構(gòu)成的，中間用冒號(hào)“：”分隔。

另外，字段值對(duì)應(yīng)單個(gè) HTTP 首部字段可以有多個(gè)值。

當(dāng) HTTP 報(bào)文首部中出現(xiàn)了兩個(gè)或以上具有相同首部字段名的首部字段時(shí)，這種情況在規(guī)范內(nèi)尚未明確，根據(jù)瀏覽器內(nèi)部處理邏輯的不同，優(yōu)先處理的順序可能不同，結(jié)果可能并不一致。

9.3首部字段類型

首部字段根據(jù)實(shí)際用途被分為以下4種類型：

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

9.5請(qǐng)求首部字段（HTTP/1.1）

9.6響應(yīng)首部字段（HTTP/1.1）

9.7實(shí)體首部字段（HTTP/1.1）

9.8為 Cookie 服務(wù)的首部字段

10、其他首部字段

HTTP 首部字段是可以自行擴(kuò)展的。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上，會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。以下是最為常用的首部字段。

X-Frame-Options：

X-Frame-Options: DENY 首部字段 X-Frame-Options 屬于 HTTP 響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標(biāo)簽內(nèi)的顯示問題。其主要目的是為了防止點(diǎn)擊劫持（clickjacking）攻擊。首部字段 X-Frame-Options 有以下兩個(gè)可指定的字段值：

DENY：拒絕；

SAMEORIGIN：僅同源域名下的頁(yè)面（Top-level-browsing-context）匹配時(shí)許可。（比如，當(dāng)指定 http://sample.com/sample.html 頁(yè)面為 SAMEORIGIN 時(shí)，那么 sample.com 上所有頁(yè)面的 frame 都被允許可加載該頁(yè)面，而 example.com 等其他域名的頁(yè)面就不行了）。

X-XSS-Protection：

X-XSS-Protection: 1 首部字段 X-XSS-Protection 屬于 HTTP 響應(yīng)首部，它是針對(duì)跨站腳本攻擊（XSS）的一種對(duì)策，用于控制瀏覽器 XSS 防護(hù)機(jī)制的開關(guān)。首部字段 X-XSS-Protection 可指定的字段值如下:

0 ：將 XSS 過濾設(shè)置成無(wú)效狀態(tài)

1 ：將 XSS 過濾設(shè)置成有效狀態(tài)

DNT：

DNT: 1 首部字段 DNT 屬于 HTTP 請(qǐng)求首部，其中 DNT 是 Do Not Track 的簡(jiǎn)稱，意為拒絕個(gè)人信息被收集，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下：

0 ：同意被追蹤

1 ：拒絕被追蹤

由于首部字段 DNT 的功能具備有效性，所以 Web 服務(wù)器需要對(duì) DNT做對(duì)應(yīng)的支持。

P3P：

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND 首部字段 P3P 屬于 HTTP 響應(yīng)首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺(tái)）技術(shù)，可以讓 Web 網(wǎng)站上的個(gè)人隱私變成一種僅供程序可理解的形式，以達(dá)到保護(hù)用戶隱私的目的。

要進(jìn)行 P3P 的設(shè)定，需按以下操作步驟進(jìn)行：

步驟 1：創(chuàng)建 P3P 隱私

步驟 2：創(chuàng)建 P3P 隱私對(duì)照文件后，保存命名在 /w3c/p3p.xml

步驟 3：從 P3P 隱私中新建 Compact policies 后，輸出到 HTTP 響應(yīng)中

11、HTTP 響應(yīng)狀態(tài)碼

消息

描述

100 Continue

服務(wù)器僅接收到部分請(qǐng)求，但是一旦服務(wù)器并沒有拒絕該請(qǐng)求，客戶端應(yīng)該繼續(xù)發(fā)送其余的請(qǐng)求。

101 Switching Protocols

服務(wù)器轉(zhuǎn)換協(xié)議：服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議。

消息

描述

200 OK

請(qǐng)求成功（其后是對(duì)GET和POST請(qǐng)求的應(yīng)答文檔。）

201 Created

請(qǐng)求被創(chuàng)建完成，同時(shí)新的資源被創(chuàng)建。

202 Accepted

供處理的請(qǐng)求已被接受，但是處理未完成。

203 Non-authoritative Information

文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確，因?yàn)槭褂玫氖俏臋n的拷貝。

204 No Content

沒有新文檔。瀏覽器應(yīng)該繼續(xù)顯示原來(lái)的文檔。如果用戶定期地刷新頁(yè)面，而Servlet可以確定用戶文檔足夠新，這個(gè)狀態(tài)代碼是很有用的。

205 Reset Content

沒有新文檔。但瀏覽器應(yīng)該重置它所顯示的內(nèi)容。用來(lái)強(qiáng)制瀏覽器清除表單輸入內(nèi)容。

206 Partial Content

客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求，服務(wù)器完成了它。

消息

描述

300 Multiple Choices

多重選擇。鏈接列表。用戶可以選擇某鏈接到達(dá)目的地。最多允許五個(gè)地址。

301 Moved Permanently

所請(qǐng)求的頁(yè)面已經(jīng)轉(zhuǎn)移至新的url。

302 Found

所請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)轉(zhuǎn)移至新的url。

303 See Other

所請(qǐng)求的頁(yè)面可在別的url下被找到。

304 Not Modified

未按預(yù)期修改文檔。客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。服務(wù)器告訴客戶，原來(lái)緩沖的文檔還可以繼續(xù)使用。

305 Use Proxy

客戶請(qǐng)求的文檔應(yīng)該通過Location頭所指明的代理服務(wù)器提取。

306 Unused

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

307 Temporary Redirect

被請(qǐng)求的頁(yè)面已經(jīng)臨時(shí)移至新的url。

消息

描述

400 Bad Request

服務(wù)器未能理解請(qǐng)求。

401 Unauthorized

被請(qǐng)求的頁(yè)面需要用戶名和密碼。

401.1

登錄失敗。

401.2

服務(wù)器配置導(dǎo)致登錄失敗。

401.3

由于 ACL 對(duì)資源的限制而未獲得授權(quán)。

401.4

篩選器授權(quán)失敗。

401.5

ISAPI/CGI 應(yīng)用程序授權(quán)失敗。

401.7

訪問被 Web 服務(wù)器上的 URL 授權(quán)策略拒絕。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

402 Payment Required

此代碼尚無(wú)法使用。

403 Forbidden

對(duì)被請(qǐng)求頁(yè)面的訪問被禁止。

403.1

執(zhí)行訪問被禁止。

403.2

讀訪問被禁止。

403.3

寫訪問被禁止。

403.4

要求 SSL。

403.5

要求 SSL 128。

403.6

IP 地址被拒絕。

403.7

要求客戶端證書。

403.8

站點(diǎn)訪問被拒絕。

403.9

用戶數(shù)過多。

403.10

配置無(wú)效。

403.11

密碼更改。

403.12

拒絕訪問映射表。

403.13

客戶端證書被吊銷。

403.14

拒絕目錄列表。

403.15

超出客戶端訪問許可。

403.16

客戶端證書不受信任或無(wú)效。

403.17

客戶端證書已過期或尚未生效。

403.18

在當(dāng)前的應(yīng)用程序池中不能執(zhí)行所請(qǐng)求的 URL。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

403.19

不能為這個(gè)應(yīng)用程序池中的客戶端執(zhí)行 CGI。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

403.20

Passport 登錄失敗。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

404 Not Found

服務(wù)器無(wú)法找到被請(qǐng)求的頁(yè)面。

404.0

（無(wú)）–沒有找到文件或目錄。

404.1

無(wú)法在所請(qǐng)求的端口上訪問 Web 站點(diǎn)。

404.2

Web 服務(wù)擴(kuò)展鎖定策略阻止本請(qǐng)求。

404.3

MIME 映射策略阻止本請(qǐng)求。

405 Method Not Allowed

請(qǐng)求中指定的方法不被允許。

406 Not Acceptable

服務(wù)器生成的響應(yīng)無(wú)法被客戶端所接受。

407 Proxy Authentication Required

用戶必須首先使用代理服務(wù)器進(jìn)行驗(yàn)證，這樣請(qǐng)求才會(huì)被處理。

408 Request Timeout

請(qǐng)求超出了服務(wù)器的等待時(shí)間。

409 Conflict

由于沖突，請(qǐng)求無(wú)法被完成。

410 Gone

被請(qǐng)求的頁(yè)面不可用。

411 Length Required

"Content-Length" 未被定義。如果無(wú)此內(nèi)容，服務(wù)器不會(huì)接受請(qǐng)求。

412 Precondition Failed

請(qǐng)求中的前提條件被服務(wù)器評(píng)估為失敗。

413 Request Entity Too Large

由于所請(qǐng)求的實(shí)體的太大，服務(wù)器不會(huì)接受請(qǐng)求。

414 Request-url Too Long

由于url太長(zhǎng)，服務(wù)器不會(huì)接受請(qǐng)求。當(dāng)post請(qǐng)求被轉(zhuǎn)換為帶有很長(zhǎng)的查詢信息的get請(qǐng)求時(shí)，就會(huì)發(fā)生這種情況。

415 Unsupported Media Type

由于媒介類型不被支持，服務(wù)器不會(huì)接受請(qǐng)求。

416 Requested Range Not Satisfiable

服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭。

417 Expectation Failed

執(zhí)行失敗。

423

鎖定的錯(cuò)誤。

消息

描述

500 Internal Server Error

請(qǐng)求未完成。服務(wù)器遇到不可預(yù)知的情況。

500.12

應(yīng)用程序正忙于在 Web 服務(wù)器上重新啟動(dòng)。

500.13

Web 服務(wù)器太忙。

500.15

不允許直接請(qǐng)求 Global.asa。

500.16

UNC 授權(quán)憑據(jù)不正確。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

500.18

URL 授權(quán)存儲(chǔ)不能打開。這個(gè)錯(cuò)誤代碼為 IIS 6.0 所專用。

500.100

內(nèi)部 ASP 錯(cuò)誤。

501 Not Implemented

請(qǐng)求未完成。服務(wù)器不支持所請(qǐng)求的功能。

502 Bad Gateway

請(qǐng)求未完成。服務(wù)器從上游服務(wù)器收到一個(gè)無(wú)效的響應(yīng)。

502.1

CGI 應(yīng)用程序超時(shí)?！?#183;

502.2

CGI 應(yīng)用程序出錯(cuò)。

503 Service Unavailable

請(qǐng)求未完成。服務(wù)器臨時(shí)過載或當(dāng)機(jī)。

504 Gateway Timeout

網(wǎng)關(guān)超時(shí)。

505 HTTP Version Not Supported

服務(wù)器不支持請(qǐng)求中指明的HTTP協(xié)議版本。

12、HTTP 報(bào)文實(shí)體

12.1HTTP 報(bào)文實(shí)體概述

大家請(qǐng)仔細(xì)看看上面示例中，各個(gè)組成部分對(duì)應(yīng)的內(nèi)容。

接著，我們來(lái)看看報(bào)文和實(shí)體的概念。如果把 HTTP 報(bào)文想象成因特網(wǎng)貨運(yùn)系統(tǒng)中的箱子，那么 HTTP 實(shí)體就是報(bào)文中實(shí)際的貨物。

報(bào)文：是網(wǎng)絡(luò)中交換和傳輸?shù)臄?shù)據(jù)單元，即站點(diǎn)一次性要發(fā)送的數(shù)據(jù)塊。報(bào)文包含了將要發(fā)送的完整的數(shù)據(jù)信息，其長(zhǎng)短很不一致，長(zhǎng)度不限且可變；

實(shí)體：作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項(xiàng)）被傳輸，其內(nèi)容由實(shí)體首部和實(shí)體主體組成。（實(shí)體首部相關(guān)內(nèi)容在上面第六點(diǎn)中已有闡述。）

我們可以看到，上面示例右圖中深紅色框的內(nèi)容就是報(bào)文的實(shí)體部分，而藍(lán)色框的兩部分內(nèi)容分別就是實(shí)體首部和實(shí)體主體。而左圖中粉紅框內(nèi)容就是報(bào)文主體。

通常，報(bào)文主體等于實(shí)體主體。只有當(dāng)傳輸中進(jìn)行編碼操作時(shí)，實(shí)體主體的內(nèi)容發(fā)生變化，才導(dǎo)致它和報(bào)文主體產(chǎn)生差異。

12.2內(nèi)容編碼

HTTP 應(yīng)用程序有時(shí)在發(fā)送之前需要對(duì)內(nèi)容進(jìn)行編碼。例如，在把很大的 HTML 文檔發(fā)送給通過慢速連接上來(lái)的客戶端之前，服務(wù)器可能會(huì)對(duì)其進(jìn)行壓縮，這樣有助于減少傳輸實(shí)體的時(shí)間。服務(wù)器還可以把內(nèi)容攪亂或加密，以此來(lái)防止未授權(quán)的第三方看到文檔的內(nèi)容。

這種類型的編碼是在發(fā)送方應(yīng)用到內(nèi)容之上的。當(dāng)內(nèi)容經(jīng)過內(nèi)容編碼后，編好碼的數(shù)據(jù)就放在實(shí)體主體中，像往常一樣發(fā)送給接收方。

內(nèi)容編碼類型：

12.3傳輸編碼

內(nèi)容編碼是對(duì)報(bào)文的主體進(jìn)行的可逆變換，是和內(nèi)容的具體格式細(xì)節(jié)緊密相關(guān)的。

傳輸編碼也是作用在實(shí)體主體上的可逆變換，但使用它們是由于架構(gòu)方面的原因，同內(nèi)容的格式無(wú)關(guān)。使用傳輸編碼是為了改變報(bào)文中的數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)姆绞健?/p>

12.4分塊編碼

分塊編碼把報(bào)文分割成若干已知大小的塊。塊之間是緊挨著發(fā)送的，這樣就不需要在發(fā)送之前知道整個(gè)報(bào)文的大小了。分塊編碼是一種傳輸編碼，是報(bào)文的屬性。

若客戶端與服務(wù)器端之間不是持久連接，客戶端就不需要知道它在讀取的主體的長(zhǎng)度，而只需要讀取到服務(wù)器關(guān)閉主體連接為止。

當(dāng)使用持久連接時(shí)，在服務(wù)器寫主體之前，必須知道它的大小并在 Content-Length 首部中發(fā)送。如果服務(wù)器動(dòng)態(tài)創(chuàng)建內(nèi)容，就可能在發(fā)送之前無(wú)法知道主體的長(zhǎng)度。

分塊編碼為這種困難提供了解決方案，只要允許服務(wù)器把主體分塊發(fā)送，說(shuō)明每塊的大小就可以了。因?yàn)橹黧w是動(dòng)態(tài)創(chuàng)建的，服務(wù)器可以緩沖它的一部分，發(fā)送其大小和相應(yīng)的塊，然后在主體發(fā)送完之前重復(fù)這個(gè)過程。服務(wù)器可以用大小為 0 的塊作為主體結(jié)束的信號(hào)，這樣就可以繼續(xù)保持連接，為下一個(gè)響應(yīng)做準(zhǔn)備。

來(lái)看看一個(gè)分塊編碼的報(bào)文示例：

12.5多部分媒體類型

MIME 中的 multipart（多部分）電子郵件報(bào)文中包含多個(gè)報(bào)文，它們合在一起作為單一的復(fù)雜報(bào)文發(fā)送。每一部分都是獨(dú)立的，有各自的描述其內(nèi)容的集，不同部分之間用分界字符串連接在一起。

相應(yīng)得，HTTP 協(xié)議中也采納了多部分對(duì)象集合，發(fā)送的一份報(bào)文主體內(nèi)可包含多種類型實(shí)體。

多部分對(duì)象集合包含的對(duì)象如下：

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

multipart/byteranges：狀態(tài)碼 206 Partial Content 響應(yīng)報(bào)文包含了多個(gè)范圍的內(nèi)容時(shí)使用。

12.6范圍請(qǐng)求

假設(shè)你正在下載一個(gè)很大的文件，已經(jīng)下了四分之三，忽然網(wǎng)絡(luò)中斷了，那下載就必須重頭再來(lái)一遍。為了解決這個(gè)問題，需要一種可恢復(fù)的機(jī)制，即能從之前下載中斷處恢復(fù)下載。要實(shí)現(xiàn)該功能，這就要用到范圍請(qǐng)求。

有了范圍請(qǐng)求， HTTP 客戶端可以通過請(qǐng)求曾獲取失敗的實(shí)體的一個(gè)范圍（或者說(shuō)一部分），來(lái)恢復(fù)下載該實(shí)體。當(dāng)然這有一個(gè)前提，那就是從客戶端上一次請(qǐng)求該實(shí)體到這一次發(fā)出范圍請(qǐng)求的時(shí)間段內(nèi)，該對(duì)象沒有改變過。例如：

GET  /bigfile.html  HTTP/1.1

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

Range: bytes=20224-

···

上面示例中，客戶端請(qǐng)求的是文檔開頭20224字節(jié)之后的部分。

13、與 HTTP 協(xié)作的 Web 服務(wù)器

HTTP 通信時(shí)，除客戶端和服務(wù)器外，還有一些用于協(xié)助通信的應(yīng)用程序。如下列出比較重要的幾個(gè)：代理、緩存、網(wǎng)關(guān)、隧道、Agent 代理。

13.1代理

HTTP 代理服務(wù)器是 Web 安全、應(yīng)用集成以及性能優(yōu)化的重要組成模塊。代理位于客戶端和服務(wù)器端之間，接收客戶端所有的 HTTP 請(qǐng)求，并將這些請(qǐng)求轉(zhuǎn)發(fā)給服務(wù)器（可能會(huì)對(duì)請(qǐng)求進(jìn)行修改之后再進(jìn)行轉(zhuǎn)發(fā)）。對(duì)用戶來(lái)說(shuō)，這些應(yīng)用程序就是一個(gè)代理，代表用戶訪問服務(wù)器。

出于安全考慮，通常會(huì)將代理作為轉(zhuǎn)發(fā)所有 Web 流量的可信任中間節(jié)點(diǎn)使用。代理還可以對(duì)請(qǐng)求和響應(yīng)進(jìn)行過濾，安全上網(wǎng)或綠色上網(wǎng)。

13.2緩存

瀏覽器第一次請(qǐng)求：

瀏覽器再次請(qǐng)求：

Web 緩存或代理緩存是一種特殊的 HTTP 代理服務(wù)器，可以將經(jīng)過代理傳輸?shù)某Ｓ梦臋n復(fù)制保存起來(lái)。下一個(gè)請(qǐng)求同一文檔的客戶端就可以享受緩存的私有副本所提供的服務(wù)了。客戶端從附近的緩存下載文檔會(huì)比從遠(yuǎn)程 Web 服務(wù)器下載快得多。

13.3網(wǎng)關(guān)

網(wǎng)關(guān)是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實(shí)體使用。通常用于將 HTTP 流量轉(zhuǎn)換成其他的協(xié)議。網(wǎng)關(guān)接收請(qǐng)求時(shí)就好像自己是資源的源服務(wù)器一樣。客戶端可能并不知道自己正在跟一個(gè)網(wǎng)關(guān)進(jìn)行通信。

13.4隧道

隧道是會(huì)在建立起來(lái)之后，就會(huì)在兩條連接之間對(duì)原始數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)的 HTTP 應(yīng)用程序。HTTP 隧道通常用來(lái)在一條或多條 HTTP 連接上轉(zhuǎn)發(fā)非 HTTP 數(shù)據(jù)，轉(zhuǎn)發(fā)時(shí)不會(huì)窺探數(shù)據(jù)。

HTTP 隧道的一種常見用途就是通過 HTTP 連接承載加密的安全套接字層（SSL）流量，這樣 SSL 流量就可以穿過只允許 Web 流量通過的防火墻了。

13.5Agent 代理

Agent 代理是代表用戶發(fā)起 HTTP 請(qǐng)求的客戶端應(yīng)用程序。所有發(fā)布 Web 請(qǐng)求的應(yīng)用程序都是 HTTP Agent 代理。

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

附錄：更多網(wǎng)絡(luò)編程資料

《技術(shù)往事：改變世界的TCP/IP協(xié)議（珍貴多圖、手機(jī)慎點(diǎn)）》

《UDP中一個(gè)包的大小最大能多大？》

《Java新一代網(wǎng)絡(luò)編程模型AIO原理及Linux系統(tǒng)AIO介紹》

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

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

《NIO框架入門(三)：iOS與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》

《NIO框架入門(四)：Android與MINA2、Netty4的跨平臺(tái)UDP雙向通信實(shí)戰(zhàn)》

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡(jiǎn)介》

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

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

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

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-1677-1-1.html）