這篇文章比較長(zhǎng)，大家用思維導(dǎo)圖來(lái)預(yù)習(xí)一下。

一.概述

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

2.TCP/IP通信傳輸流

當(dāng)使用TCP/IP協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí)，會(huì)通過(guò)分層序列相互通信。發(fā)送方從應(yīng)用層往下走，接收方從鏈路層往上走。如下:

通信傳輸流

首先作為發(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ā)送過(guò)來(lái)的 HTTP請(qǐng)求。

如下圖所示:

httpqueryinfo

在網(wǎng)絡(luò)架構(gòu)中，有很多網(wǎng)絡(luò)協(xié)議。本文主要圍繞HTTP協(xié)議(HTTP/1.1版)展開(kāi)。

超文本傳輸協(xié)議是一種將超文本從萬(wàn)維網(wǎng)服務(wù)器傳輸?shù)奖镜貫g覽器的傳輸協(xié)議?？梢允篂g覽器更高效，減少網(wǎng)絡(luò)傳輸。它不僅保證了計(jì)算機(jī)正確、快速地傳輸超文本文檔，而且確定了傳輸文檔的哪一部分和內(nèi)容的哪一部分先顯示(如文字后圖形)。

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

我們?cè)跒g覽器地址欄輸入的網(wǎng)址叫做URL(統(tǒng)一資源定位符)。就像每個(gè)家庭都有一個(gè)家庭地址，所以每個(gè)網(wǎng)頁(yè)都有一個(gè)互聯(lián)網(wǎng)地址。當(dāng)您在瀏覽器的地址框中輸入網(wǎng)址或單擊超鏈接時(shí)，網(wǎng)址將決定要瀏覽的地址。瀏覽器通過(guò)超文本傳輸協(xié)議(HTTP)在Web服務(wù)器上提取網(wǎng)站的網(wǎng)頁(yè)代碼，并翻譯成漂亮的網(wǎng)頁(yè)。

二、HTTP工作流程

HTTP通信機(jī)制是在一個(gè)完整的HTTP通信過(guò)程中，客戶端和服務(wù)器之間將完成以下七個(gè)步驟:

建立 TCP 連接 在HTTP工作開(kāi)始之前，客戶端首先要通過(guò)網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過(guò) TCP 來(lái)完成的，該協(xié)議與 IP 協(xié)議共同構(gòu)建 Internet，即著名的 TCP/IP 協(xié)議族，因此 Internet 又被稱(chēng)作是 TCP/IP 網(wǎng)絡(luò)。HTTP 是比 TCP 更高層次的應(yīng)用層協(xié)議，根據(jù)規(guī)則，只有低層協(xié)議建立之后，才能進(jìn)行高層協(xié)議的連接，因此，首先要建立 TCP 連接，一般 TCP 連接的端口號(hào)是80；客戶端向服務(wù)器發(fā)送請(qǐng)求命令 一旦建立了TCP連接，客戶端就會(huì)向服務(wù)器發(fā)送請(qǐng)求命令； 例如：GET/sample/hello.jsp HTTP/1.1客戶端發(fā)送請(qǐng)求頭信息 客戶端發(fā)送其請(qǐng)求命令之后，還要以頭信息的形式向服務(wù)器發(fā)送一些別的信息，之后客戶端發(fā)送了一空白行來(lái)通知服務(wù)器，它已經(jīng)結(jié)束了該頭信息的發(fā)送；服務(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)碼服務(wù)器返回響應(yīng)頭信息 正如客戶端會(huì)隨同請(qǐng)求發(fā)送關(guān)于自身的信息一樣，服務(wù)器也會(huì)隨同響應(yīng)向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請(qǐng)求的文檔；服務(wù)器向客戶端發(fā)送數(shù)據(jù) 服務(wù)器向客戶端發(fā)送頭信息后，它會(huì)發(fā)送一個(gè)空白行來(lái)表示頭信息的發(fā)送到此為結(jié)束，接著，它就以 Content-Type 響應(yīng)頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)；服務(wù)器關(guān)閉 TCP 連接 一般情況下，一旦服務(wù)器向客戶端返回了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉 TCP 連接，然后如果客戶端或者服務(wù)器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 連接在發(fā)送后將仍然保持打開(kāi)狀態(tài)，于是，客戶端可以繼續(xù)通過(guò)相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間，還節(jié)約了網(wǎng)絡(luò)帶寬。

第三，HTTP協(xié)議基礎(chǔ)

1.通過(guò)交換請(qǐng)求和響應(yīng)進(jìn)行交流

應(yīng)用HTTP協(xié)議時(shí)，一端必須扮演客戶端的角色，另一端扮演服務(wù)器的角色。僅從一條通信線路來(lái)看，服務(wù)器和客戶服務(wù)的角色是確定的。按照HTTP協(xié)議，請(qǐng)求從客戶端發(fā)出，最后服務(wù)器響應(yīng)請(qǐng)求返回。換句話說(shuō)，必須首先從客戶端建立通信，服務(wù)器在收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)。

2.HTTP是一種不保存狀態(tài)的協(xié)議

HTTP是無(wú)狀態(tài)協(xié)議。協(xié)議本身不保存請(qǐng)求和響應(yīng)之間的通信狀態(tài)。也就是說(shuō)，在HTTP級(jí)別，協(xié)議不持久保存發(fā)送的請(qǐng)求或響應(yīng)。這是為了更快的處理大量事務(wù)，保證協(xié)議的可擴(kuò)展性，而HTTP協(xié)議就是專(zhuān)門(mén)設(shè)計(jì)的這么簡(jiǎn)單。

然而，隨著網(wǎng)絡(luò)的不斷發(fā)展，我們的許多業(yè)務(wù)都需要保存通信狀態(tài)。于是我們引入了Cookie技術(shù)。通過(guò)Cookie和HTTP協(xié)議通信，可以管理狀態(tài)。

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

Cookie技術(shù)通過(guò)在請(qǐng)求和響應(yīng)消息中寫(xiě)入Cookie信息來(lái)控制客戶端的狀態(tài)。Cookie將根據(jù)服務(wù)器發(fā)送的響應(yīng)消息中稱(chēng)為設(shè)置Cookie的報(bào)頭字段信息通知客戶端保存Cookie。下次客戶端向服務(wù)器發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)將Cookie值添加到請(qǐng)求消息中并發(fā)送出去。當(dāng)服務(wù)器找到客戶端發(fā)送的Cookie時(shí)，會(huì)檢查是哪個(gè)客戶端發(fā)送的連接請(qǐng)求，然后比較服務(wù)器上的記錄，最后得到之前的狀態(tài)信息。

4.請(qǐng)URI找到資源

HTTP協(xié)議使用URIs定位互聯(lián)網(wǎng)上的資源。由于URIs的特殊功能，可以在互聯(lián)網(wǎng)上的任何地方訪問(wèn)資源。

5.告知服務(wù)器意圖的HTTP方法(HTTP/1.1)

6.持久連接

在HTTP協(xié)議的初始版本中，每次HTTP通信都應(yīng)該斷開(kāi)一次TCP連接。例如，當(dāng)使用瀏覽器瀏覽包含多個(gè)圖片的HTML頁(yè)面時(shí)，當(dāng)您發(fā)送訪問(wèn)HTML頁(yè)面資源的請(qǐng)求時(shí)，您也會(huì)請(qǐng)求HTML頁(yè)面中包含的其他資源。所以每一個(gè)請(qǐng)求都會(huì)造成無(wú)畏的TCP連接建立和斷開(kāi)，增加流量開(kāi)銷(xiāo)。

為了解決以上TCP連接問(wèn)題，HTTP/1.1和一些HTTP/1.0都想出了持久連接的方法。其特征在于，只要任一端沒(méi)有明確提出斷開(kāi)，TCP連接狀態(tài)就保持不變。它設(shè)計(jì)用于在建立TCP連接后與多個(gè)請(qǐng)求和響應(yīng)進(jìn)行交互。在HTTP/1.1中，默認(rèn)情況下所有連接都是持久的。

7.管道

持久連接使得大多數(shù)請(qǐng)求能夠以流水線方式發(fā)送。在發(fā)送請(qǐng)求之前，您需要等待并收到響應(yīng)，然后再發(fā)送下一個(gè)請(qǐng)求。流水線技術(shù)出現(xiàn)后，下一個(gè)請(qǐng)求不用等待就可以發(fā)送。這樣可以同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不是一個(gè)個(gè)等待響應(yīng)。

