一文帶你看清HTTP全部概念

上一篇文章咱們大體講解了一下 HTTP 的基本特徵和使用，你們反響很不錯，那麼本篇文章咱們就來深究一下 HTTP 的特性。咱們接着上篇文章沒有說完的 HTTP 標頭繼續來介紹（此篇文章會介紹全部標頭的概念，但沒有深刻底層）

HTTP 標頭

先來回顧一下 HTTP1.1 標頭都有哪幾種

HTTP 1.1 的標頭主要分爲四種，通用標頭、實體標頭、請求標頭、響應標頭，如今咱們來對這幾種標頭進行介紹

通用標頭

HTTP 通用標頭之因此這樣命名，是由於與其餘三個類別不一樣，它們不是限定於特定種類的消息或者消息組件（請求，響應或消息實體）的。HTTP 通用標頭主要用於傳達有關消息自己的信息，而不是它所攜帶的內容。它們提供通常信息並控制如何處理和處理消息。

儘管通用標頭不會限定因而請求仍是響應報文，可是某些通用標頭大部分或所有用於一種特定類型的請求中。也就是說，若是某個通用標頭出如今請求報文中，那麼大部分通用標頭都會顯示在該請求報文中。響應報文也是同樣的。

先列出來一個清單，講明咱們都須要介紹哪些通用標頭

• Cache-Control
• Connection
• Date
• Pragma
• Trailer
• Transfer-Encoding
• Upgrade
• Via
• Warning

Cache-Control

緩存（Cache）是計算機領域裏的一個重要概念，是優化系統性能的利器。不只計算機中的 CPU 爲了提升指令執行效率從而選擇使用寄存器做爲輔助，計算機網絡一樣存在緩存，下面咱們就來介紹一下計算機網絡中的緩存。

Cache-Control 是通用標頭的指令，它可以管理如何對 HTTP 的請求或者響應使用緩存。

由於計算機網絡中是能夠有第三者出現的，也就是緩存服務器，這個指令經過影響請求/響應中的緩存服務器從而達到控制緩存的目的；不只有緩存服務器，還有瀏覽器內部緩存也會影響鏈路的緩存。

這個標頭中能夠出現許多單獨的指令，其詳細信息能夠在 RFC 2616 中找到，即便這是常規標頭，某些指令也只能出如今請求或響應中。下表提供了一個 Cache-Control 選項的總結並告訴你如何去使用

請注意，在 Cache-Control 標頭中只能出現一個指令，可是在消息中能夠出現多個這樣的標頭。

上面這個表格其實會有四種分類

• 可緩存性： 它們分別是 no-cache、no-store、private 和 public
• 緩存有效性時間： 它們分別是 max-age、s-maxage、max-stale、min-fresh
• 從新驗證並從新加載： 它們分別是 must-revalidate 和 proxy-revalidate
• 其餘： 它們分別是 only-if-cached 和 no-transform

分別對錶格中的內容進行一下詳細介紹

no-cache

no-cache 很容易和 no-store 混淆，通常都會把 no-cache 認爲是不緩存，其實不是這樣。

使用 no-cache 指令的目的是爲了防止從緩存中返回過時的資源，例以下圖所示

Cache-Control: no-cache

舉個例子你就明白了，No-Cache 就至關因而吃着碗裏的，佔着鍋裏的，若是鍋裏還有新的肉片，就先吃鍋裏的，若是鍋裏沒有新的，再吃本身的，這裏鍋裏的就至關因而源服務器產生的，碗裏的就至關因而緩存的。

no-store

no-store 纔是真正意義上的不緩存，每次服務器接受到客戶端的請求後，都會返回最新的資源給客戶端。

Cache-Control: no-store

max-age

max-age 能夠用在請求或者響應中，當客戶端發送帶有 max-age 的指令時，緩存服務器會判斷本身緩存時間的數值和 max-age 的大小，若是比 max-age 小，那麼緩存有效，能夠繼續給客戶端返回緩存的數據，若是比 max-age 大，那麼緩存服務器將不能返回給客戶端緩存的數據。

Cache-Control: max-age=60

若是 max-age = 0，那麼緩存服務器將會直接把請求轉發到服務器

Cache-Control: max-age=0

注意：這個 max-age 的值是相對於請求時間的

must-revalidate

