（71）一篇文章帶你熟悉HTTP協議

時間 2019-12-06

原文原文鏈接



做者：滌生_Woo
連接：http://www.jianshu.com/p/6e9e4156ece3
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

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

一張圖帶你看完本篇文章

1、概述

1.計算機網絡體系結構分層

計算機網絡體系結構分層

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服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。安全

2、HTTP 工做過程

HTTP請求響應模型

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

創建 TCP 鏈接
在HTTP工做開始以前，客戶端首先要經過網絡與服務器創建鏈接，該鏈接是經過 TCP 來完成的，該協議與 IP 協議共同構建 Internet，即著名的 TCP/IP 協議族，所以 Internet 又被稱做是 TCP/IP 網絡。HTTP 是比 TCP 更高層次的應用層協議，根據規則，只有低層協議創建以後，才能進行高層協議的鏈接，所以，首先要創建 TCP 鏈接，通常 TCP 鏈接的端口號是80；
客戶端向服務器發送請求命令
一旦創建了TCP鏈接，客戶端就會向服務器發送請求命令；
例如：GET/sample/hello.jsp HTTP/1.1
客戶端發送請求頭信息
客戶端發送其請求命令以後，還要以頭信息的形式向服務器發送一些別的信息，以後客戶端發送了一空白行來通知服務器，它已經結束了該頭信息的發送；
服務器應答
客戶端向服務器發出請求後，服務器會客戶端返回響應；
例如： HTTP/1.1 200 OK
響應的第一部分是協議的版本號和響應狀態碼
服務器返回響應頭信息
正如客戶端會隨同請求發送關於自身的信息同樣，服務器也會隨同響應向用戶發送關於它本身的數據及被請求的文檔；
服務器向客戶端發送數據
服務器向客戶端發送頭信息後，它會發送一個空白行來表示頭信息的發送到此爲結束，接着，它就以 Content-Type 響應頭信息所描述的格式發送用戶所請求的實際數據；
服務器關閉 TCP 鏈接
通常狀況下，一旦服務器向客戶端返回了請求數據，它就要關閉 TCP 鏈接，而後若是客戶端或者服務器在其頭信息加入了這行代碼 Connection:keep-alive ，TCP 鏈接在發送後將仍然保持打開狀態，因而，客戶端能夠繼續經過相同的鏈接發送請求。保持鏈接節省了爲每一個請求創建新鏈接所需的時間，還節約了網絡帶寬。

3、HTTP 協議基礎

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

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

2.HTTP 是不保存狀態的協議

HTTP 是一種無狀態協議。協議自身不對請求和響應之間的通訊狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不作持久化處理。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。
但是隨着 Web 的不斷髮展，咱們的不少業務都須要對通訊狀態進行保存。因而咱們引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就能夠管理狀態了。cookie

3.使用 Cookie 的狀態管理

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

Cookie 的流程

4.請求 URI 定位資源

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

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

HTTP 方法

6.持久鏈接

HTTP 協議的初始版本中，每進行一個 HTTP 通訊都要斷開一次 TCP 鏈接。好比使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無畏的 TCP 鏈接創建和斷開，增長通訊量的開銷。
爲了解決上述 TCP 鏈接的問題，HTTP/1.1 和部分 HTTP/1.0 想出了持久鏈接的方法。其特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。旨在創建一次 TCP 鏈接後進行屢次請求和響應的交互。在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接。

7.管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。之前發送請求後需等待並接收到響應，才能發送下一個請求。管線化技術出現後，不用等待亦可發送下一個請求。這樣就能作到同時並行發送多個請求，而不須要一個接一個地等待響應了。
好比，當請求一個包含多張圖片的 HTML 頁面時，與挨個鏈接相比，用持久鏈接可讓請求更快結束。而管線化技術要比持久鏈接速度更快。請求數越多，時間差就越明顯。

4、HTTP 協議報文結構

1.HTTP 報文

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

2.HTTP 報文結構

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

HTTP 報文結構

2.1請求報文結構

請求報文結構

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

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

請求報文的示例，以下：

請求報文示例

2.2響應報文結構

響應報文結構

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

狀態行 —— 包含代表響應結果的狀態碼、緣由短語和 HTTP 版本。
首部字段 —— 包含表示請求的各類條件和屬性的各種首部。（通用首部、響應首部、實體首部以及RFC裏未定義的首部如 Cookie 等）

響應報文的示例，以下：

響應報文示例

5、HTTP 報文首部之請求行、狀態行

1.請求行

舉個栗子，下面是一個 HTTP 請求的報文：

GET  /index.htm  HTTP/1.1
Host: sample.com

其中，下面的這行就是請求行，

GET  /index.htm  HTTP/1.1

開頭的 GET 表示請求訪問服務器的類型，稱爲方法；
隨後的字符串 /index.htm 指明瞭請求訪問的資源對象，也叫作請求 URI；
最後的 HTTP/1.1，即 HTTP 的版本號，用來提示客戶端使用的 HTTP 協議功能。