例如，當(dāng)請(qǐng)求包含多個(gè)圖片的HTML頁(yè)面時(shí)，使用持久連接可以使請(qǐng)求比逐個(gè)連接更快結(jié)束。管道技術(shù)比持久連接更快。請(qǐng)求越多，時(shí)間差越明顯。

第四，HTTP協(xié)議的消息結(jié)構(gòu)

1.HTTP消息

用于HTTP協(xié)議交互的信息稱(chēng)為HTTP消息。請(qǐng)求端(客戶端)的HTTP消息稱(chēng)為請(qǐng)求消息；響應(yīng)端(服務(wù)器端)稱(chēng)為響應(yīng)消息。HTTP消息本身是由多行數(shù)據(jù)組成的字符串文本(使用CR+LF作為換行符)。

2.HTTP消息結(jié)構(gòu)

HTTP消息大致可以分為消息頭和消息體。它們被第一條空線分開(kāi)(CR+LF)。一般不一定有消息體。如下:

2.1請(qǐng)求消息結(jié)構(gòu)

請(qǐng)求消息的報(bào)頭內(nèi)容由以下數(shù)據(jù)組成:

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

請(qǐng)求消息的示例如下:

2.2響應(yīng)消息結(jié)構(gòu)

響應(yīng)消息的報(bào)頭內(nèi)容由以下數(shù)據(jù)組成:

狀態(tài)行 —— 包含表明響應(yīng)結(jié)果的狀態(tài)碼、原因短語(yǔ)和 HTTP 版本。首部字段 —— 包含表示請(qǐng)求的各種條件和屬性的各類(lèi)首部。（通用首部、響應(yīng)首部、實(shí)體首部以及RFC里未定義的首部如 Cookie 等）

響應(yīng)消息的示例如下:

5.HTTP消息頭的請(qǐng)求行和狀態(tài)行

1.請(qǐng)求行

例如，下面是一條HTTP請(qǐng)求消息:

GET /index.htm HTTP/1.1

主持人:sample.com

其中，下面一行是請(qǐng)求行。

GET/index.htm HTTP/ 1。一

開(kāi)頭的 GET 表示請(qǐng)求訪問(wèn)服務(wù)器的類(lèi)型，稱(chēng)為方法；隨后的字符串 /index.htm 指明了請(qǐng)求訪問(wèn)的資源對(duì)象，也叫做請(qǐng)求 URI；最后的 HTTP/1.1，即 HTTP 的版本號(hào)，用來(lái)提示客戶端使用的 HTTP 協(xié)議功能。

總的來(lái)說(shuō)，就是在一個(gè)HTTP服務(wù)器上請(qǐng)求訪問(wèn)/index.htm頁(yè)面資源。

2.狀態(tài)行

還舉個(gè)栗子，下面是一條HTTP響應(yīng)消息:

HTTP/1.1 200 OK

日期:2017年7月10日星期一格林尼治時(shí)間15:50:06

內(nèi)容-長(zhǎng)度:256

內(nèi)容類(lèi)型:文本/html

& lthtml>。

...

其中，下面一行是狀態(tài)行。

HTTP/1.1 200OK

開(kāi)頭的 HTTP/1.1 表示服務(wù)器對(duì)應(yīng)的 HTTP 版本；緊挨著的 200 OK 表示請(qǐng)求的處理結(jié)果的狀態(tài)碼和原因短語(yǔ)。

不及物動(dòng)詞HTTP消息頭的頭字段(重點(diǎn)分析)

1.標(biāo)題字段概述

首先，檢查郵件中標(biāo)題字段的位置。HTTP消息包含一個(gè)消息頭和一個(gè)消息體。消息標(biāo)題包含一個(gè)請(qǐng)求行(或狀態(tài)行)和一個(gè)標(biāo)題字段。

在眾多的消息字段中，HTTP頭字段包含了最豐富的信息。標(biāo)頭字段存在于請(qǐng)求和響應(yīng)消息中，涵蓋了與HTTP消息相關(guān)的內(nèi)容信息。標(biāo)頭字段用于向客戶服務(wù)和服務(wù)器提供消息正文大小、使用的語(yǔ)言、身份驗(yàn)證信息和其他內(nèi)容。

2.標(biāo)題字段結(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é)果可能并不一致。 首部字段名冒號(hào)字段值Content-Type：text/htmlKeep-Alive：timeout=30, max=120

3.標(biāo)題字段類(lèi)型

根據(jù)實(shí)際用途，標(biāo)題字段分為以下四種類(lèi)型:

類(lèi)型描述通用首部字段請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部請(qǐng)求首部字段從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部。補(bǔ)充了請(qǐng)求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級(jí)等信息響應(yīng)首部字段從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會(huì)要求客戶端附加額外的內(nèi)容信息。實(shí)體首部字段針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的的信息。

4.通用報(bào)頭字段(HTTP/1.1)

首部字段名說(shuō)明Cache-Control控制緩存的行為Connection逐挑首部、連接的管理Date創(chuàng)建報(bào)文的日期時(shí)間Pragma報(bào)文指令Trailer報(bào)文末端的首部一覽Transfer-Encoding指定報(bào)文主體的傳輸編碼方式Upgrade升級(jí)為其他協(xié)議Via代理服務(wù)器的相關(guān)信息Warning錯(cuò)誤通知

4.1緩存控制

緩存的工作機(jī)制可以通過(guò)指定頭字段緩存控制的指令來(lái)操作。

4.1.1可用說(shuō)明列表

可用指令按請(qǐng)求和響應(yīng)分類(lèi)如下:

緩存請(qǐng)求指令

指令參數(shù)說(shuō)明no-cache無(wú)強(qiáng)制向服務(wù)器再次驗(yàn)證no-store無(wú)不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容max-age = [秒]必需響應(yīng)的最大Age值max-stale( =[秒])可省略接收已過(guò)期的響應(yīng)min-fresh = [秒]必需期望在指定時(shí)間內(nèi)的響應(yīng)仍有效no-transform無(wú)代理不可更改媒體類(lèi)型only-if-cached無(wú)從緩存獲取資源cache-extension-新指令標(biāo)記（token）

緩存響應(yīng)指令

指令參數(shù)說(shuō)明public無(wú)可向任意方提供響應(yīng)的緩存private可省略僅向特定用戶返回響應(yīng)no-cache可省略緩存前必須先確認(rèn)其有效性no-store無(wú)不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容no-transform無(wú)代理不可更改媒體類(lèi)型must-revalidate無(wú)可緩存但必須再向源服務(wù)器進(jìn)行確認(rèn)proxy-revalidate無(wú)要求中間緩存服務(wù)器對(duì)緩存的響應(yīng)有效性再進(jìn)行確認(rèn)max-age = [秒]必需響應(yīng)的最大Age值s-maxage = [秒]必需公共緩存服務(wù)器響應(yīng)的最大Age值cache-extension-新指令標(biāo)記（token） 4.1.2 表示能否緩存的指令

公共指令

緩存控制:公共

當(dāng)公共指令被指定時(shí)，它清楚地表明其他用戶也可以使用緩存。

私人指令

緩存控制:私有

當(dāng)指定私有指令時(shí)，響應(yīng)只以特定用戶為對(duì)象，這與公共指令的行為相反。緩存服務(wù)器將為該特定用戶提供資源緩存服務(wù)，代理服務(wù)器不會(huì)為其他用戶發(fā)送的請(qǐng)求返回緩存。

無(wú)緩存指令

緩存控制:無(wú)緩存

使用 no-cache 指令是為了防止從緩存中返回過(guò)期的資源。 客戶端發(fā)送的請(qǐng)求中如果包含 no-cache 指令，則表示客戶端將不會(huì)接收緩存過(guò)的響應(yīng)。于是，“中間”的緩存服務(wù)器必須把客戶端請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。 如果服務(wù)器中返回的響應(yīng)包含 no-cache 指令，那么緩存服務(wù)器不能對(duì)資源進(jìn)行緩存。源服務(wù)器以后也將不再對(duì)緩存服務(wù)器請(qǐng)求中提出的資源有效性進(jìn)行確認(rèn)，且禁止其對(duì)響應(yīng)資源進(jìn)行緩存操作。

緩存控制:無(wú)緩存=位置

在服務(wù)器返回的響應(yīng)中，如果在頭字段Cache-Control中用參數(shù)值指定了無(wú)緩存字段名，則客戶端在收到與指定參數(shù)值的頭字段對(duì)應(yīng)的響應(yīng)消息后，無(wú)法使用緩存。換句話說(shuō)，沒(méi)有參數(shù)值的頭字段可以使用緩存。該參數(shù)只能在響應(yīng)指令中指定。

無(wú)存儲(chǔ)指令