表示一旦資源過時，緩存就必須在原始服務器上沒有成功驗證的狀況下才使用其過時的數據。

Cache-Control: must-revalidate

no-store 、no_cache 、 must-revalidate 和 max-age 能夠一塊兒看，下面是一個這四個標頭的流程圖

public

public 屬性只出如今客戶端響應中，表示響應能夠被任何緩存所緩存。在計算機網絡中，分爲兩種緩存，共享緩存和私有緩存，以下所示

Cache-Control: public

private

當指定 private 指令後，響應只以特定的用戶做爲對象，這與 public 的用法相反，緩存服務器只對特定的客戶端進行緩存，其餘客戶端發送過來的請求，緩存服務器則不會返回緩存。

Cache-Control: private

s-maxage

s-maxage 指令的功能和 max-age 指令的功能相同，不一樣點之處在於 s-maxage 不能用於私有緩存，只能用於多用戶使用的公共服務器，對於同一用戶的重複請求和響應來講，這個指令沒有任何做用。

Cache-Control: s-maxage=60

min-fresh

min-fresh只能出如今請求中，min-fresh 要求緩存服務器返回 min-fresh 時間內的緩存數據。例如 Cache-Control:min-fresh=60，這就要求緩存服務器發送60秒內的數據。

Cache-Control: min-fresh=60

max-stable

max-stable 只能出如今請求中，表示客戶端會接受緩存數據，即便過時也照常接收。

Cache-Control: max-stable=60

only-if-cached

這個標頭只能出如今請求中，使用 only-if-cached 指令表示客戶端僅在緩存服務器本地緩存目標資源的狀況下才會要求其返回。

Cache-Control: only-if-cached

proxy-revalidate

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

Cache-Control: proxy-revalidate

no-transform

使用 no-transform 指令規定不管是在請求仍是響應中，緩存都不能改變實體主體的媒體類型。

Cache-Control: no-transform

Connection

HTTP 協議使用 TCP 來管理鏈接方式，主要有兩種鏈接方式，持久性鏈接 和 非持久性鏈接。

持久性鏈接

持久性鏈接指的是一次會話完成後，TCP 鏈接並未關閉，第二次再次發送請求後，就再也不須要創建 TCP 鏈接，而是能夠直接進行請求和響應。它的通常表示形式以下

Connection: keep-alive

從 HTTP 1.1 開始，默認使用持久性鏈接。

keep-alive 也是一個通用標頭，通常 Connection 都會和 keep-alive 一塊兒使用，keep-alive 有兩個參數，一個是 timeout；另外一個是 max，它們的主要表現形式以下

Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000

• timeout: 指的是空閒鏈接必須打開的最短期，也就是說此次請求的鏈接時間不能少於5秒，
• max: 指的是在鏈接關閉以前服務器所可以收到的最大請求數。

非持久性鏈接

非持久性鏈接表示一次會話請求/響應後關閉鏈接的方式。HTTP 1.1 以前使用的鏈接都是非持久鏈接，也就是

Connection: close

Date

Date 是一個通用標頭，它能夠出如今請求標頭和響應標頭中，它的基本表示以下

Date: Wed, 21 Oct 2015 07:28:00 GMT

表示的是格林威治標準時間，這個時間要比北京時間慢八個小時

Pragma

Pragma是 http 1.1 以前版本的歷史遺留字段，僅做爲與 http 的向後兼容而定義。它的通常形式以下

Pragma: no-cache

只用於客戶端發送的請求中。客戶端會要求全部的中間服務器不返回緩存的資源。

若是全部的中間服務器都以實現 HTTP /1.1爲標準，那麼直接使用 Cache-Control: no-cache 便可，若是不是的話，就要包含兩個字段，以下

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

Trailer

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

Transfer-Encoding: chunked
Trailer: Expires

以上用例中，指定首部字段 Trailer 的值爲 Expires，在報文主體以後（分塊長度 0 以後）出現了首部字段 Expires。

Transfer-Encoding

Transfer-Encoding 屬於內容協商的範疇，下面會具體介紹一下內容協商，如今先作個預告：Transfer-Encoding 規定了傳輸報文所採用的編碼方式

注意：HTTP 1.1 的傳輸編碼方式僅對分塊傳輸有效，可是 HTTP 2.0 就再也不支持分塊傳輸，而提供了本身更有效的數據傳輸機制。