綜合來看，大意是請求訪問某臺 HTTP 服務器上的 /index.htm 頁面資源。

2.狀態行

一樣舉個栗子，下面是一個 HTTP 響應的報文：

HTTP/1.1  200  OK
Date: Mon, 10 Jul 2017 15:50:06 GMT
Content-Length: 256
Content-Type: text/html
    
<html>
...

其中，下面的這行就是狀態行，

HTTP/1.1  200  OK

開頭的 HTTP/1.1 表示服務器對應的 HTTP 版本；
緊挨着的 200 OK 表示請求的處理結果的狀態碼和緣由短語。

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

1.首部字段概述

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

2.首部字段結構

HTTP 首部字段是由首部字段名和字段值構成的，中間用冒號「：」分隔。
另外，字段值對應單個 HTTP 首部字段能夠有多個值。
當 HTTP 報文首部中出現了兩個或以上具備相同首部字段名的首部字段時，這種狀況在規範內還沒有明確，根據瀏覽器內部處理邏輯的不一樣，優先處理的順序可能不一樣，結果可能並不一致。

首部字段名	冒號	字段值
Content-Type	：	text/html
Keep-Alive	：	timeout=30, max=120

3.首部字段類型

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

類型	描述
通用首部字段	請求報文和響應報文兩方都會使用的首部
請求首部字段	從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息
響應首部字段	從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段	針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的的信息。

4.通用首部字段（HTTP/1.1）

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	逐挑首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知

4.1 Cache-Control

經過指定首部字段 Cache-Control 的指令，就能操做緩存的工做機制。

4.1.1 可用的指令一覽

可用的指令按請求和響應分類以下：
緩存請求指令

指令	參數	說明
no-cache	無	強制向服務器再次驗證
no-store	無	不緩存請求或響應的任何內容
max-age = [秒]	必需	響應的最大Age值
max-stale( =[秒])	可省略	接收已過時的響應
min-fresh = [秒]	必需	指望在指定時間內的響應仍有效
no-transform	無	代理不可更改媒體類型
only-if-cached	無	從緩存獲取資源
cache-extension	-	新指令標記（token）

緩存響應指令

指令	參數	說明
public	無	可向任意方提供響應的緩存
private	可省略	僅向特定用戶返回響應
no-cache	可省略	緩存前必須先確認其有效性
no-store	無	不緩存請求或響應的任何內容
no-transform	無	代理不可更改媒體類型
must-revalidate	無	可緩存但必須再向源服務器進行確認
proxy-revalidate	無	要求中間緩存服務器對緩存的響應有效性再進行確認
max-age = [秒]	必需	響應的最大Age值
s-maxage = [秒]	必需	公共緩存服務器響應的最大Age值
cache-extension	-	新指令標記（token）

4.1.2 表示可否緩存的指令

public 指令
Cache-Control: public
當指定使用 public 指令時，則明確代表其餘用戶也可利用緩存。

private 指令
Cache-Control: private
當指定 private 指令後，響應只以特定的用戶做爲對象，這與 public 指令的行爲相反。緩存服務器會對該特定用戶提供資源緩存的服務，對於其餘用戶發送過來的請求，代理服務器則不會返回緩存。

no-cache 指令
Cache-Control: no-cache

使用 no-cache 指令是爲了防止從緩存中返回過時的資源。
客戶端發送的請求中若是包含 no-cache 指令，則表示客戶端將不會接收緩存過的響應。因而，「中間」的緩存服務器必須把客戶端請求轉發給源服務器。
若是服務器中返回的響應包含 no-cache 指令，那麼緩存服務器不能對資源進行緩存。源服務器之後也將再也不對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操做。

Cache-Control: no-cache=Location
由服務器返回的響應中，若報文首部字段 Cache-Control 中對 no-cache 字段名具體指定參數值，那麼客戶端在接收到這個被指定參數值的首部字段對應的響應報文後，就不能使用緩存。換言之，無參數值的首部字段可使用緩存。只能在響應指令中指定該參數。

no-store 指令
Cache-Control: no-store
當使用 no-store 指令時，暗示請求（和對應的響應）或響應中包含機密信息。所以，該指令規定緩存不能在本地存儲請求或響應的任一部分。
注意：no-cache 指令表明不緩存過時的指令，緩存會向源服務器進行有效期確認後處理資源；no-store 指令纔是真正的不進行緩存。

4.1.3 指定緩存期限和認證的指令

s-maxage 指令
Cache-Control: s-maxage=604800（單位：秒）

s-maxage 指令的功能和 max-age 指令的相同，它們的不一樣點是 s-maxage 指令只適用於供多位用戶使用的公共緩存服務器（通常指代理）。也就是說，對於向同一用戶重複返回響應的服務器來講，這個指令沒有任何做用。
另外，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及 max-age 指令的處理。