緩存控制:無(wú)存儲(chǔ)

當(dāng)使用無(wú)存儲(chǔ)指令時(shí)，它意味著請(qǐng)求(和相應(yīng)的響應(yīng))或響應(yīng)包含機(jī)密信息。因此，該指令指定緩存不能在本地存儲(chǔ)請(qǐng)求或響應(yīng)的任何部分。

注意:無(wú)緩存指令是指不緩存過(guò)期指令，緩存會(huì)在向源服務(wù)器確認(rèn)有效期后處理資源；無(wú)存儲(chǔ)指令真的不緩存。

4.1.3指定緩存周期和身份驗(yàn)證的說(shuō)明

S-maxage指令

緩存控制:s-maxage=604800(單位:秒)

s-maxage 指令的功能和 max-age 指令的相同，它們的不同點(diǎn)是 s-maxage 指令只適用于供多位用戶使用的公共緩存服務(wù)器（一般指代理）。也就是說(shuō)，對(duì)于向同一用戶重復(fù)返回響應(yīng)的服務(wù)器來(lái)說(shuō)，這個(gè)指令沒(méi)有任何作用。 另外，當(dāng)使用 s-maxage 指令后，則直接忽略對(duì) Expires 首部字段及 max-age 指令的處理。

最大年齡指令

緩存控制:最大年齡= 604800(單位:秒)

當(dāng)客戶端發(fā)送的請(qǐng)求中包含 max-age 指令時(shí)，如果判定緩存資源的緩存時(shí)間數(shù)值比指定的時(shí)間更小，那么客戶端就接收緩存的資源。另外，當(dāng)指定 max-age 的值為0，那么緩存服務(wù)器通常需要將請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。 當(dāng)服務(wù)器返回的響應(yīng)中包含 max-age 指令時(shí)，緩存服務(wù)器將不對(duì)資源的有效性再作確認(rèn)，而 max-age 數(shù)值代表資源保存為緩存的最長(zhǎng)時(shí)間。 應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時(shí)存在 Expires 首部字段的情況時(shí)，會(huì)優(yōu)先處理 max-age 指令，并忽略掉 Expires 首部字段；而 HTTP/1.0 版本的緩存服務(wù)器則相反。

最低新鮮指示

緩存控制:最小刷新= 60(單位:秒)

min-fresh指令要求緩存服務(wù)器至少返回未超過(guò)指定時(shí)間的緩存資源。

最大陳舊指令

緩存控制:最大延遲= 3600(單位:秒)

使用 max-stale 可指示緩存資源，即使過(guò)期也照常接收。 如果指令未指定參數(shù)值，那么無(wú)論經(jīng)過(guò)多久，客戶端都會(huì)接收響應(yīng)；如果指定了具體參數(shù)值，那么即使過(guò)期，只要仍處于 max-stale 指定的時(shí)間內(nèi)，仍舊會(huì)被客戶端接收。

僅當(dāng)緩存指令

緩存控制:僅當(dāng)緩存時(shí)

指示如果目標(biāo)資源由緩存服務(wù)器本地緩存，客戶端將僅要求目標(biāo)資源返回。換句話說(shuō)，該指令要求緩存服務(wù)器不要重新加載響應(yīng)或重新確認(rèn)資源的有效性。

必須更新的指令

緩存控制:必須重新驗(yàn)證

使用必須更新指令，代理再次向源服務(wù)器驗(yàn)證要返回的響應(yīng)緩存目前是否仍然有效。此外，使用必須更新指令會(huì)忽略所請(qǐng)求的最大過(guò)期指令。

代理更新命令

緩存控制:代理-重新驗(yàn)證

代理更新指令要求所有緩存服務(wù)器在接收到來(lái)自客戶端請(qǐng)求的指令響應(yīng)之前，再次驗(yàn)證緩存的有效性。

無(wú)轉(zhuǎn)換命令

緩存控制:無(wú)轉(zhuǎn)換

使用非轉(zhuǎn)換指令指定緩存不能在請(qǐng)求或響應(yīng)中更改實(shí)體主體的媒體類(lèi)型。這樣做可以防止圖片的緩存或代理壓縮以及其他類(lèi)似操作。

4.1.4緩存控制的擴(kuò)展

緩存控制:私有，社區(qū)=“UCI”

使用緩存擴(kuò)展標(biāo)記，可以擴(kuò)展緩存控制頭字段中的指令。上面提到的社區(qū)指令是一個(gè)擴(kuò)展指令，如果緩存服務(wù)器無(wú)法理解這個(gè)新指令，就會(huì)直接忽略。

4.2連接

連接頭字段有以下兩個(gè)功能:

控制不再轉(zhuǎn)發(fā)的報(bào)頭字段

連接:升級(jí)

在客戶端發(fā)送的請(qǐng)求和服務(wù)器返回的響應(yīng)中，連接頭字段可以用來(lái)控制不再轉(zhuǎn)發(fā)給代理的頭字段，即在轉(zhuǎn)發(fā)前刪除(即逐跳頭)。

管理持久連接

連接:關(guān)閉連接:關(guān)閉

HTTP/1.1中的默認(rèn)連接是持久連接。當(dāng)服務(wù)器想要顯式斷開(kāi)連接時(shí)，連接頭字段的值被指定為關(guān)閉。

連接:保持活力

HTTP/1.1之前的HTTP版本默認(rèn)連接都是非持久連接。因此，如果您想在舊版本的HTTP協(xié)議上保持連續(xù)的連接，您需要將連接頭字段的值指定為保持活動(dòng)。

4.3日期

指示創(chuàng)建HTTP消息的日期和時(shí)間。

日期:2017年7月10日星期一15:50:06格林尼治時(shí)間

HTTP/1.1協(xié)議使用RFC1123中指定的日期和時(shí)間格式。

4.4 Pragma

Pragma頭字段是HTTP/1.1之前的歷史遺留字段，僅定義為與HTTP/1.0向后兼容。

Pragma:無(wú)緩存

該首部字段屬于通用首部字段，但只用在客戶端發(fā)送的請(qǐng)求中，要求所有的中間服務(wù)器不返回緩存的資源。 所有的中間服務(wù)器如果都能以 HTTP/1.1 為基準(zhǔn)，那直接采用 Cache-Control: no-cache 指定緩存的處理方式最為理想。但是要整體掌握所有中間服務(wù)器使用的 HTTP 協(xié)議版本卻是不現(xiàn)實(shí)的，所以，發(fā)送的請(qǐng)求會(huì)同時(shí)包含下面兩個(gè)首部字段：

緩存控制:無(wú)緩存

Pragma:無(wú)緩存

4.5拖車(chē)

預(yù)告片:過(guò)期

報(bào)頭字段“尾部”將提前解釋哪些報(bào)頭字段記錄在消息正文之后?？梢詰?yīng)用于HTTP/1.1版的塊傳輸編碼。

4.6傳輸編碼

傳輸編碼:分塊

規(guī)定了傳輸報(bào)文主體時(shí)采用的編碼方式。 HTTP/1.1 的傳輸編碼方式僅對(duì)分塊傳輸編碼有效。

4.7升級(jí)

升級(jí):TSL/1.0

用于檢測(cè)HTTP協(xié)議和其他協(xié)議是否可以與更高版本通信，其參數(shù)值可以用來(lái)指定完全不同的通信協(xié)議。

4.8通過(guò)

Via: 1.1 a1.sample.com(Squid/2.7)

為了追蹤客戶端和服務(wù)器端之間的請(qǐng)求和響應(yīng)報(bào)文的傳輸路徑。 報(bào)文經(jīng)過(guò)代理或網(wǎng)關(guān)時(shí)，會(huì)現(xiàn)在首部字段 Via 中附加該服務(wù)器的信息，然后再進(jìn)行轉(zhuǎn)發(fā)。 首部字段 Via 不僅用于追蹤報(bào)文的轉(zhuǎn)發(fā)，還可避免請(qǐng)求回環(huán)的發(fā)生。4.9 Warning

這個(gè)頭字段通常通知用戶一些關(guān)于緩存相關(guān)問(wèn)題的警告。

警告標(biāo)題字段的格式如下

警告:[警告代碼][警告主機(jī):端口號(hào)]"[警告內(nèi)容]"([日期和時(shí)間])

最后的日期和時(shí)間可以省略。

HTTP/1.1中定義了7種警告，警告代碼對(duì)應(yīng)的警告內(nèi)容僅供參考。此外，警告代碼是可擴(kuò)展的，將來(lái)可能會(huì)添加新的警告代碼。