Transfer-Encoding: chunked

Transfer-Encoding 也屬於 Hop-by-hop（逐跳） 首部 ，下面來回顧一下，HTTP 報文標頭除了能夠根據屬性所在的位置分爲 通用標頭、請求標頭、響應標頭 和 實體標頭；還能夠按照是否被緩存分爲 端到端首部(End-to-End) 和 逐跳首部(Top-to-Top)。

除了下面八種屬於逐跳首部外，其他都屬於端到端首部

Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade

下面回到討論中來，Transfer-Encoding 用於兩個節點之間傳輸消息，而不是資源自己。在多個節點傳輸消息的過程當中，每一段消息的傳輸均可以使用不一樣的 Transfer-Encoding。如圖所示

Transfer-Encoding 支持文件壓縮，若是你想要以文件壓縮後的形式發送的話。Transfer-Encoding 全部可選類型以下

• chunked： 數據按照一系列塊發送，在這種狀況下，將省略 Content-Length 標頭，並在每一個塊的開頭，須要以十六進制填充當前塊的長度，後跟 '\r\n'，而後是塊自己，而後是另外一個'\r\n'。當將大量數據發送到客戶端而且在請求已被徹底處理以前，可能沒法知道響應的總大小時，分塊編碼頗有用。 例如，在生成由數據庫查詢產生的大型 HTML 表時或在傳輸大型圖像時。 分塊的響應看起來像這樣

HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n 
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n 
\r\n

終止塊一般是0。緊隨Transfer-Encoding 後面的是 Trailer 標頭， Trailer 可能爲空。

• compress： 使用 Lempel-Ziv-Welch(LZW) 算法的格式。值名稱取自 UNIX 壓縮程序，該程序實現了該算法。如今幾乎沒有瀏覽器使用這種內容編碼了，由於這個專利在 2003 年就停掉了。
• deflate：使用 zlib(在 RFC 1950 定義) 結構和 deflate 壓縮算法
• gzip： 使用Lempel-Ziv編碼（LZ77）和32位CRC的格式。這最初是 UNIX gzip 程序的格式。HTTP / 1.1標準還建議出於兼容性目的，支持此內容編碼的服務器應將 x-gzip 識別爲別名。
• identity： 使用身份功能（即無壓縮或修改）。

也能夠列出多個值，以逗號分隔，相似一個集合列表

Transfer-Encoding: gzip, chunked

Upgrade

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

上圖用例中，首部字段 Upgrade 指定的值爲 TLS/1.0。請注意此處兩個字段首部字段的對應關係，Connection 的值被指定爲 Upgrade。
Upgrade 首部字段產生做用的對象僅限於客戶端和臨近服務器之間。所以，使用首部字段 Upgrade 時，還須要額外指定 Connection: Upgrade。
對於附有首部字段 Upgrade 的請求，服務器可用 101 Switching Protocols 狀態碼做爲響應返回。

Via

使用 Via 是爲了跟蹤客戶端和服務器之間的請求/響應路徑，避免請求循環以及可以識別請求/響應鏈中發送者協議的功能。Via 字段由代理服務器添加，不管是正向代理仍是反向代理，而且能夠出如今請求標頭和響應標頭中。它用於跟蹤消息轉發。例以下圖所示

Via 後面的的 1.1, 1.0 表示接收服務器上的 HTTP 版本，Via 首部是爲了跟蹤路徑，常常和 TRACE 方法一塊兒使用。

Warning

注意：Warning 字段即將被棄用