max-age 指令
Cache-Control: max-age=604800（單位：秒）

當客戶端發送的請求中包含 max-age 指令時，若是斷定緩存資源的緩存時間數值比指定的時間更小，那麼客戶端就接收緩存的資源。另外，當指定 max-age 的值爲0，那麼緩存服務器一般須要將請求轉發給源服務器。
當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源的有效性再做確認，而 max-age 數值表明資源保存爲緩存的最長時間。
應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的狀況時，會優先處理 max-age 指令，並忽略掉 Expires 首部字段；而 HTTP/1.0 版本的緩存服務器則相反。

min-fresh 指令
Cache-Control: min-fresh=60（單位：秒）
min-fresh 指令要求緩存服務器返回至少還未過指定時間的緩存資源。

max-stale 指令
Cache-Control: max-stale=3600（單位：秒）

使用 max-stale 可指示緩存資源，即便過時也照常接收。
若是指令未指定參數值，那麼不管通過多久，客戶端都會接收響應；若是指定了具體參數值，那麼即便過時，只要仍處於 max-stale 指定的時間內，仍舊會被客戶端接收。

only-if-cached 指令
Cache-Control: only-if-cached
表示客戶端僅在緩存服務器本地緩存目標資源的狀況下才會要求其返回。換言之，該指令要求緩存服務器不從新加載響應，也不會再次確認資源的有效性。

must-revalidate 指令
Cache-Control: must-revalidate
使用 must-revalidate 指令，代理會向源服務器再次驗證即將返回的響應緩存目前是否仍有效。另外，使用 must-revalidate 指令會忽略請求的 max-stale 指令。

proxy-revalidate 指令
Cache-Control: proxy-revalidate
proxy-revalidate 指令要求全部的緩存服務器在接收到客戶端帶有該指令的請求返回響應以前，必須再次驗證緩存的有效性。

no-transform 指令
Cache-Control: no-transform
使用 no-transform 指令規定不管是在請求仍是響應中，緩存都不能改變實體主體的媒體類型。這樣作可防止緩存或代理壓縮圖片等相似操做。

4.1.4 Cache-Control 擴展

Cache-Control: private, community="UCI"
經過 cache-extension 標記（token），能夠擴展 Cache-Control 首部字段內的指令。上述 community 指令即擴展的指令，若是緩存服務器不能理解這個新指令，就會直接忽略掉。

4.2 Connection

Connection 首部字段具有如下兩個做用：

控制再也不轉發的首部字段
Connection: Upgrade
在客戶端發送請求和服務器返回響應中，使用 Connection 首部字段，可控制再也不轉發給代理的首部字段，即刪除後再轉發（即Hop-by-hop首部）。

管理持久鏈接
Connection: close
HTTP/1.1 版本的默認鏈接都是持久鏈接。當服務器端想明確斷開鏈接時，則指定 Connection 首部字段的值爲 close。
Connection: Keep-Alive
HTTP/1.1 以前的 HTTP 版本的默認鏈接都是非持久鏈接。爲此，若是想在舊版本的 HTTP 協議上維持持續鏈接，則須要指定 Connection 首部字段的值爲 Keep-Alive。

4.3 Date

代表建立 HTTP 報文的日期和時間。
Date: Mon, 10 Jul 2017 15:50:06 GMT
HTTP/1.1 協議使用在 RFC1123 中規定的日期時間的格式。

4.4 Pragma

Pragma 首部字段是 HTTP/1.1 版本以前的歷史遺留字段，僅做爲與 HTTP/1.0 的向後兼容而定義。
Pragma: no-cache

該首部字段屬於通用首部字段，但只用在客戶端發送的請求中，要求全部的中間服務器不返回緩存的資源。
全部的中間服務器若是都能以 HTTP/1.1 爲基準，那直接採用 Cache-Control: no-cache 指定緩存的處理方式最爲理想。可是要總體掌握全部中間服務器使用的 HTTP 協議版本倒是不現實的，因此，發送的請求會同時包含下面兩個首部字段：

Cache-Control: no-cache
Pragma: no-cache

4.5 Trailer

Trailer: Expires
首部字段 Trailer 會事先說明在報文主體後記錄了哪些首部字段。可應用在 HTTP/1.1 版本分塊傳輸編碼時。

4.6 Transfer-Encoding

Transfer-Encoding: chunked

規定了傳輸報文主體時採用的編碼方式。
HTTP/1.1 的傳輸編碼方式僅對分塊傳輸編碼有效。

4.7 Upgrade

Upgrade: TSL/1.0
用於檢測 HTTP 協議及其餘協議是否可以使用更高的版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議。

4.8 Via

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

爲了追蹤客戶端和服務器端之間的請求和響應報文的傳輸路徑。
報文通過代理或網關時，會如今首部字段 Via 中附加該服務器的信息，而後再進行轉發。
首部字段 Via 不只用於追蹤報文的轉發，還可避免請求迴環的發生。