警告碼 警告內(nèi)容 說(shuō)明 110 Response is stale(響應(yīng)已過(guò)期) 代理返回已過(guò)期的資源 111 Revalidation failed(再驗(yàn)證失敗) 代理再驗(yàn)證資源有效性時(shí)失?。ǚ?wù)器無(wú)法到達(dá)等原因） 112 Disconnection operation(斷開(kāi)連接操作) 代理與互聯(lián)網(wǎng)連接被故意切斷 113 Heuristic expiration(試探性過(guò)期) 響應(yīng)的試用期超過(guò)24小時(shí)(有效緩存的設(shè)定時(shí)間大于24小時(shí)的情況下) 199 Miscellaneous warning(雜項(xiàng)警告) 任意的警告內(nèi)容 214 Transformation applied(使用了轉(zhuǎn)換) 代理對(duì)內(nèi)容編碼或媒體類(lèi)型等執(zhí)行了某些處理時(shí) 299 Miscellaneous persistent warning(持久雜項(xiàng)警告) 任意的警告內(nèi)容

5.請(qǐng)求頭字段(HTTP/1.1)

首部字段名 說(shuō)明 Accept 用戶代理可處理的媒體類(lèi)型 Accept-Charset 優(yōu)先的字符集 Accept-Encoding 優(yōu)先的內(nèi)容編碼 Accept-Language 優(yōu)先的語(yǔ)言（自然語(yǔ)言） Authorization Web認(rèn)證信息 Expect 期待服務(wù)器的特定行為 From 用戶的電子郵箱地址 Host 請(qǐng)求資源所在服務(wù)器 If-Match 比較實(shí)體標(biāo)記（ETag） If-Modified-Since 比較資源的更新時(shí)間 If-None-Match 比較實(shí)體標(biāo)記（與 If-Macth 相反） If-Range 資源未更新時(shí)發(fā)送實(shí)體 Byte 的范圍請(qǐng)求 If-Unmodified-Since 比較資源的更新時(shí)間(與 If-Modified-Since 相反) Max-Forwards 最大傳輸逐跳數(shù) Proxy-Authorization 代理服務(wù)器要求客戶端的認(rèn)證信息 Range 實(shí)體的字節(jié)范圍請(qǐng)求 Referer 對(duì)請(qǐng)求中 URI 的原始獲取方 TE 傳輸編碼的優(yōu)先級(jí) User-Agent HTTP 客戶端程序的信息

5.1接受

接受:text/html，application/xhtml+xml，application/XML；q=0.5

Accept 首部字段可通知服務(wù)器，用戶代理能夠處理的媒體類(lèi)型及媒體類(lèi)型的相對(duì)優(yōu)先級(jí)?？墒褂?type/subtype 這種形式，一次指定多種媒體類(lèi)型。 若想要給顯示的媒體類(lèi)型增加優(yōu)先級(jí)，則使用 q=[數(shù)值] 來(lái)表示權(quán)重值，用分號(hào)（;）進(jìn)行分隔。權(quán)重值的范圍 0~1（可精確到小數(shù)點(diǎn)后三位），且 1 為最大值。不指定權(quán)重值時(shí)，默認(rèn)為 1。5.2 Accept-Charset

Accept-Charset: iso-8859-5，unicode-1-1；q=0.8

Accept-Charset頭字段可用于通知服務(wù)器用戶代理支持的字符集以及字符集的相對(duì)優(yōu)先級(jí)。此外，您可以一次指定多個(gè)字符集。Q=[ value]也用來(lái)表示相對(duì)優(yōu)先級(jí)。

5.3接受編碼

接受-編碼:g，deflate

Accept-Encoding頭字段用于通知服務(wù)器用戶代理支持的內(nèi)容代碼以及內(nèi)容代碼的優(yōu)先級(jí)順序，并且可以一次指定多個(gè)內(nèi)容代碼。Q=[ value]也用來(lái)表示相對(duì)優(yōu)先級(jí)。您也可以使用星號(hào)(*)作為通配符來(lái)指定任何編碼格式。

5.4接受-語(yǔ)言

Accept-Lanuage: zh-cn，zh；q=0.7，en=us，en；q=0.3

告訴服務(wù)器用戶代理可以處理的自然語(yǔ)言集(中文或英文等)。)和自然語(yǔ)言集的相對(duì)優(yōu)先級(jí)，并一次指定多個(gè)自然語(yǔ)言集。Q=[ value]也用來(lái)表示相對(duì)優(yōu)先級(jí)。

5.5授權(quán)

授權(quán):基本ldfKDHKfkDdasSAEdasd = =

將用戶代理的身份驗(yàn)證信息(證書(shū)值)通知服務(wù)器。通常，希望通過(guò)服務(wù)器驗(yàn)證的用戶代理在收到返回的401狀態(tài)代碼響應(yīng)后，會(huì)將標(biāo)題字段“授權(quán)”添加到請(qǐng)求中。當(dāng)公共緩存接收到包含授權(quán)頭字段的請(qǐng)求時(shí)，操作處理將略有不同。

5.6期待

期望:100-繼續(xù)

通知服務(wù)器客戶端預(yù)期的特定行為。

5.7從

出發(fā)地:Deeson_Woo@ 163。com

告訴服務(wù)器使用用戶代理的電子郵件地址。

5.8主機(jī)

主持人:www.jianshu.com

告知服務(wù)器，請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)和端口號(hào)。 Host 首部字段是 HTTP/1.1 規(guī)范內(nèi)唯一一個(gè)必須被包含在請(qǐng)求內(nèi)的首部字段。 若服務(wù)器未設(shè)定主機(jī)名，那直接發(fā)送一個(gè)空值即可 Host: 。5.9 If-Match

If-xxx形式的請(qǐng)求頭字段可以稱(chēng)為條件請(qǐng)求。服務(wù)器收到帶條件的請(qǐng)求后，只有判斷指定條件為真，才會(huì)執(zhí)行請(qǐng)求。

如果匹配:“123456”

首部字段 If-Match，屬附帶條件之一，它會(huì)告知服務(wù)器匹配資源所用的實(shí)體標(biāo)記（ETag）值。這時(shí)的服務(wù)器無(wú)法使用弱 ETag 值。 服務(wù)器會(huì)比對(duì) If-Match 的字段值和資源的 ETag 值，僅當(dāng)兩者一致時(shí)，才會(huì)執(zhí)行請(qǐng)求。反之，則返回狀態(tài)碼 412 Precondition Failed 的響應(yīng)。 還可以使用星號(hào)（*）指定 If-Match 的字段值。針對(duì)這種情況，服務(wù)器將會(huì)忽略 ETag 的值，只要資源存在就處理請(qǐng)求。5.10 If-Modified-Since

如果-修改-自:2017年7月10日星期一15:50:06格林尼治標(biāo)準(zhǔn)時(shí)間

首部字段 If-Modified-Since，屬附帶條件之一，用于確認(rèn)代理或客戶端擁有的本地資源的有效性。 它會(huì)告知服務(wù)器若 If-Modified-Since 字段值早于資源的更新時(shí)間，則希望能處理該請(qǐng)求。而在指定 If-Modified-Since 字段值的日期時(shí)間之后，如果請(qǐng)求的資源都沒(méi)有過(guò)更新，則返回狀態(tài)碼 304 Not Modified 的響應(yīng)。5.11 If-None-Match

如果-無(wú)-匹配:“123456”

標(biāo)題字段如果-無(wú)-匹配是附加的條件之一。它的工作原理與標(biāo)題字段“如果匹配”相反。當(dāng)用于指定如果不匹配字段的值的實(shí)體標(biāo)記的值與所請(qǐng)求資源的實(shí)體標(biāo)記不一致時(shí)，它告訴服務(wù)器處理該請(qǐng)求。

5.12中頻范圍

if-范圍:“123456”

首部字段 If-Range 屬于附帶條件之一。它告知服務(wù)器若指定的 If-Range 字段值（ETag 值或者時(shí)間）和請(qǐng)求資源的 ETag 值或時(shí)間相一致時(shí)，則作為范圍請(qǐng)求處理。反之，則返回全體資源。 下面我們思考一下不使用首部字段 If-Range 發(fā)送請(qǐng)求的情況。服務(wù)器端的資源如果更新，那客戶端持有資源中的一部分也會(huì)隨之無(wú)效，當(dāng)然，范圍請(qǐng)求作為前提是無(wú)效的。這時(shí)，服務(wù)器會(huì)暫且以狀態(tài)碼 412 Precondition Failed 作為響應(yīng)返回，其目的是催促客戶端再次發(fā)送請(qǐng)求。這樣一來(lái)，與使用首部字段 If-Range 比起來(lái)，就需要花費(fèi)兩倍的功夫。5.13 If-Unmodified-Since