查閱 Warning (https://github.com/httpwg/http-core/issues/139) and Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) 獲取更多細節

Warning 通用 HTTP 標頭一般會告知用戶一些與緩存相關的問題的警告

HTTP/1.1 中定義了 7 種警告。它們分別以下

請求標頭

請求標頭用於客戶端發送 HTTP 請求到服務器中所使用的字段，下面咱們一塊兒來看一下 HTTP 請求標頭都包含哪些字段，分別是什麼意思。下面會介紹

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Authorization
• Expect
• From
• Host
• If-Match
• If-Modified-Since
• If-None-Match
• If-Range
• If-Unmodified-Since
• Max-Forwards
• Proxy-Authorization
• RangeReferer
• TE
• User-Agent

下面分別來介紹一下

Accept

HTTP 請求標頭會告知客戶端可以接收的 MIME 類型是什麼

那麼什麼是 MIME 類型呢？在回答這個問題前你應該先了解一下什麼是 MIME

MIME: MIME (Multipurpose Internet Mail Extensions) 是描述消息內容類型的因特網標準。MIME 消息能包含文本、圖像、音頻、視頻以及其餘應用程序專用的數據。

也就是說，MIME 類型其實就是一系列消息內容類型的集合。那麼 MIME 類型都有哪些呢？

文本文件： text/html、text/plain、text/css、application/xhtml+xml、application/xml

圖片文件： image/jpeg、image/gif、image/png

視頻文件： video/mpeg、video/quicktime

應用程序二進制文件： application/octet-stream、application/zip

好比，若是瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類型。

通常 MIME 類型也會和 q 這個屬性一塊兒使用，q 是什麼？q 表示的是權重，來看一個例子

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

這是什麼意思呢？若想要給顯示的媒體類型增長優先級，則使用 q= 來額外表示權重值，沒有顯示權重的時候默認值是1.0 ，我給你列個表格你就明白了

q	MIME
1.0	text/html
1.0	application/xhtml+xml
0.9	application/xml
0.8	/

也就是說，這是一個放置順序，權重高的在前，低的在後，application/xml;q=0.9 是不可分割的總體。

Accept-Charset

Accept-Charset 表示客戶端可以接受的字符編碼。Accept-Charset 也是屬於內容協商的一部分，它和

Accept 同樣，也能夠用 q 來表示字符集，用逗號進行分割，例如

Accept-Charset: iso-8859-1
Accept-Charset: utf-8, iso-8859-1;q=0.5
Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1

事實上，不少以 Accept-* 開頭的標頭，都是屬於內容協商的範疇，關於內容協商咱們下面會說。

Accept-Encoding

表示 HTTP 標頭會標明客戶端但願服務端返回的內容編碼，這一般是一種壓縮算法。Accept-Encoding 也是屬於內容協商 的一部分，使用並經過客戶端選擇 Content-Encoding 內容進行返回。

即便客戶端和服務器都可以支持相同的壓縮算法，服務器也可能選擇不壓縮並返回，這種狀況多是因爲這兩種狀況形成的:

• 要發送的數據已經被壓縮了一次，第二次壓縮並不會致使發送的數據更小
• 服務器過載，沒法承受壓縮帶來的性能開銷，一般，若是服務器使用 CPU 超過 80% ，Microsoft 則建議不要使用壓縮

下面是 Accept-Encoding 的使用方式

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

上面的幾種表述方式就已經把 Accept-Encoding 的屬性列全了

• gzip: 由文件壓縮程序 gzip 生成的編碼格式，使用 Lempel-Ziv編碼（LZ77）和32位CRC的壓縮格式，感興趣的同窗能夠讀一下 （https://en.wikipedia.org/wiki...）
• compress: 使用Lempel-Ziv-Welch（LZW）算法的壓縮格式，有興趣的同窗能夠讀 （https://en.wikipedia.org/wiki...）
• deflate: 使用 zlib 結構和 deflate 壓縮算法的壓縮格式，參考 （https://en.wikipedia.org/wiki...） 和 （https://en.wikipedia.org/wiki...）
• br: 使用 Brotli 算法的壓縮格式，參考 （https://en.wikipedia.org/wiki...）
• 不執行壓縮或不會變化的默認編碼格式
• * : 匹配標頭中未列出的任何內容編碼，若是沒有列出 Accept-Encoding ，這就是默認值，並不意味着支

  持任何算法，只是表示沒有偏好

• ;q= 採用權重 q 值來表示相對優先級，這點與首部字段 Accept 相同。

Accept-Language

Accept-Language 請求表示客戶端須要服務端返回的語言類型，Accept-Language 也屬於內容協商的範疇。服務端經過 Content-Language 進行響應，和 Accept 首部字段同樣，按權重值 q 來表示相對優先級。例如

Accept-Language: de
Accept-Language: de-CH
Accept-Language: en-US,en;q=0.5

Authorization

HTTP Authorization 請求頭用於向服務器認證用戶代理的憑據，一般用在服務器以401未經受權狀態和WWW-Authenticate標頭響應以後，啥意思呢？你不明白的話我畫張圖給你看

請求標頭 Authorization 是用來告知服務器，用戶的認證信息，服務器在只有收到認證後纔會返回給客戶端 200 OK 的響應，若是沒有認證信息，則會返回 401 並告知客戶端須要認證信息。詳細關於 Authorization 的信息，後面也會詳細解釋

Expect

Expect HTTP 請求標頭指示服務器須要知足的指望才能正確處理請求。若是服務器沒有辦法完成客服端所指望完成的事情而且服務端存在錯誤的話，會返回 417 Expectation Failed 。HTTP 1.1 只規定了100-continue 。

• 若是服務器能正常完成客戶端所指望的事情，會返回 100
• 若是不能知足指望或返回任何其餘4xx 的狀態碼，會返回 417

例如

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

From

From 請求頭用來告知服務器使用用戶代理的電子郵件地址。一般狀況下，其使用目的就是爲了顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式。咱們在使用代理的狀況下，應儘量包含 From 首部字段。例如

From: webmaster@example.org

你不該該將 From 用在訪問控制或者身份驗證中

Host

Host 請求頭指明瞭服務器的域名（對於虛擬主機來講），以及（可選的）服務器監聽的TCP端口號。若是沒有給定端口號，會自動使用被請求服務的默認端口（好比請求一個 HTTP 的 URL 會自動使用80做爲端口）。

Host: developer.mozilla.org

Host 首部字段在 HTTP/1.1 規範內是惟一一個必須被包含在請求內的首部字段。

If-Match

If-Match 後面能夠跟一大堆屬性，形式像 If-Match 這種的請求頭稱爲條件請求，服務器接收到條件請求後，須要斷定條件請求是否知足，只有條件請求爲真，纔會執行條件請求

相似的還有 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since

對於 GET 和 POST 方法，服務器僅在與列出的 ETag（響應標頭） 之一匹配時才返回請求的資源。這裏又多了一個新詞 ETag，咱們稍後再說 ETag 的用法。對於像是 PUT 和其餘非安全的方法，在這種狀況下，它僅僅將上傳資源。

下面是兩種常見的案例

• 對於 GET 和 POST 方法，會結合使用 Range 標頭，它能夠確保新發送請求的範圍與上一個請求的資源相同，若是不匹配的話，會返回 416 響應。
• 對於其餘方法，特別是 PUT 方法，If-Match 能夠防止丟失更新，服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當二者一致時，纔會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響應。例如

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-Match: *

If-Modified-Since

If-Modified-Since 是 HTTP 條件請求的一部分，只有在給定日期以後，服務端修改了請求所須要的資源，纔會返回 200 OK 的響應。若是在給定日期以後，服務端沒有修改內容，響應會返回 304 而且不帶任何響應體。If-Modified-Since 只能使用 GET 和 HEAD 請求。

If-Modified-Since 與 If-None-Match 結合使用時，它將被忽略，除非服務器不支持 If-None-Match。通常表示以下

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

注意：這是格林威治標準時間。 HTTP 日期始終以格林尼治標準時間表示，而不是本地時間。

If-None-Match

條件請求，它與 If-Match 的做用相反，僅當 If-None-Match 的字段值與 ETag 值不一致時，可處理該請求。對於GET 和 HEAD ，僅當服務器沒有與給定資源匹配的 ETag 時，服務器將返回 200 做爲響應。對於其餘方法，僅當最終現有資源的 ETag 與列出的任何值都不匹配時，纔會處理請求。

當 GET 和 POST 發送的 If-None-Match與 ETag 匹配時，服務器會返回 304。

If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
If-None-Match: W/"67ab43", "54ed21", "7892dd"
If-None-Match: *

有同窗可能會好奇 W/ 是什麼意思，這實際上是 ETag 的弱匹配，關於 ETag 咱們會在響應標頭中詳細講述。

If-Range

If-Range 也是條件請求，若是知足條件（If-Range 的值和 ETag 值或者更新的日期時間一致），則會發出範圍請求，不然將會返回所有資源。它的通常表示以下

If-Range: Wed, 21 Oct 2015 07:28:00 GMT

If-Unmodified-Since

If-Unmodified-Since HTTP 請求標頭也是一個條件請求，服務器只有在給定日期以後沒有對其進行修改時，服務器才返回請求資源。若是在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 做爲響應返回。

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT

Max-Forwards

MDN 把這個標頭置灰了，因此下面內容取自《圖解 HTTP》

Max-Forwards 通常用於 TRACE 和 OPTION 方法，發送包含 Max-Forwards 的首部字段時，每通過一個服務器，Max-Forwards 的值就會 -1，直到 Max-Forwards 爲0時返回。Max-Forwards 是一個十進制的整數值。

Max-Forwards: 10

能夠靈活使用首部字段 Max-Forwards，針對以上問題產生的緣由展開調查。因爲當 Max-Forwards 字段值爲 0 時，服務器就會當即返回響應，由此咱們至少能夠對以那臺服務器爲終點的傳輸路徑的通訊情況有所把握。

Proxy-Authorization

Proxy-Authorization 是屬於請求與認證的範疇，咱們在上面提到一個認證的 HTTP 標頭是 Authorization，不一樣於 Authorization 發生在客戶端 - 服務器之間；Proxy-Authorization 發生在代理服務器和客戶端之間。它表示接收到從代理服務器發來的認證時，客戶端會發送包含首部字段 Proxy-Authorization 的請求，以告知服務器認證所須要的信息。

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

Range

Range HTTP 請求標頭指示服務器應返回文檔指定部分的資源，能夠一次請求一個 Range 來返回多個部分，服務器會將這些資源返回各個文檔中。若是服務器成功返回，那麼將返回 206 響應；若是 Range 範圍無效，服務器返回416 Range Not Satisfiable錯誤；服務器還能夠忽略 Range 標頭，而且返回 200 做爲響應。

Range: bytes=200-1000, 2000-6576, 19000-

Referer

HTTP Referer 屬性是請求標頭的一部分，當瀏覽器向 web 服務器發送請求的時候，通常會帶上 Referer，告訴服務器該網頁是從哪一個頁面連接過來的，服務器所以能夠得到一些信息用於處理。

Referer: https://developer.mozilla.org/testpage.html

TE

首部字段 TE 會告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像，可是用於傳輸編碼。

TE: gzip, deflate;q=0.5

首部字段 TE 除指定傳輸編碼以外，還能夠指定伴隨 trailer 字段的分塊傳輸編碼的方式。應用後者時，只需把 trailers 賦值給該字段值。

TE: trailers, deflate;q=0.5

User-Agent

首部字段 User-Agent 會將建立請求的瀏覽器和用戶代理名稱等信息傳達給服務器。

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

響應標頭

剛剛咱們的着重點一直放在客戶端請求，如今咱們把關注點轉換一下放在服務器上。響應首部字段是由服務器發送給客戶端響應中所包含的字段，用於補充相應信息等，這部分標頭也是很是多，咱們先一塊兒來看一下

• Accept-Ranges
• Age
• ETag
• Location
• Proxy-Authenticate
• Retry-After
• Server
• Vary
• www-Authenticate

Accept-Ranges

Accept-Ranges HTTP 響應標頭，這個標頭有兩個值

• 當服務器可以處理客戶端發送過來的請求時，使用bytes 來指定
• 當服務器不能處理客戶端發來的請求時，使用 none 來指定

Accept-Ranges: bytes
Accept-Ranges: none

Age

Age HTTP 響應標頭告訴客戶端源服務器在多久以前建立了響應，它的單位爲秒，Age 標頭一般接近於0，若是是0則多是從源服務器獲取的，若是不是表示多是由代理服務器建立，那麼 Age 的值表示的是緩存後的響應再次發起認證到認證完成的時間值。代理建立響應時必須加上首部字段 Age。通常表示以下

Age: 24

ETag

ETag 對於條件請求來講真是過重要了。由於條件請求就是根據 ETag 的值進行匹配的，下面咱們就來詳細瞭解一下。

ETag 響應頭是特定版本的標識，它可以使緩存變得更高效並可以節省帶寬，由於若是緩存內容未發生變動，Web 服務器則不須要從新發送完整的響應。除此以外，ETag 可以防止資源同時更新互相覆蓋。

若是給定 URL 上的資源發生變動，必須生成一個新的 ETag 值，經過比較它們能夠肯定資源的兩個表示形式是否相同。

ETag 值有兩種，一種是強 ETag，一種是弱 ETag；

• 強 ETag 值，不管實體發生多麼細微的變化都會改變其值，通常的表示以下

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

• 弱 ETag 值，弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差別時纔會改變 ETag 值。這時，會在字段值最開始處附加 W/。

ETag: W/"0815"

Location

Location 響應標頭表示 URL 須要重定向頁面，它僅僅與 3xx(重定向) 或 201(已建立) 狀態響應一塊兒使用。下面是一個頁面重定向的過程

使用首部字段 Location 能夠將響應接受方引導至某個與請求 URI 位置不一樣的資源。

Location 和 content-Location 是不同的：Location 表示目標的重定向（或新建立資源的 URL）。然而 Content-Location 表示發生內容協商時用於訪問資源的直接 URL，而無須進一步協商。Location 是與響應相關聯的標頭，而 Content-Location 與返回的實體相關聯。

Location: /index.html

Proxy-Authenticate

HTTP 響應標頭 Proxy-Authenticate 會定義認證方法，應該使用身份驗證方法來訪問代理服務器後面的資源即客戶端。

它與 HTTP 客戶端和服務端之間的訪問認證行爲類似，不一樣之處在於 Proxy-Authenticate 的認證雙方是客戶端與代理之間。它的通常表示形式以下

Proxy-Authenticate: Basic
Proxy-Authenticate: Basic realm="Access to the internal site"

Retry-After

HTTP 響應標頭 Retry-After 告知客戶端須要在多久以後從新發送請求，使用此標頭主要有以下三種狀況

• 當發送 503(服務不可用) 響應時，這表示該服務預計沒法使用多長時間。
• 當發送 429(太多請求)響應時，這表示發出新請求以前要等待多長時間。
• 當發送重定向的響應像是 301(永久移動)，這表示在發出重定向請求以前要求用戶客戶端等待的最短期。

字段值能夠指定爲具體的日期時間，也能夠是建立響應後所持續的秒數，例如

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120

Server

服務器標頭包含有關原始服務器用來處理請求的軟件的信息。

應該避免使用過於冗長和詳細的 Server 值，由於它們可能會泄露內部實施細節，這可能會使攻擊者容易地發現並利用已知的安全漏洞。例以下面這種寫法

Server: Apache/2.4.1 (Unix)

Vary

Vary HTTP 響應標頭肯定如何匹配請求標頭，以決定是否可使用緩存的響應，而不是從原始服務器請求一個新的響應。

Vary: User-Agent

www-Authenticate

HTTP WWW-Authenticate 響應標頭定義了應用於得到對資源的訪問權限的身份驗證方法。WWW-Authenticate標頭與401未經受權的響應一塊兒發送。它的通常表示形式以下

WWW-Authenticate: Basic
WWW-Authenticate: Basic realm="Access to the staging site", charset="UTF-8"

Access-Control-Allow-Origin

一個返回的 HTTP 標頭可能會具備 Access-Control-Allow-Origin ，Access-Control-Allow-Origin 指定一個來源，它告訴瀏覽器容許該來源進行資源訪問。 不然-對於沒有憑據的請求 *通配符，告訴瀏覽器容許任何源訪問資源。例如，要容許源 https://mozilla.org 的代碼訪問資源，能夠指定：

Access-Control-Allow-Origin: https://mozilla.org
Vary: Origin

若是服務器指定單個來源而不是 * 通配符的話 ，則服務器還應在 Vary 響應標頭中包含 Origin ，以向客戶端指示 服務器響應將根據原始請求標頭的值而有所不一樣。

實體標頭

實體標頭用於HTTP請求和響應中，例如 Content-Length，Content-Language，Content-Encoding 的標頭是實體標頭。實體標頭不侷限於請求標頭或者響應標頭，下面例子中，Content-Length 是一個實體標頭，可是卻出如今了請求報文中

POST /myform.html HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Content-Length: 128

下面就來講一下實體標頭都包含哪些

• Allow
• Content-Encoding
• Content-Language
• Content-Length
• Content-Location
• Content-MD5
• Content-Range
• Content-Type
• Expires
• Last-Modified

下面來分開說一下

Allow

HTTP 實體標頭 Allow 列出了資源支持的方法集合。若是服務器響應405 Method Not Allowed狀態碼以指示可使用哪些請求方法，則必須發送此標頭。例如

Allow: GET, POST, HEAD

這段代碼表示服務器容許支持 GET 、POST 和 HEAD 方法。當服務器接收到不支持的 HTTP 方法時，會以狀態碼 405 Method Not Allowed 做爲響應返回。

Content-Encoding

咱們上面講過 Accept-Encoding 是客戶端但願服務端返回的內容編碼，可是實際上服務端返回給客戶端的內容編碼其實是經過 Content-Encoding 返回的。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。主要也是四種，和 Accept-Encoding 相同，它們是 gzip、compress、deflate、identity。下面是一組請求/響應內容壓縮編碼

Accept-Encoding: gzip, deflate
Content-Encoding: gzip

Content-Language

首部字段 Content-Language 會告知客戶端，服務器使用的天然語言是什麼，它與 Accept-Language 相對，下面是一組請求/響應使用的語言類型

Content-Language: de-DE, en-CA

Content-Length

Content-Length 的實體標頭指服務器發送給客戶端的實際主體大小，以字節爲單位。

Content-Length: 3000

如上，服務器返回給客戶端的主體大小是 3000 字節。

Content-Location

Content-Location 可不是對應 Accept-Location，由於沒有這個標頭哈哈哈哈。實際上 Content-Location 對應的是 Location。

Location 和 Content-Location 是不同的，Location 表示重定向的 URL，而 Content-Location 表示用於訪問資源的直接 URL，之後無需進行進一步的內容協商。Location 是與響應關聯的標頭，而 Content-Location 是與返回的數據相關聯的標頭，若是你很差理解，看一下下面的表格

Request header	Response header
Accept: application/json, text/json	Content-Location: /documents/foo.json
Accept: application/xml, text/xml	Content-Location: /documents/foo.xml
Accept: text/plain, text/*	Content-Location: /documents/foo.txt

Content-MD5

客戶端會對接收的報文主體執行相同的 MD5 算法，而後與首部字段 Content-MD5 的字段進行比較。

Content-MD5: e10adc3949ba59abbe56e057f20f883e

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

Content-Range

HTTP 的 Content-Range 響應標頭是針對範圍請求而設定的，返回響應時使用首部字段 Content-Range，可以告知客戶端響應實體的哪部分是符合客戶端請求的，字段以字節爲單位。它的通常表示以下

Content-Range: bytes 200-1000/67589

上段代碼表示從全部 67589 個字節中返回 200-1000 個字節的內容

Content-Type

HTTP 響應標頭 Content-Type 說明了實體內對象的媒體類型，和首部字段 Accept 同樣使用，表示服務器可以響應的媒體類型。

Expires

HTTP Expires 實體標頭包含 日期/時間，在該日期/時間以後，響應被認爲過時；在響應時間以內被認爲有效。特殊的值好比0表示過去的日期，表示資源已過時。

Expires: Wed, 21 Oct 2015 07:28:00 GMT

源服務器會將資源失效的日期或時間發送給客戶端，緩存服務器在接受到 Expires 的響應後，會判斷是否把緩存返回給客戶端。

源服務器不但願緩存服務器對資源緩存時，最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。可是，當首部字段 Cache-Control 有指定 max-age 指令時，比起首部字段 Expires，會優先處理 max-age 指令。

Last-Modified

實體字段 Last-Modified 指明資源的最後修改時間，它用做驗證器來肯定接收或存儲的資源是否相同。它的做用不如 ETag 那麼準確，它能夠做爲一種後備機制，包含 If-Modified-Since 或 If-Unmodified-Since 標頭的條件請求將使用此字段。它的通常表示以下

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

總結

本篇文章主要介紹了 HTTP 四種標頭的基本概念，可是並無涵蓋所有，畢竟 HTTP 標頭內容確實太多了，以上介紹的基本都是日常工做中經常使用的一些概念，下一篇文章預告 HTTP 的黑科技

文章參考：

https://developer.mozilla.org...

http://www.tcpipguide.com/fre...

http://www.tcpipguide.com/fre...

https://developer.mozilla.org...

《圖解 HTTP》

https://www.w3.org/Protocols/...

https://blog.csdn.net/qq_2940...

https://en.wikipedia.org/wiki...