4.9 Warning

該首部字段一般會告知用戶一些與緩存相關的問題的警告。
Warning 首部字段的格式以下：
Warning：[警告碼][警告的主機:端口號] "[警告內容]"([日期時間])
最後的日期時間可省略。
HTTP/1.1 中定義了7種警告，警告碼對應的警告內容僅推薦參考，另外，警告碼具有擴展性，從此有可能追加新的警告碼。

警告碼	警告內容	說明
110	Response is stale(響應已過時)	代理返回已過時的資源
111	Revalidation failed(再驗證失敗)	代理再驗證資源有效性時失敗（服務器沒法到達等緣由）
112	Disconnection operation(斷開鏈接操做)	代理與互聯網鏈接被故意切斷
113	Heuristic expiration(試探性過時)	響應的試用期超過24小時(有效緩存的設定時間大於24小時的狀況下)
199	Miscellaneous warning(雜項警告)	任意的警告內容
214	Transformation applied(使用了轉換)	代理對內容編碼或媒體類型等執行了某些處理時
299	Miscellaneous persistent warning(持久雜項警告)	任意的警告內容

5. 請求首部字段（HTTP/1.1）

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言（天然語言）
Authorization	Web認證信息
Expect	期待服務器的特定行爲
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-None-Match	比較實體標記（與 If-Macth 相反）
If-Range	資源未更新時發送實體 Byte 的範圍請求
If-Unmodified-Since	比較資源的更新時間(與 If-Modified-Since 相反)
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍請求
Referer	對請求中 URI 的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP 客戶端程序的信息

5.1 Accept

Accept: text/html, application/xhtml+xml, application/xml; q=0.5

Accept 首部字段可通知服務器，用戶代理可以處理的媒體類型及媒體類型的相對優先級。可以使用 type/subtype 這種形式，一次指定多種媒體類型。
若想要給顯示的媒體類型增長優先級，則使用 q=[數值] 來表示權重值，用分號（;）進行分隔。權重值的範圍 0~1（可精確到小數點後三位），且 1 爲最大值。不指定權重值時，默認爲 1。

5.2 Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
Accept-Charset 首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。另外，可一次性指定多種字符集。一樣使用 q=[數值] 來表示相對優先級。

5.3 Accept-Encoding

Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先順序，並可一次性指定多種內容編碼。一樣使用 q=[數值] 來表示相對優先級。也可以使用星號（*）做爲通配符，指定任意的編碼格式。

5.4 Accept-Language

Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3
告知服務器用戶代理可以處理的天然語言集（指中文或英文等），以及天然語言集的相對優先級，可一次性指定多種天然語言集。一樣使用 q=[數值] 來表示相對優先級。

5.5 Authorization

Authorization: Basic ldfKDHKfkDdasSAEdasd==
告知服務器用戶代理的認證信息（證書值）。一般，想要經過服務器認證的用戶代理會在接收到返回的 401 狀態碼響應後，把首部字段 Authorization 加入請求中。共用緩存在接收到含有 Authorization 首部字段的請求時的操做處理會略有差別。

5.6 Expect

Expect: 100-continue
告知服務器客戶端指望出現的某種特定行爲。

5.7 From

From: Deeson_Woo@163.com
告知服務器使用用戶代理的電子郵件地址。

5.8 Host

Host: www.jianshu.com

告知服務器，請求的資源所處的互聯網主機和端口號。
Host 首部字段是 HTTP/1.1 規範內惟一一個必須被包含在請求內的首部字段。
若服務器未設定主機名，那直接發送一個空值便可 Host: 。

5.9 If-Match

形如 If-xxx 這種樣式的請求首部字段，均可稱爲條件請求。服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔會執行請求。

If-Match: "123456"

首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用的實體標記（ETag）值。這時的服務器沒法使用弱 ETag 值。
服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當二者一致時，纔會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響應。
還可使用星號（*）指定 If-Match 的字段值。針對這種狀況，服務器將會忽略 ETag 的值，只要資源存在就處理請求。

5.10 If-Modified-Since

If-Modified-Since: Mon, 10 Jul 2017 15:50:06 GMT

首部字段 If-Modified-Since，屬附帶條件之一，用於確認代理或客戶端擁有的本地資源的有效性。
它會告知服務器若 If-Modified-Since 字段值早於資源的更新時間，則但願能處理該請求。而在指定 If-Modified-Since 字段值的日期時間以後，若是請求的資源都沒有過更新，則返回狀態碼 304 Not Modified 的響應。

5.11 If-None-Match

If-None-Match: "123456"
首部字段 If-None-Match 屬於附帶條件之一。它和首部字段 If-Match 做用相反。用於指定 If-None-Match 字段值的實體標記（ETag）值與請求資源的 ETag 不一致時，它就告知服務器處理該請求。

5.12 If-Range