如果-未修改-自:2017年7月10日星期一15:50:06格林尼治標(biāo)準(zhǔn)時(shí)間

標(biāo)題字段“如果-未修改-自”和標(biāo)題字段“如果-修改-自”具有相反的功能。它的功能是通知服務(wù)器，指定的請(qǐng)求資源只能在字段值中指定的日期和時(shí)間之后處理請(qǐng)求。如果更新發(fā)生在指定的日期和時(shí)間之后，則返回狀態(tài)代碼412先決條件失敗作為響應(yīng)。

5.14最大值-遠(yuǎn)期

最大轉(zhuǎn)發(fā)數(shù):10

當(dāng)通過(guò)TRACE方法或OPTIONS方法發(fā)送包含頭字段Max-Forward的請(qǐng)求時(shí)，該字段以十進(jìn)制整數(shù)的形式指定可以通過(guò)的最大服務(wù)器數(shù)量。在服務(wù)器將請(qǐng)求轉(zhuǎn)發(fā)到下一臺(tái)服務(wù)器之前，最大轉(zhuǎn)發(fā)值減1，然后重新分配。當(dāng)服務(wù)器收到最大轉(zhuǎn)發(fā)值為0的請(qǐng)求時(shí)，它不會(huì)轉(zhuǎn)發(fā)它，而是直接返回響應(yīng)。

5.15代理-授權(quán)

代理-授權(quán):基本dGlwOjkpNLAGfFY5

接收到從代理服務(wù)器發(fā)來(lái)的認(rèn)證質(zhì)詢時(shí)，客戶端會(huì)發(fā)送包含首部字段 Proxy-Authorization 的請(qǐng)求，以告知服務(wù)器認(rèn)證所需要的信息。 這個(gè)行為是與客戶端和服務(wù)器之間的 HTTP 訪問(wèn)認(rèn)證相類(lèi)似的，不同之處在于，認(rèn)證行為發(fā)生在客戶端與代理之間。5.16 Range

范圍:字節(jié)=5

范圍:字節(jié)=5001-10000

對(duì)于只需獲取部分資源的范圍請(qǐng)求，包含首部字段 Range 即可告知服務(wù)器資源的指定范圍。 接收到附帶 Range 首部字段請(qǐng)求的服務(wù)器，會(huì)在處理請(qǐng)求之后返回狀態(tài)碼為 206 Partial Content 的響應(yīng)。無(wú)法處理該范圍請(qǐng)求時(shí)，則會(huì)返回狀態(tài)碼 200 OK 的響應(yīng)及全部資源。

5.17推薦人

推薦人:http://www . sample . com/index . html

標(biāo)題字段Referer告訴服務(wù)器所請(qǐng)求的原始資源的URI。

5.18 TE

TE: g，放氣；q=0.5

首部字段 TE 會(huì)告知服務(wù)器客戶端能夠處理響應(yīng)的傳輸編碼方式及相對(duì)優(yōu)先級(jí)。它和首部字段 Accept-Encoding 的功能很相像，但是用于傳輸編碼。 首部字段 TE 除指定傳輸編碼之外，還可以指定伴隨 trailer 字段的分塊傳輸編碼的方式。應(yīng)用后者時(shí)，只需把 trailers 賦值給該字段值。TE: trailers5.19 User-Agent

用戶代理:Mozilla/5.0(Windows NT 6.1；WOW64rv:13.0) Gecko/20100101

首部字段 User-Agent 會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱(chēng)等信息傳達(dá)給服務(wù)器。 由網(wǎng)絡(luò)爬蟲(chóng)發(fā)起請(qǐng)求時(shí)，有可能會(huì)在字段內(nèi)添加爬蟲(chóng)作者的電子郵件地址。此外，如果請(qǐng)求經(jīng)過(guò)代理，那么中間也很可能被添加上代理服務(wù)器的名稱(chēng)。6. 響應(yīng)首部字段（HTTP/1.1）首部字段名 說(shuō)明 Accept-Ranges 是否接受字節(jié)范圍請(qǐng)求 Age 推算資源創(chuàng)建經(jīng)過(guò)時(shí)間 ETag 資源的匹配信息 Location 令客戶端重定向至指定 URI Proxy-Authenticate 代理服務(wù)器對(duì)客戶端的認(rèn)證信息 Retry-After 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求 Server HTTP 服務(wù)器的安裝信息 Vary 代理服務(wù)器緩存的管理信息 WWW-Authenticate 服務(wù)器對(duì)客戶端的認(rèn)證信息

6.1接受范圍

接受-范圍:字節(jié)

首部字段 Accept-Ranges 是用來(lái)告知客戶端服務(wù)器是否能處理范圍請(qǐng)求，以指定獲取服務(wù)器端某個(gè)部分的資源。 可指定的字段值有兩種，可處理范圍請(qǐng)求時(shí)指定其為 bytes，反之則指定其為 none。6.2 Age

年齡:1200

首部字段 Age 能告知客戶端，源服務(wù)器在多久前創(chuàng)建了響應(yīng)。字段值的單位為秒。 若創(chuàng)建該響應(yīng)的服務(wù)器是緩存服務(wù)器，Age 值是指緩存后的響應(yīng)再次發(fā)起認(rèn)證到認(rèn)證完成的時(shí)間值。代理創(chuàng)建響應(yīng)時(shí)必須加上首部字段 Age。6.3 ETag

ETag: "usagi-1234 "

首部字段 ETag 能告知客戶端實(shí)體標(biāo)識(shí)。它是一種可將資源以字符串形式做唯一性標(biāo)識(shí)的方式。服務(wù)器會(huì)為每份資源分配對(duì)應(yīng)的 ETag 值。 另外，當(dāng)資源更新時(shí)，ETag 值也需要更新。生成 ETag 值時(shí)，并沒(méi)有統(tǒng)一的算法規(guī)則，而僅僅是由服務(wù)器來(lái)分配。 ETag 中有強(qiáng) ETag 值和弱 ETag 值之分。強(qiáng) ETag 值，不論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值；弱 ETag 值只用于提示資源是否相同。只有資源發(fā)生了根本改變，產(chǎn)生差異時(shí)才會(huì)改變 ETag 值。這時(shí)，會(huì)在字段值最開(kāi)始處附加 W/：ETag: W/"usagi-1234"。6.4 Location

網(wǎng)址:http://www . sample . com/sample . html

使用首部字段 Location 可以將響應(yīng)接收方引導(dǎo)至某個(gè)與請(qǐng)求 URI 位置不同的資源。 基本上，該字段會(huì)配合 3xx ：Redirection 的響應(yīng)，提供重定向的 URI。 幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應(yīng)后，都會(huì)強(qiáng)制性地嘗試對(duì)已提示的重定向資源的訪問(wèn)。6.5 Proxy-Authenticate

代理-身份驗(yàn)證:基本領(lǐng)域

首部字段 Proxy-Authenticate 會(huì)把由代理服務(wù)器所要求的認(rèn)證信息發(fā)送給客戶端。 它與客戶端和服務(wù)器之間的 HTTP 訪問(wèn)認(rèn)證的行為相似，不同之處在于其認(rèn)證行為是在客戶端與代理之間進(jìn)行的。6.6 Retry-After

重試后:180

首部字段 Retry-After 告知客戶端應(yīng)該在多久之后再次發(fā)送請(qǐng)求。主要配合狀態(tài)碼 503 Service Unavailable 響應(yīng)，或 3xx Redirect 響應(yīng)一起使用。 字段值可以指定為具體的日期時(shí)間（Mon, 10 Jul 2017 15:50:06 GMT 等格式），也可以是創(chuàng)建響應(yīng)后的秒數(shù)。6.7 Server

服務(wù)器:Apache/2.2.6 (Unix) PHP/5.2.5

頭字段服務(wù)器告訴客戶端當(dāng)前服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序的信息。不僅會(huì)標(biāo)記服務(wù)器上軟件應(yīng)用程序的名稱(chēng)，還會(huì)標(biāo)記版本號(hào)和安裝期間啟用的可選選項(xiàng)。

6.8變化

變化:接受-語(yǔ)言

首部字段 Vary 可對(duì)緩存進(jìn)行控制。源服務(wù)器會(huì)向代理服務(wù)器傳達(dá)關(guān)于本地緩存使用方法的命令。 從代理服務(wù)器接收到源服務(wù)器返回包含 Vary 指定項(xiàng)的響應(yīng)之后，若再要進(jìn)行緩存，僅對(duì)請(qǐng)求中含有相同 Vary 指定首部字段的請(qǐng)求返回緩存。即使對(duì)相同資源發(fā)起請(qǐng)求，但由于 Vary 指定的首部字段不相同，因此必須要從源服務(wù)器重新獲取資源。6.9 WWW-Authenticate

萬(wàn)維網(wǎng)-認(rèn)證:基本領(lǐng)域

標(biāo)題字段WWW-Authenticate用于HTTP訪問(wèn)驗(yàn)證。它通知客戶端身份驗(yàn)證方案(基本或摘要)和帶有參數(shù)提示的質(zhì)詢，該參數(shù)提示適用于訪問(wèn)請(qǐng)求URI指定的資源。

7.實(shí)體頭字段(HTTP/1.1)

首部字段名 說(shuō)明 Allow 資源可支持的 HTTP 方法 Content-Encoding 實(shí)體主體適用的編碼方式 Content-Language 實(shí)體主體的自然語(yǔ)言 Content-Length 實(shí)體主體的大?。▎挝唬鹤止?jié)） Content-Location 替代對(duì)應(yīng)資源的 URI Content-MD5 實(shí)體主體的報(bào)文摘要 Content-Range 實(shí)體主體的位置范圍 Content-Type 實(shí)體主體的媒體類(lèi)型 Expires 實(shí)體主體過(guò)期的日期時(shí)間 Last-Modified 資源的最后修改日期時(shí)間 7.1 Allow

允許:開(kāi)始，頭

首部字段 Allow 用于通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法。 當(dāng)服務(wù)器接收到不支持的 HTTP 方法時(shí)，會(huì)以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回。與此同時(shí)，還會(huì)把所有能支持的 HTTP 方法寫(xiě)入首部字段 Allow 后返回。7.2 Content-Encoding

內(nèi)容編碼:g

首部字段 Content-Encoding 會(huì)告知客戶端服務(wù)器對(duì)實(shí)體的主體部分選用的內(nèi)容編碼方式。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮。 主要采用這 4 種內(nèi)容編碼的方式（g、compress、deflate、identity）。7.3 Content-Language

內(nèi)容-語(yǔ)言:中文

第一個(gè)字段，內(nèi)容-語(yǔ)言，將通知客戶實(shí)體中使用的自然語(yǔ)言(中文或英文)。

7.4內(nèi)容-長(zhǎng)度

內(nèi)容-長(zhǎng)度:15000

標(biāo)題字段內(nèi)容-長(zhǎng)度指示實(shí)體主體部分的大小(以字節(jié)為單位)。當(dāng)在實(shí)體主體上執(zhí)行內(nèi)容編碼傳輸時(shí)，不能再使用內(nèi)容長(zhǎng)度報(bào)頭字段。

7.5內(nèi)容-位置

內(nèi)容-位置:http://www . sample . com/index . html

標(biāo)題字段內(nèi)容-位置給出對(duì)應(yīng)于消息正文的URI。與標(biāo)題字段位置不同，內(nèi)容位置指示與消息正文返回的資源相對(duì)應(yīng)的URI。

7.6內(nèi)容-MD5

內(nèi)容-MD5:ogfkzduwngvhngy3n 2mxmdiwzmq 4 ntbmy2iyty = =

報(bào)頭字段Content-MD5是由MD5算法生成的一系列值，旨在檢查消息體在傳輸過(guò)程中是否保持完整，并確認(rèn)傳輸?shù)牡竭_(dá)。

7.7內(nèi)容-范圍

內(nèi)容-范圍:字節(jié)5001-10000/10000

對(duì)于范圍請(qǐng)求，返回響應(yīng)時(shí)使用的標(biāo)題字段“內(nèi)容-范圍”可以告訴客戶端，作為響應(yīng)返回的實(shí)體的哪一部分滿足范圍請(qǐng)求。字段值以字節(jié)為單位，表示當(dāng)前發(fā)送部分和整個(gè)實(shí)體的大小。

7.8內(nèi)容類(lèi)型

內(nèi)容——類(lèi)型:文本/html；字符集=UTF-8

標(biāo)題字段內(nèi)容類(lèi)型描述實(shí)體主體中對(duì)象的媒體類(lèi)型。與標(biāo)題字段“接受”一樣，字段值以類(lèi)型/子類(lèi)型的形式分配。參數(shù)字符集由iso-8859-1或euc-jp指定。

7.9到期

到期時(shí)間:2017年7月10日星期一15:50:06格林尼治時(shí)間

首部字段 Expires 會(huì)將資源失效的日期告知客戶端。 緩存服務(wù)器在接收到含有首部字段 Expires 的響應(yīng)后，會(huì)以緩存來(lái)應(yīng)答請(qǐng)求，在 Expires 字段值指定的時(shí)間之前，響應(yīng)的副本會(huì)一直被保存。當(dāng)超過(guò)指定的時(shí)間后，緩存服務(wù)器在請(qǐng)求發(fā)送過(guò)來(lái)時(shí)，會(huì)轉(zhuǎn)向源服務(wù)器請(qǐng)求資源。 源服務(wù)器不希望緩存服務(wù)器對(duì)資源緩存時(shí)，最好在 Expires 字段內(nèi)寫(xiě)入與首部字段 Date 相同的時(shí)間值。7.10 Last-Modified

最后修改時(shí)間:2017年7月10日星期一15:50:06格林尼治時(shí)間

上次修改的標(biāo)題字段指示資源上次修改的時(shí)間。一般來(lái)說(shuō)，該值是請(qǐng)求-URI指定的資源被修改的時(shí)間。但是，類(lèi)似于使用CGI腳本進(jìn)行動(dòng)態(tài)數(shù)據(jù)處理，這個(gè)值可能成為數(shù)據(jù)最終被修改的時(shí)間。

8.Cookie服務(wù)的標(biāo)頭字段

首部字段名 說(shuō)明 首部類(lèi)型 Set-Cookie 開(kāi)始狀態(tài)管理所使用的 Cookie 信息 響應(yīng)首部字段 Cookie 服務(wù)器接收到的 Cookie 信息 請(qǐng)求首部字段

8.1設(shè)置Cookie

set-Cookie:status = enable；到期= 2017年7月10日星期一格林尼治時(shí)間15:50:06；path =/；

下表列出了設(shè)置Cookie的字段值。

屬性 說(shuō)明 NAME=VALUE 賦予 Cookie 的名稱(chēng)和其值（必需項(xiàng)） expires=DATE Cookie 的有效期（若不明確指定則默認(rèn)為瀏覽器關(guān)閉前為止） path=PATH 將服務(wù)器上的文件目錄作為Cookie的適用對(duì)象（若不指定則默認(rèn)為文檔所在的文件目錄） domain=域名 作為 Cookie 適用對(duì)象的域名 （若不指定則默認(rèn)為創(chuàng)建 Cookie的服務(wù)器的域名） Secure 僅在 HTTPS 安全通信時(shí)才會(huì)發(fā)送 Cookie HttpOnly 加以限制，使 Cookie 不能被 Java 腳本訪問(wèn)

8.1.1過(guò)期屬性

Cookie 的 expires 屬性指定瀏覽器可發(fā)送 Cookie 的有效期。 當(dāng)省略 expires 屬性時(shí)，其有效期僅限于維持瀏覽器會(huì)話（Session）時(shí)間段內(nèi)。這通常限于瀏覽器應(yīng)用程序被關(guān)閉之前。 另外，一旦 Cookie 從服務(wù)器端發(fā)送至客戶端，服務(wù)器端就不存在可以顯式刪除 Cookie 的方法。但可通過(guò)覆蓋已過(guò)期的 Cookie，實(shí)現(xiàn)對(duì)客戶端 Cookie 的實(shí)質(zhì)性刪除操作。

8.1.2路徑屬性

Cookie的Path屬性可用于限制指定Cookie發(fā)送范圍的文件目錄。

8.1.3域?qū)傩?/p> 通過(guò) Cookie 的 domain 屬性指定的域名可做到與結(jié)尾匹配一致。比如，當(dāng)指定 example.com 后，除example.com 以外，www.example.com 或 www2.example.com 等都可以發(fā)送 Cookie。 因此，除了針對(duì)具體指定的多個(gè)域名發(fā)送 Cookie 之 外，不指定 domain 屬性顯得更安全。

8.1.4安全屬性

cookie的安全屬性用于限制網(wǎng)頁(yè)僅在HTTPS安全連接時(shí)才發(fā)送cookie。

8.1.5 HttpOnly屬性