If-Range: "123456"

首部字段 If-Range 屬於附帶條件之一。它告知服務器若指定的 If-Range 字段值（ETag 值或者時間）和請求資源的 ETag 值或時間相一致時，則做爲範圍請求處理。反之，則返回全體資源。
下面咱們思考一下不使用首部字段 If-Range 發送請求的狀況。服務器端的資源若是更新，那客戶端持有資源中的一部分也會隨之無效，固然，範圍請求做爲前提是無效的。這時，服務器會暫且以狀態碼 412 Precondition Failed 做爲響應返回，其目的是催促客戶端再次發送請求。這樣一來，與使用首部字段 If-Range 比起來，就須要花費兩倍的功夫。

5.13 If-Unmodified-Since

If-Unmodified-Since: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的做用相反。它的做用的是告知服務器，指定的請求資源只有在字段值內指定的日期時間以後，未發生更新的狀況下，才能處理請求。若是在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 做爲響應返回。

5.14 Max-Forwards

Max-Forwards: 10
經過 TRACE 方法或 OPTIONS 方法，發送包含首部字段 Max-Forwards 的請求時，該字段以十進制整數形式指定可通過的服務器最大數目。服務器在往下一個服務器轉發請求以前，Max-Forwards 的值減 1 後從新賦值。當服務器接收到 Max-Forwards 值爲 0 的請求時，則再也不進行轉發，而是直接返回響應。

5.15 Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

接收到從代理服務器發來的認證質詢時，客戶端會發送包含首部字段 Proxy-Authorization 的請求，以告知服務器認證所須要的信息。
這個行爲是與客戶端和服務器之間的 HTTP 訪問認證相相似的，不一樣之處在於，認證行爲發生在客戶端與代理之間。

5.16 Range

Range: bytes=5001-10000

對於只需獲取部分資源的範圍請求，包含首部字段 Range 便可告知服務器資源的指定範圍。
接收到附帶 Range 首部字段請求的服務器，會在處理請求以後返回狀態碼爲 206 Partial Content 的響應。沒法處理該範圍請求時，則會返回狀態碼 200 OK 的響應及所有資源。

5.17 Referer

Referer: http://www.sample.com/index.html
首部字段 Referer 會告知服務器請求的原始資源的 URI。

5.18 TE

TE: gzip, deflate; q=0.5

首部字段 TE 會告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像，可是用於傳輸編碼。
首部字段 TE 除指定傳輸編碼以外，還能夠指定伴隨 trailer 字段的分塊傳輸編碼的方式。應用後者時，只需把 trailers 賦值給該字段值。TE: trailers

5.19 User-Agent

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101

首部字段 User-Agent 會將建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器。
由網絡爬蟲發起請求時，有可能會在字段內添加爬蟲做者的電子郵件地址。此外，若是請求通過代理，那麼中間也極可能被添加上代理服務器的名稱。

6. 響應首部字段（HTTP/1.1）

首部字段名	說明
Accept-Ranges	是否接受字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定 URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP 服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

6.1 Accept-Ranges

Accept-Ranges: bytes

首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理範圍請求，以指定獲取服務器端某個部分的資源。
可指定的字段值有兩種，可處理範圍請求時指定其爲 bytes，反之則指定其爲 none。

6.2 Age

Age: 1200

首部字段 Age 能告知客戶端，源服務器在多久前建立了響應。字段值的單位爲秒。
若建立該響應的服務器是緩存服務器，Age 值是指緩存後的響應再次發起認證到認證完成的時間值。代理建立響應時必須加上首部字段 Age。

6.3 ETag

ETag: "usagi-1234"

首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。
另外，當資源更新時，ETag 值也須要更新。生成 ETag 值時，並無統一的算法規則，而僅僅是由服務器來分配。
ETag 中有強 ETag 值和弱 ETag 值之分。強 ETag 值，不論實體發生多麼細微的變化都會改變其值；弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差別時纔會改變 ETag 值。這時，會在字段值最開始處附加 W/： ETag: W/"usagi-1234"。

6.4 Location

Location: http://www.sample.com/sample.html

使用首部字段 Location 能夠將響應接收方引導至某個與請求 URI 位置不一樣的資源。
基本上，該字段會配合 3xx ：Redirection 的響應，提供重定向的 URI。
幾乎全部的瀏覽器在接收到包含首部字段 Location 的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。

6.5 Proxy-Authenticate

Proxy-Authenticate: Basic realm="Usagidesign Auth"

首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端。
它與客戶端和服務器之間的 HTTP 訪問認證的行爲類似，不一樣之處在於其認證行爲是在客戶端與代理之間進行的。

6.6 Retry-After

Retry-After: 180

首部字段 Retry-After 告知客戶端應該在多久以後再次發送請求。主要配合狀態碼 503 Service Unavailable 響應，或 3xx Redirect 響應一塊兒使用。
字段值能夠指定爲具體的日期時間（Mon, 10 Jul 2017 15:50:06 GMT 等格式），也能夠是建立響應後的秒數。