Cookie 的 HttpOnly 屬性是 Cookie 的擴(kuò)展功能，它使 Java 腳本無(wú)法獲得 Cookie。其主要目的為防止跨站腳本攻擊（Cross-site ing，XSS）對(duì) Cookie 的信息竊取。 通過(guò)上述設(shè)置，通常從 Web 頁(yè)面內(nèi)還可以對(duì) Cookie 進(jìn)行讀取操作。但使用 Java 的 document.cookie 就無(wú)法讀取附加 HttpOnly 屬性后的 Cookie 的內(nèi)容了。因此，也就無(wú)法在 XSS 中利用 Java 劫持 Cookie 了。

8.2餅干

Cookie:狀態(tài)=啟用

標(biāo)頭字段Cookie告訴服務(wù)器，當(dāng)客戶端想要獲得HTTP狀態(tài)管理支持時(shí)，它將在請(qǐng)求中包含從服務(wù)器接收的Cookie。當(dāng)收到多個(gè)cookie時(shí)，也可以以多個(gè)cookie的形式發(fā)送。

9.其他標(biāo)題字段

HTTP頭字段是可自我擴(kuò)展的。所以在Web服務(wù)器和瀏覽器的應(yīng)用中，會(huì)出現(xiàn)各種不標(biāo)準(zhǔn)的表頭字段。

以下是最常用的標(biāo)題字段。

9.1 X-框架-選項(xiàng)

框架選項(xiàng):拒絕

標(biāo)題字段X-框架-選項(xiàng)屬于HTTP響應(yīng)標(biāo)題，用于控制網(wǎng)站內(nèi)容在其他網(wǎng)站的框架標(biāo)簽中的顯示。它的主要目的是防止點(diǎn)擊劫持攻擊。標(biāo)題字段“X-框架-選項(xiàng)”有以下兩個(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è)面就不行了）

9.2X-XSS-保護(hù)

x-XSS-保護(hù):1

報(bào)頭字段X-XSS-Protection屬于HTTP響應(yīng)報(bào)頭，是針對(duì)跨站點(diǎn)腳本攻擊(XSS)的對(duì)策，用于控制瀏覽器XSS保護(hù)機(jī)制的切換?？梢栽跇?biāo)題字段X-XSS-保護(hù)中指定的字段值如下:

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

9.3 DNT

DNT: 1

報(bào)頭字段DNT屬于HTTP請(qǐng)求報(bào)頭，其中DNT是“不追蹤”的縮寫(xiě)，表示拒絕收集個(gè)人信息，是一種拒絕被精確廣告追蹤的方法?？梢栽跇?biāo)題字段DNT中指定的字段值如下:

0 ：同意被追蹤 1 ：拒絕被追蹤

由于DNT報(bào)頭字段的功能是有效的，因此網(wǎng)絡(luò)服務(wù)器需要相應(yīng)地支持DNT。

9.4 P3P

P3P: CP="CAO DSP LAW CURa ADMa DEVa阿泰PSAa PSDa IVAa IVDa OUR BUS IND

報(bào)頭字段P3P屬于HTTP響應(yīng)報(bào)頭。通過(guò)使用P3p(The Platform for Privacy Preferences，Online Platform for Privacy Preferences)技術(shù)，可以將網(wǎng)站上的個(gè)人隱私變成只有程序才能理解的形式，從而保護(hù)用戶的隱私。

要設(shè)置P3P，請(qǐng)按照下列步驟操作:

步驟 1：創(chuàng)建 P3P 隱私 步驟 2：創(chuàng)建 P3P 隱私對(duì)照文件后，保存命名在 /w3c/p3p.xml 步驟 3：從 P3P 隱私中新建 Compact policies 后，輸出到 HTTP 響應(yīng)中

七、HTTP響應(yīng)狀態(tài)碼(重點(diǎn)分析)

1.狀態(tài)代碼概述

HTTP 狀態(tài)碼負(fù)責(zé)表示客戶端 HTTP 請(qǐng)求的返回結(jié)果、標(biāo)記服務(wù)器端的處理是否正常、通知出現(xiàn)的錯(cuò)誤等工作。 HTTP 狀態(tài)碼如 200 OK ，以 3 位數(shù)字和原因短語(yǔ)組成。數(shù)字中的第一位指定了響應(yīng)類(lèi)別，后兩位無(wú)分類(lèi)。 不少返回的響應(yīng)狀態(tài)碼都是錯(cuò)誤的，但是用戶可能察覺(jué)不到這點(diǎn)。比如 Web 應(yīng)用程序內(nèi)部發(fā)生錯(cuò)誤，狀態(tài)碼依然返回 200 OK。

2.狀態(tài)代碼類(lèi)別

類(lèi)別 原因短語(yǔ) 1xx Informational(信息性狀態(tài)碼) 接收的請(qǐng)求正在處理 2xx Success(成功狀態(tài)碼) 請(qǐng)求正常處理完畢 3xx Redirection(重定向狀態(tài)碼) 需要進(jìn)行附加操作以完成請(qǐng)求 4xx Client Error(客戶端錯(cuò)誤狀態(tài)碼) 服務(wù)器無(wú)法處理請(qǐng)求 5xx Server Error(服務(wù)器錯(cuò)誤狀態(tài)碼) 服務(wù)器處理請(qǐng)求出錯(cuò)

我們可以自己更改RFC2616中定義的狀態(tài)代碼，也可以由服務(wù)器創(chuàng)建狀態(tài)代碼，只要遵循狀態(tài)代碼的類(lèi)別定義即可。

3.常見(jiàn)狀態(tài)代碼分析

HTTP狀態(tài)碼有很多種，有幾十種。其中最常用的有以下14種。我們來(lái)看看。

3.1 200 OK

指示從客戶端發(fā)送的請(qǐng)求通常在服務(wù)器端處理。

3.2 204無(wú)內(nèi)容

代表服務(wù)器接收的請(qǐng)求已成功處理，但在返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分。另外，也不允許返回任何實(shí)體的主體。 一般在只需要從客戶端向服務(wù)器端發(fā)送消息，而服務(wù)器端不需要向客戶端發(fā)送新消息內(nèi)容的情況下使用。

3.3 206部分內(nèi)容

它表明客戶端發(fā)出了一個(gè)范圍請(qǐng)求，服務(wù)器成功地執(zhí)行了GET請(qǐng)求的這一部分。響應(yīng)消息包含由內(nèi)容范圍報(bào)頭字段指定的范圍內(nèi)的實(shí)體內(nèi)容。

3.4 301永久移動(dòng)

持久重定向。指示請(qǐng)求的資源已被分配新的URI?，F(xiàn)在資源所指的URI應(yīng)該在以后使用。也就是說(shuō)，如果對(duì)應(yīng)于該資源的URI已經(jīng)被保存為書(shū)簽，則應(yīng)該根據(jù)由位置頭字段提示的URI再次保存它。

3.5 302找到

臨時(shí)性重定向。表示請(qǐng)求的資源已被分配了新的 URI，希望用戶（本次）能使用新的 URI 訪問(wèn)。 和 301 Moved Permanently 狀態(tài)碼相似，但 302 Found 狀態(tài)碼代表資源不是被永久移動(dòng)，只是臨時(shí)性質(zhì)的。換句話說(shuō)，已移動(dòng)的資源對(duì)應(yīng)的 URI 將來(lái)還有可能發(fā)生改變。

3.6 303參見(jiàn)其他

表示由于請(qǐng)求的資源存在著另一個(gè) URI，應(yīng)使用 GET 方法定向獲取請(qǐng)求的資源。303 See Other 和 302 Found 狀態(tài)碼有著相同的功能，但 303 See Other 狀態(tài)碼明確表示客戶端應(yīng)采用 GET 方法獲取資源，這點(diǎn)與 302 Found 狀態(tài)碼有區(qū)別。

3.7 304未修改

表示客戶端發(fā)送附帶條件的請(qǐng)求時(shí)，服務(wù)器端允許請(qǐng)求訪問(wèn)的資源，但未滿足條件的情況。304 Not Modified 狀態(tài)碼返回時(shí)，不包含任何響應(yīng)的主體部分。304 Not Modified 雖然被劃分到 3xx 類(lèi)別中，但和重定向沒(méi)有關(guān)系。

3.8 307臨時(shí)重定向

臨時(shí)重定向。該狀態(tài)代碼的含義與302“已找到”相同。

3.9 400錯(cuò)誤請(qǐng)求

表示請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤。當(dāng)錯(cuò)誤發(fā)生時(shí)，需修改請(qǐng)求的內(nèi)容后再次發(fā)送請(qǐng)求。另外，瀏覽器會(huì)像 200 OK 一樣對(duì)待該狀態(tài)碼。