6.7 Server

Server: Apache/2.2.6 (Unix) PHP/5.2.5
首部字段 Server 告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。不僅僅會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啓用的可選項。

6.8 Vary

Vary: Accept-Language

首部字段 Vary 可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。
從代理服務器接收到源服務器返回包含 Vary 指定項的響應以後，若再要進行緩存，僅對請求中含有相同 Vary 指定首部字段的請求返回緩存。即便對相同資源發起請求，但因爲 Vary 指定的首部字段不相同，所以必需要從源服務器從新獲取資源。

6.9 WWW-Authenticate

WWW-Authenticate: Basic realm="Usagidesign Auth"
首部字段 WWW-Authenticate 用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。

7. 實體首部字段（HTTP/1.1）

首部字段名	說明
Allow	資源可支持的 HTTP 方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（單位：字節）
Content-Location	替代對應資源的 URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

7.1 Allow

Allow: GET, HEAD

首部字段 Allow 用於通知客戶端可以支持 Request-URI 指定資源的全部 HTTP 方法。
當服務器接收到不支持的 HTTP 方法時，會以狀態碼 405 Method Not Allowed 做爲響應返回。與此同時，還會把全部能支持的 HTTP 方法寫入首部字段 Allow 後返回。

7.2 Content-Encoding

Content-Encoding: gzip

首部字段 Content-Encoding 會告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。
主要採用這 4 種內容編碼的方式（gzip、compress、deflate、identity）。

7.3 Content-Language

Content-Language: zh-CN
首部字段 Content-Language 會告知客戶端，實體主體使用的天然語言（指中文或英文等語言）。

7.4 Content-Length

Content-Length: 15000
首部字段 Content-Length 代表了實體主體部分的大小（單位是字節）。對實體主體進行內容編碼傳輸時，不能再使用 Content-Length首部字段。

7.5 Content-Location

Content-Location: http://www.sample.com/index.html
首部字段 Content-Location 給出與報文主體部分相對應的 URI。和首部字段 Location 不一樣，Content-Location 表示的是報文主體返回資源對應的 URI。

7.6 Content-MD5

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。

7.7 Content-Range

Content-Range: bytes 5001-10000/10000
針對範圍請求，返回響應時使用的首部字段 Content-Range，能告知客戶端做爲響應返回的實體的哪一個部分符合範圍請求。字段值以字節爲單位，表示當前發送部分及整個實體大小。

7.8 Content-Type

Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實體主體內對象的媒體類型。和首部字段 Accept 同樣，字段值用 type/subtype 形式賦值。參數 charset 使用 iso-8859-1 或 euc-jp 等字符集進行賦值。

7.9 Expires

Expires: Mon, 10 Jul 2017 15:50:06 GMT

首部字段 Expires 會將資源失效的日期告知客戶端。
緩存服務器在接收到含有首部字段 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間以前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。
源服務器不但願緩存服務器對資源緩存時，最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。

7.10 Last-Modified

Last-Modified: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 Last-Modified 指明資源最終修改的時間。通常來講，這個值就是 Request-URI 指定資源被修改的時間。但相似使用 CGI 腳本進行動態數據處理時，該值有可能會變成數據最終修改時的時間。

8. 爲 Cookie 服務的首部字段

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的 Cookie 信息	響應首部字段
Cookie	服務器接收到的 Cookie 信息	請求首部字段

8.1 Set-Cookie

Set-Cookie: status=enable; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/;

下面的表格列舉了 Set-Cookie 的字段值。

屬性	說明
NAME=VALUE	賦予 Cookie 的名稱和其值（必需項）
expires=DATE	Cookie 的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
path=PATH	將服務器上的文件目錄做爲Cookie的適用對象（若不指定則默認爲文檔所在的文件目錄）
domain=域名	做爲 Cookie 適用對象的域名（若不指定則默認爲建立 Cookie的服務器的域名）
Secure	僅在 HTTPS 安全通訊時纔會發送 Cookie
HttpOnly	加以限制，使 Cookie 不能被 JavaScript 腳本訪問

8.1.1 expires 屬性

Cookie 的 expires 屬性指定瀏覽器可發送 Cookie 的有效期。
當省略 expires 屬性時，其有效期僅限於維持瀏覽器會話（Session）時間段內。這一般限於瀏覽器應用程序被關閉以前。
另外，一旦 Cookie 從服務器端發送至客戶端，服務器端就不存在能夠顯式刪除 Cookie 的方法。但可經過覆蓋已過時的 Cookie，實現對客戶端 Cookie 的實質性刪除操做。

8.1.2 path 屬性

Cookie 的 path 屬性可用於限制指定 Cookie 的發送範圍的文件目錄。

8.1.3 domain 屬性

經過 Cookie 的 domain 屬性指定的域名可作到與結尾匹配一致。好比，當指定 example.com 後，除example.com 之外，www.example.com 或 www2.example.com 等均可以發送 Cookie。
所以，除了針對具體指定的多個域名發送 Cookie 之外，不指定 domain 屬性顯得更安全。

8.1.4 secure 屬性

Cookie 的 secure 屬性用於限制 Web 頁面僅在 HTTPS 安全鏈接時，才能夠發送 Cookie。

8.1.5 HttpOnly 屬性

Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本沒法得到 Cookie。其主要目的爲防止跨站腳本攻擊（Cross-site scripting，XSS）對 Cookie 的信息竊取。
經過上述設置，一般從 Web 頁面內還能夠對 Cookie 進行讀取操做。但使用 JavaScript 的 document.cookie 就沒法讀取附加 HttpOnly 屬性後的 Cookie 的內容了。所以，也就沒法在 XSS 中利用 JavaScript 劫持 Cookie 了。

8.2 Cookie

Cookie: status=enable
首部字段 Cookie 會告知服務器，當客戶端想得到 HTTP 狀態管理支持時，就會在請求中包含從服務器接收到的 Cookie。接收到多個 Cookie 時，一樣能夠以多個 Cookie 形式發送。

9. 其餘首部字段

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

9.1 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 等其餘域名的頁面就不行了）

9.2 X-XSS-Protection

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

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

9.3 DNT

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

0 ：贊成被追蹤
1 ：拒絕被追蹤

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

9.4 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 響應中

7、HTTP 響應狀態碼（重點分析）

1. 狀態碼概述

HTTP 狀態碼負責表示客戶端 HTTP 請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工做。
HTTP 狀態碼如 200 OK ，以 3 位數字和緣由短語組成。數字中的第一位指定了響應類別，後兩位無分類。
很多返回的響應狀態碼都是錯誤的，可是用戶可能察覺不到這點。好比 Web 應用程序內部發生錯誤，狀態碼依然返回 200 OK。

2. 狀態碼類別

	類別	緣由短語
1xx	Informational(信息性狀態碼)	接收的請求正在處理
2xx	Success(成功狀態碼)	請求正常處理完畢
3xx	Redirection(重定向狀態碼)	須要進行附加操做以完成請求
4xx	Client Error(客戶端錯誤狀態碼)	服務器沒法處理請求
5xx	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

咱們能夠自行改變 RFC2616 中定義的狀態碼或者服務器端自行建立狀態碼，只要遵照狀態碼的類別定義就能夠了。

3. 經常使用狀態碼解析

HTTP 狀態碼種類繁多，數量達幾十種。其中最經常使用的有如下 14 種，一塊兒來看看。

3.1 200 OK

表示從客戶端發來的請求在服務器端被正常處理了。

3.2 204 No Content

表明服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。另外，也不容許返回任何實體的主體。
通常在只須要從客戶端向服務器端發送消息，而服務器端不須要向客戶端發送新消息內容的狀況下使用。

3.3 206 Partial Content

表示客戶端進行了範圍請求，而服務器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 首部字段指定範圍的實體內容。

3.4 301 Moved Permanently

永久性重定向。表示請求的資源已被分配了新的 URI。之後應使用資源如今所指的 URI。也就是說，若是已經把資源對應的 URI 保存爲書籤了，這時應該按 Location 首部字段提示的 URI 從新保存。

3.5 302 Found

臨時性重定向。表示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問。
和 301 Moved Permanently 狀態碼類似，但 302 Found 狀態碼錶明資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的 URI 未來還有可能發生改變。

3.6 303 See Other

表示因爲請求的資源存在着另外一個 URI，應使用 GET 方法定向獲取請求的資源。
303 See Other 和 302 Found 狀態碼有着相同的功能，但 303 See Other 狀態碼明確表示客戶端應採用 GET 方法獲取資源，這點與 302 Found 狀態碼有區別。

3.7 304 Not Modified

表示客戶端發送附帶條件的請求時，服務器端容許請求訪問的資源，但未知足條件的狀況。
304 Not Modified 狀態碼返回時，不包含任何響應的主體部分。
304 Not Modified 雖然被劃分到 3xx 類別中，但和重定向沒有關係。

3.8 307 Temporary Redirect

臨時重定向。該狀態碼與 302 Found 有着相同的含義。

3.9 400 Bad Request

表示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。
另外，瀏覽器會像 200 OK 同樣對待該狀態碼。

3.10 401 Unauthorized

表示發送的請求須要有經過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。
另外，若以前已進行過 1 次請求，則表示用戶認證失敗。
返回含有 401 Unauthorized 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以質詢（challenge）用戶信息。

3.11 403 Forbidden

代表對請求資源的訪問被服務器拒絕了。服務器端沒有必要給出詳細的拒絕理由，固然也能夠在響應報文的實體主體部分對緣由進行描述。

3.12 404 Not Found