3.10 401未經(jīng)授權(quán)

表示發(fā)送的請(qǐng)求需要有通過(guò) HTTP 認(rèn)證（BASIC 認(rèn)證、DIGEST 認(rèn)證）的認(rèn)證信息。另外，若之前已進(jìn)行過(guò) 1 次請(qǐng)求，則表示用戶認(rèn)證失敗。返回含有 401 Unauthorized 的響應(yīng)必須包含一個(gè)適用于被請(qǐng)求資源的 WWW-Authenticate 首部用以質(zhì)詢（challenge）用戶信息。

3.11 403禁止

表示服務(wù)器拒絕訪問(wèn)請(qǐng)求的資源。服務(wù)器不需要給出拒絕的詳細(xì)原因，但是也可以在響應(yīng)消息的實(shí)體體部分描述原因。

3.12 404未找到

指示在服務(wù)器上找不到請(qǐng)求的資源。另外，也可以在服務(wù)端拒絕請(qǐng)求，不想說(shuō)明原因的時(shí)候使用。

3.13 500內(nèi)部服務(wù)器錯(cuò)誤

指示執(zhí)行請(qǐng)求時(shí)服務(wù)器端出現(xiàn)錯(cuò)誤。也可能是Web應(yīng)用程序中的一個(gè)bug或者某種暫時(shí)的失敗。

3.14 503服務(wù)不可用

表示服務(wù)器暫時(shí)過(guò)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無(wú)法處理請(qǐng)求。如果您事先知道緩解上述情況所需的時(shí)間，最好編寫(xiě)“重試后”頭字段并將其返回給客戶端。

八、HTTP消息實(shí)體

1.http消息實(shí)體概述

請(qǐng)仔細(xì)看看上面例子中每個(gè)組件對(duì)應(yīng)的內(nèi)容。

接下來(lái)，讓我們看看消息和實(shí)體的概念。如果把HTTP消息看作是互聯(lián)網(wǎng)貨運(yùn)系統(tǒng)中的一個(gè)盒子，那么HTTP實(shí)體就是消息中的實(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)容是消息的實(shí)體部分，而藍(lán)色框的兩部分是實(shí)體頭和實(shí)體體。左邊圖片中的粉紅色方框就是消息體。

一般消息體等于實(shí)體體。只有在傳輸中進(jìn)行編碼操作時(shí)，實(shí)體體的內(nèi)容才會(huì)發(fā)生變化，從而導(dǎo)致它與消息體的區(qū)別。

2.內(nèi)容編碼

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

內(nèi)容編碼類(lèi)型:

編碼方式描述g表明實(shí)體采用 GNU 編碼compress表明實(shí)體采用 Unix 的文件壓縮程序deflate表明實(shí)體采用 zlib 的格式壓縮的identity表明沒(méi)有對(duì)實(shí)體進(jìn)行編碼，當(dāng)沒(méi)有 Content-Encoding 首部字段時(shí)，默認(rèn)采用此編碼方式

3.傳輸編碼

內(nèi)容編碼是消息體的可逆轉(zhuǎn)換，與內(nèi)容的具體格式細(xì)節(jié)密切相關(guān)。

傳輸編碼也是作用于實(shí)體體的可逆變換，但它們是出于架構(gòu)原因而使用的，與內(nèi)容的格式無(wú)關(guān)。傳輸編碼用于改變消息中的數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)姆绞健?/p>

4.分組編碼

塊編碼將一條消息分成幾個(gè)已知大小的塊。塊是并排發(fā)送的，所以發(fā)送前不需要知道整個(gè)消息的大小。分組編碼是一種傳輸編碼，是報(bào)文的屬性。

塊編碼和持久連接

如果客戶機(jī)和服務(wù)器之間的連接不是持久的，客戶機(jī)不需要知道它正在讀取的正文的長(zhǎng)度，而只需要讀取，直到服務(wù)器關(guān)閉正文的連接。

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

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

讓我們看一個(gè)塊編碼消息的例子:

5.多部分媒體類(lèi)型

MIME中的多部分電子郵件包含多條消息，這些消息作為一條復(fù)雜的消息一起發(fā)送。每個(gè)部分都是獨(dú)立的，有自己的集合描述它的內(nèi)容，不同的部分通過(guò)分界字符串連接在一起。

相應(yīng)地，HTTP協(xié)議也采用多部分對(duì)象集，發(fā)送的消息正文可以包含各種類(lèi)型的實(shí)體。

多部分對(duì)象集合包含以下對(duì)象:

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

6.范圍請(qǐng)求

假設(shè)你正在下載一個(gè)很大的文件，下載了四分之三，突然網(wǎng)絡(luò)中斷，那么你必須重新開(kāi)始。為了解決這個(gè)問(wèn)題，需要一個(gè)可恢復(fù)的機(jī)制，即可以從之前的下載中斷恢復(fù)下載。要實(shí)現(xiàn)這個(gè)功能，這需要范圍請(qǐng)求。

通過(guò)范圍請(qǐng)求，HTTP客戶端可以通過(guò)請(qǐng)求未能獲得的實(shí)體的范圍(或部分)來(lái)恢復(fù)下載該實(shí)體。當(dāng)然，有一個(gè)前提，即從客戶端最后一次請(qǐng)求實(shí)體的時(shí)間到發(fā)出范圍請(qǐng)求的時(shí)間，對(duì)象沒(méi)有發(fā)生變化。例如:

GET /bigfile.html HTTP/1.1

主持人:www.sample.com

范圍:字節(jié)=20224-

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

九.與超文本傳輸協(xié)議合作的網(wǎng)絡(luò)服務(wù)器

在HTTP通信中，除了客戶端和服務(wù)器端，還有一些用來(lái)輔助通信的應(yīng)用。更重要的如下:代理、緩存、網(wǎng)關(guān)、隧道和代理。

1.機(jī)構(gòu)

HTTP代理服務(wù)器是Web安全、應(yīng)用集成和性能優(yōu)化的重要組成部分。代理位于客戶端和服務(wù)器之間，接收來(lái)自客戶端的所有HTTP請(qǐng)求，并將它們轉(zhuǎn)發(fā)給服務(wù)器(在轉(zhuǎn)發(fā)之前，請(qǐng)求可能會(huì)被修改)。對(duì)用戶來(lái)說(shuō)，這些應(yīng)用程序只是代表他們?cè)L問(wèn)服務(wù)器的代理。

出于安全原因，代理通常用作轉(zhuǎn)發(fā)所有網(wǎng)絡(luò)流量的可信中間節(jié)點(diǎn)。代理還可以過(guò)濾請(qǐng)求和響應(yīng)，安全或綠色上網(wǎng)。

2.高速緩存

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

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

Web緩存或代理緩存是一種特殊的HTTP代理服務(wù)器，可以復(fù)制和保存代理傳輸?shù)某Ｓ梦臋n。下一個(gè)請(qǐng)求相同文檔的客戶端可以享受緩存的私有副本所提供的服務(wù)?？蛻舳藦母浇木彺嫦螺d文檔的速度比從遠(yuǎn)程網(wǎng)絡(luò)服務(wù)器快得多。

3.門(mén)

網(wǎng)關(guān)是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實(shí)體。常用于將HTTP流量轉(zhuǎn)換為其他協(xié)議。網(wǎng)關(guān)接收請(qǐng)求，就好像它是資源的源服務(wù)器一樣?？蛻舳丝赡懿恢浪麄冋谂c網(wǎng)關(guān)通信。

4.人工地下通道

隧道是一種建立后在兩個(gè)連接之間盲目轉(zhuǎn)發(fā)原始數(shù)據(jù)的HTTP應(yīng)用程序。超文本傳輸協(xié)議隧道通常用于通過(guò)一個(gè)或多個(gè)超文本傳輸協(xié)議連接轉(zhuǎn)發(fā)非超文本傳輸協(xié)議數(shù)據(jù)，而不會(huì)窺探數(shù)據(jù)。

HTTP隧道的一個(gè)常見(jiàn)用途是通過(guò)HTTP連接傳輸加密的安全套接字層(SSL)流量，這樣SSL流量就可以通過(guò)只允許網(wǎng)絡(luò)流量通過(guò)的防火墻。

5.代理代理

代理代理是代表用戶發(fā)起HTTP請(qǐng)求的客戶端應(yīng)用程序。發(fā)布網(wǎng)絡(luò)請(qǐng)求的所有應(yīng)用程序都是超文本傳輸協(xié)議代理。

滌綸_Woo

https://www.jianshu.com/p/6e9e4156ece3