代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由的時候使用。

3.13 500 Internal Server Error

代表服務器端在執行請求時發生了錯誤。也多是 Web 應用存在的 bug 或某些臨時的故障。

3.14 503 Service Unavailable

代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入 Retry-After 首部字段再返回給客戶端。

8、HTTP 報文實體

1. HTTP 報文實體概述

HTTP 報文結構

你們請仔細看看上面示例中，各個組成部分對應的內容。
接着，咱們來看看報文和實體的概念。若是把 HTTP 報文想象成因特網貨運系統中的箱子，那麼 HTTP 實體就是報文中實際的貨物。

報文：是網絡中交換和傳輸的數據單元，即站點一次性要發送的數據塊。報文包含了將要發送的完整的數據信息，其長短很不一致，長度不限且可變。
實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。（實體首部相關內容在上面第六點中已有闡述。）

咱們能夠看到，上面示例右圖中深紅色框的內容就是報文的實體部分，而藍色框的兩部份內容分別就是實體首部和實體主體。而左圖中粉紅框內容就是報文主體。
一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別。

2. 內容編碼

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

內容編碼類型：

編碼方式	描述
gzip	代表實體採用 GNU zip 編碼
compress	代表實體採用 Unix 的文件壓縮程序
deflate	代表實體採用 zlib 的格式壓縮的
identity	代表沒有對實體進行編碼，當沒有 Content-Encoding 首部字段時，默認採用此編碼方式

3. 傳輸編碼

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

內容編碼和傳輸編碼的對比

4. 分塊編碼

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

分塊編碼與持久鏈接
若客戶端與服務器端之間不是持久鏈接，客戶端就不須要知道它在讀取的主體的長度，而只須要讀取到服務器關閉主體鏈接爲止。
當使用持久鏈接時，在服務器寫主體以前，必須知道它的大小並在 Content-Length 首部中發送。若是服務器動態建立內容，就可能在發送以前沒法知道主體的長度。
分塊編碼爲這種困難提供瞭解決方案，只要容許服務器把主體分塊發送，說明每塊的大小就能夠了。由於主體是動態建立的，服務器能夠緩衝它的一部分，發送其大小和相應的塊，而後在主體發送完以前重複這個過程。服務器能夠用大小爲 0 的塊做爲主體結束的信號，這樣就能夠繼續保持鏈接，爲下一個響應作準備。
來看看一個分塊編碼的報文示例：

分塊編碼的報文

5.多部分媒體類型

MIME 中的 multipart（多部分）電子郵件報文中包含多個報文，它們合在一塊兒做爲單一的複雜報文發送。每一部分都是獨立的，有各自的描述其內容的集，不一樣部分之間用分界字符串鏈接在一塊兒。
相應得，HTTP 協議中也採納了多部分對象集合，發送的一份報文主體內可包含多種類型實體。
多部分對象集合包含的對象以下：

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

6. 範圍請求

假設你正在下載一個很大的文件，已經下了四分之三，突然網絡中斷了，那下載就必須重頭再來一遍。爲了解決這個問題，須要一種可恢復的機制，即能從以前下載中斷處恢復下載。要實現該功能，這就要用到範圍請求。
有了範圍請求， HTTP 客戶端能夠經過請求曾獲取失敗的實體的一個範圍（或者說一部分），來恢復下載該實體。固然這有一個前提，那就是從客戶端上一次請求該實體到這一次發出範圍請求的時間段內，該對象沒有改變過。例如：

GET  /bigfile.html  HTTP/1.1
Host: www.sample.com
Range: bytes=20224-
···

實體範圍請求示例

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

9、與 HTTP 協做的 Web 服務器

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

1.代理

代理

HTTP 代理服務器是 Web 安全、應用集成以及性能優化的重要組成模塊。代理位於客戶端和服務器端之間，接收客戶端全部的 HTTP 請求，並將這些請求轉發給服務器（可能會對請求進行修改以後再進行轉發）。對用戶來講，這些應用程序就是一個代理，表明用戶訪問服務器。
出於安全考慮，一般會將代理做爲轉發全部 Web 流量的可信任中間節點使用。代理還能夠對請求和響應進行過濾，安全上網或綠色上網。

2. 緩存

瀏覽器第一次請求：

瀏覽器第一次請求

瀏覽器再次請求：

瀏覽器再次請求

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

3. 網關

HTTP / FTP 網關

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

4. 隧道

HTTP/SSL 隧道

隧道是會在創建起來以後，就會在兩條鏈接之間對原始數據進行盲轉發的 HTTP 應用程序。HTTP 隧道一般用來在一條或多條 HTTP 鏈接上轉發非 HTTP 數據，轉發時不會窺探數據。
HTTP 隧道的一種常見用途就是經過 HTTP 鏈接承載加密的安全套接字層（SSL）流量，這樣 SSL 流量就能夠穿過只容許 Web 流量經過的防火牆了。