引言：對于HTTP屬性的一些整理，數(shù)據(jù)請求和響應(yīng)就不再貼圖，隨意找個網(wǎng)站打開調(diào)試工具都可以看得到。注：HTTP版本1.1

TCP連接接

傳輸控制協(xié)議，是互聯(lián)網(wǎng)連接協(xié)議集的一種

通用頭 General-Header

Request URL

請求的地址 可以進(jìn)行參數(shù)和錨的傳遞

Request Method

請求方法：
GET 請求指定的頁面信息，并返回實體主體
POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請求(例如提交表單或者上傳文件)。數(shù)據(jù)被包含在請求體中。Post請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。
HEAD 類似于Get請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報頭。
OPTIONS 允許客戶端查看服務(wù)器的性能。
PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
DELETE 請求服務(wù)器刪除指定的頁面。
TRACE 回顯服務(wù)器收到的請求，主要用于測試或者診斷。
CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

Status Code

1xx：指示信息--表示請求已接收，繼續(xù)處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進(jìn)行更進(jìn)一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx：服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求

200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被服務(wù)器所理解
401 Unauthorized //請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden //服務(wù)器收到請求，但是拒絕提供服務(wù)
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請求，一段時間后可能恢復(fù)正常

Remote Address

請求的遠(yuǎn)程地址 例如：182.140.130.25:80

Referrer Policy

當(dāng)產(chǎn)生Http請求時，瀏覽器會給這些請求頭加上表示來源的Referrer字段。
No Referrer：任何情況下都不發(fā)送Referrer信息；
No Referrer When-downgrade：僅當(dāng)發(fā)生協(xié)議降級(如HTTPS頁面引入HTTP資源，從HTTPS頁面跳到HTTP等)時不發(fā)送Referrer信息。這個規(guī)則是現(xiàn)在大部分瀏覽器默認(rèn)所采用的。
Origin Only：發(fā)送只包含host部分的Referrer。棄用這個規(guī)則，無論是否發(fā)生協(xié)議降級，無論是本站鏈接還是站外鏈接，都會發(fā)送Referrer信息，但是之包含協(xié)議+host部分(不包含具體的路徑及參數(shù)等信息)。
Origin When Cross-origin：僅在發(fā)生跨域訪問時發(fā)送只包含host的Referrer，同域下還是完整的。它與Origin Only的區(qū)別是多判斷了是否Cross-origin。需要注意的是協(xié)議、域名和端口都一致，才會被瀏覽器認(rèn)為是同域。
Unsafe URL：無論是否發(fā)生協(xié)議降級，無論是本站鏈接還是站外鏈接，統(tǒng)統(tǒng)都發(fā)送Referrer信息。正如其名，這是最寬松而最不安全的策略。

CSP 響應(yīng)頭設(shè)置：Content-Security-Policy: referrer no-referrer|no-referrer-when-downgrade|origin|origin-when-cross-origin|unsafe-url;
CSP 的指令和指令值之間以空格分割，多個指令之間用英文分號分割。

通過 <meta> 標(biāo)簽也可以指定 Referrer 策略，同樣很簡單：
<meta name="referrer" content="no-referrer|no-referrer-when-downgrade|origin|origin-when-crossorigin|unsafe-url">

<a  referrer="no-referrer|origin|unsafe-url">xxx</a>
這種方式作用的只是這一個鏈接。并且，<a> 標(biāo)簽可用的 Referrer 策略只有三種：不傳、只傳 host 和都傳。另外，這樣針對單個鏈接設(shè)置的策略優(yōu)先級比 CSP 和 <meta> 要高。
需要注意的是：經(jīng)過我的測試，目前并沒有哪個瀏覽器實現(xiàn)了對 referrer
 屬性的支持。現(xiàn)階段，如果要針對單個鏈接去掉 Referrer，還是推薦使用下面這種支持度更好的寫法：
<a  rel="noreferrer">xxx</a>

響應(yīng)頭 Response Headers

HTTP/1.1 200 OK

一旦收到請求，服務(wù)器（向客戶端）發(fā)回一個狀態(tài)行
HTTP/1.1 代表http協(xié)議的版本這里是指目前最流行的1.1版本
200 OK指服務(wù)器返回客服端響應(yīng)狀態(tài)。(前面有解釋比較常用的幾個狀態(tài)所代表的含義)

Date

Date頭域表示消息發(fā)送的時間，緩存在評估相應(yīng)的新鮮度時要用到，時間的格式由RFC822定義。
例如:Date: Thu, 11 Jul 2015 15:33:24 GMT。

Age

當(dāng)代理服務(wù)器用自己緩存的實體去響應(yīng)請求時，用該頭部表明該實體從產(chǎn)生到現(xiàn)在經(jīng)過多長時間了。

Content-Type

內(nèi)容類型，是指服務(wù)器向客戶端傳輸?shù)臄?shù)據(jù)類型。決定文件接受方將以什么形式、什么編碼讀取這個文件。
列出幾個常用數(shù)據(jù)類型：
text/plain//無格式正文
text/html//html格式的正文
text/css//CSS樣式的標(biāo)記
image/jpeg//.jpg格式圖片
image/png//.png格式圖片
image/gif//.gif格式圖片
image/svg+xml//svg格式圖片
audio/mp4//mp4格式音頻
video/mp4//mp4格式視頻
application/javascript//服務(wù)器端處理js文件的mime類型
application/pdf//服務(wù)器端處理pdf文件的mime類型
application/zip//服務(wù)器端處理zip的mime類型
application/json//服務(wù)器端處理JSON數(shù)據(jù)的mime類型
application/msword//Word文檔格式
application/atom+xml//Atom XML聚合格式
multipart/form-data//需要在表單中進(jìn)行文件上傳時，就需要使用該格式

Connection

連接 值有兩個keep-alive和close 默認(rèn)為keep-alive

Content-Length

內(nèi)容長度

Content-Encoding

傳輸內(nèi)容編碼指服務(wù)器是用什么樣的方式處理數(shù)據(jù)傳輸?shù)娇蛻舳耍蛻舳艘允裁礃拥姆绞椒聪蛱幚韥淼玫皆紨?shù)據(jù)。
值：
deflate//一種壓縮算法，使用LZ77和哈弗曼進(jìn)行編碼，指的是在RFC1950說明的zlib格式。
compress//
gzip//一種格式，也是對deflate進(jìn)行的封裝.(最常用)

Transfer-Encoding

值為chunked
是一個 HTTP 頭部字段，字面意思是「傳輸編碼」。實際上，HTTP 協(xié)議中還有另外一個頭部與編碼有關(guān)：Content-Encoding（內(nèi)容編碼）。Content-Encoding 通常用于對實體內(nèi)容進(jìn)行壓縮編碼，目的是優(yōu)化傳輸，例如用 gzip 壓縮文本文件，能大幅減小體積。內(nèi)容編碼通常是選擇性的，例如 jpg / png 這類文件一般不開啟，因為圖片格式已經(jīng)是高度壓縮過的，再壓一遍沒什么效果不說還浪費(fèi) CPU。
而 Transfer-Encoding 則是用來改變報文格式，它不但不會減少實體內(nèi)容傳輸大小，甚至還會使傳輸變大，那它的作用是什么呢？本文接下來主要就是講這個。我們先記住一點(diǎn)，Content-Encoding 和 Transfer-Encoding 二者是相輔相成的，對于一個 HTTP 報文，很可能同時進(jìn)行了內(nèi)容編碼和傳輸編碼。
HTTP 運(yùn)行在 TCP 連接之上，自然也有著跟 TCP 一樣的三次握手、慢啟動等特性，為了盡可能的提高 HTTP 性能，使用持久連接就顯得尤為重要了。為此，HTTP 協(xié)議引入了相應(yīng)的機(jī)制。
HTTP/1.0 的持久連接機(jī)制是后來才引入的，通過 Connection: keep-alive 這個頭部來實現(xiàn)，服務(wù)端和客戶端都可以使用它告訴對方在發(fā)送完數(shù)據(jù)之后不需要斷開 TCP 連接，以備后用。HTTP/1.1 則規(guī)定所有連接都必須是持久的，除非顯式地在頭部加上 Connection: close。所以實際上，HTTP/1.1 中 Connection 這個頭部字段已經(jīng)沒有 keep-alive 這個取值了，但由于歷史原因，很多 Web Server 和瀏覽器，還是保留著給 HTTP/1.1 長連接發(fā)送 Connection: keep-alive 的習(xí)慣。
瀏覽器重用已經(jīng)打開的空閑持久連接，可以避開緩慢的三次握手，還可以避免遇上 TCP 慢啟動的擁塞適應(yīng)階段。
由于 Content-Length 字段必須真實反映實體長度，但實際應(yīng)用中，有些時候?qū)嶓w長度并沒那么好獲得，例如實體來自于網(wǎng)絡(luò)文件，或者由動態(tài)語言生成。這時候要想準(zhǔn)確獲取長度，只能開一個足夠大的 buffer，等內(nèi)容全部生成好再計算。但這樣做一方面需要更大的內(nèi)存開銷，另一方面也會讓客戶端等更久。
我們在做 WEB 性能優(yōu)化時，有一個重要的指標(biāo)叫 TTFB（Time To First Byte），它代表的是從客戶端發(fā)出請求到收到響應(yīng)的第一個字節(jié)所花費(fèi)的時間。大部分瀏覽器自帶的 Network 面板都可以看到這個指標(biāo)，越短的 TTFB 意味著用戶可以越早看到頁面內(nèi)容，體驗越好。可想而知，服務(wù)端為了計算響應(yīng)實體長度而緩存所有內(nèi)容，跟更短的 TTFB 理念背道而馳。但在 HTTP 報文中，實體一定要在頭部之后，順序不能顛倒，為此我們需要一個新的機(jī)制：不依賴頭部的長度信息，也能知道實體的邊界。
Transfer-Encoding 正是用來解決上面這個問題的。歷史上 Transfer-Encoding 可以有多種取值，為此還引入了一個名為 TE 的頭部用來協(xié)商采用何種傳輸編碼。但是最新的 HTTP 規(guī)范里，只定義了一種傳輸編碼：分塊編碼（chunked）。
分塊編碼相當(dāng)簡單，在頭部加入 Transfer-Encoding: chunked 之后，就代表這個報文采用了分塊編碼。這時，報文中的實體需要改為用一系列分塊來傳輸。每個分塊包含十六進(jìn)制的長度值和數(shù)據(jù)，長度值獨(dú)占一行，長度不包括它結(jié)尾的 CRLF（\r\n），也不包括分塊數(shù)據(jù)結(jié)尾的 CRLF。最后一個分塊長度值必須為 0，對應(yīng)的分塊數(shù)據(jù)沒有內(nèi)容，表示實體結(jié)束。
前面說過 Content-Encoding 和 Transfer-Encoding 二者經(jīng)常會結(jié)合來用，其實就是針對 Transfer-Encoding 的分塊再進(jìn)行 Content-Encoding。

(這一大段是其他作者關(guān)于Transfer-Encoding、Content-Encoding、Content-Length、Connection的相互理解。文章最后有鏈接)

Last-Modified

當(dāng)瀏覽器第一次請求某一個URL時，服務(wù)器的返回狀態(tài)是200，內(nèi)容是客戶端請求的資源，同時有一個Last-Modified的屬性標(biāo)記此文件在服務(wù)器端最后被修改的時間
例如：Last-Modified : Fri , 12 May 2006 18:53:33 GMT
當(dāng)瀏覽器第二次請求URL時，根據(jù)HTTP協(xié)議的規(guī)定，瀏覽器會向服務(wù)器發(fā)送If-Modified-Since報頭，詢問該時間之后文件是否有被修改過：If-Modified-Since:Fri , 12 May 2006 18:53:33 GMT
如果服務(wù)器端的資源沒有變化，則自動返回HTTP 304(Not changed)狀態(tài)碼，內(nèi)容為空，這樣就節(jié)省了傳輸數(shù)據(jù)量。當(dāng)服務(wù)器端代碼發(fā)生改變或者重啟服務(wù)器時，則重新發(fā)出資源，返回和第一次請求時類似。從而保證不向客戶端重復(fù)發(fā)出資源，也保證當(dāng)服務(wù)器有變化時，客戶端能夠得到最新的資源。

Cache-Control

它用于指定所有緩存機(jī)制在整個請求/響應(yīng)鏈中必須服從的指令。這些指令指定用于阻止緩存對請求或響應(yīng)造成不利干擾的行為。這些指令通常覆蓋默認(rèn)緩存算法。緩存指令是單向的，即請求中存在一個指令不意味著響應(yīng)中將存在同一個指令。
常見的值
public//所有內(nèi)容都將被緩存(客戶端和代理服務(wù)器都可緩存)
private//默認(rèn)值，內(nèi)容只緩存到私有緩存中(僅客戶端可以緩存，代理服務(wù)器不可緩存)
no-cache//必須先與服務(wù)器確認(rèn)返回的響應(yīng)是否被更改，然后才能使用該響應(yīng)來滿足后續(xù)對同一個網(wǎng)址的請求。因此，如果存在合適的驗證令牌 (ETag)，no-cache 會發(fā)起往返通信來驗證緩存的響應(yīng)，如果資源未被更改，可以避免下載。
no-store//所有內(nèi)容都不會被緩存到緩存或 Internet 臨時文件中
must-revalidation/proxy-revalidation//如果緩存的內(nèi)容失效，請求必須發(fā)送到服務(wù)器/代理以進(jìn)行重新驗證
max-age=xxx (xxx is numeric)//緩存的內(nèi)容將在 xxx 秒后失效, 這個選項只在HTTP 1.1可用, 并如果和Last-Modified一起使用時, 優(yōu)先級較高

Expires

頭部字段提供一個日期和時間，響應(yīng)在該日期和時間后被認(rèn)為失效。
例如：Expires:Thu, 22 Jun 2017 10:03:50 GMT
失效的緩存條目通常不會被緩存（無論是代理緩存還是用戶代理緩存）返回，除非首先通過原始服務(wù)器（或者擁有該實體的最新副本的中介緩存）驗證。（注意：cache-control max-age 和 s-maxage 將覆蓋 Expires 頭部。）
Expires 字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看內(nèi)容時的日期在給定的日期之前，則認(rèn)為該內(nèi)容沒有失效并從緩存中提取出來。反之，則認(rèn)為該內(nèi)容失效，緩存將采取一些措施。

Server

web server
服務(wù)器程序軟件名稱和版本
常見值為nginx Apache等

Vary

值為Accept-Encoding
告訴代理服務(wù)器緩存兩種版本的資源：壓縮和非壓縮，這有助于避免一些公共代理不能正確地檢測Content-Encoding標(biāo)頭的問題
當(dāng)瀏覽器發(fā)出一個請求時，會包含一些HTTP頭信息，服務(wù)器會根據(jù)這些頭信息決定返回什么樣的東西（這是一個移動客戶端嗎？它能否處理壓縮內(nèi)容？它是否需要特定的語言支持？）。
直接訪問是好的，但現(xiàn)在網(wǎng)絡(luò)使用了中間高速緩存（cache）和內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）。這就產(chǎn)生了一個問題，緩存如何使用頭信息決定返回什么？它能否復(fù)制服務(wù)器端的決策邏輯？
設(shè)想有兩個客戶，一個使用的舊瀏覽器不支持壓縮，一個使用新的瀏覽器支持壓縮，如果他們都請求同一個網(wǎng)頁，那么取決于誰先請求，壓縮或非壓縮版本便存儲在CDN上。這樣問題就出現(xiàn)了，舊瀏覽器請求常規(guī)網(wǎng)頁但獲得緩存的壓縮版本，而新瀏覽器會獲得緩存的非壓縮版本但嘗試去“解壓”它。無論哪種方式都是壞消息。解決方法是，源服務(wù)器回送“Vary: Accept-Encoding”。
現(xiàn)在的中間CDN會存儲獨(dú)立的緩存條目，一個是Accept-encoding: gzip ，而如果你沒有發(fā)送header，則存儲另一個。

請求頭 Request Headers

Accept

表示瀏覽器支持的MIME類型
例如：application/json, text/javascript, /; q=0.01

Accept-Encoding

瀏覽器支持的壓縮類型
例如：gzip, deflate

Accept-Language

瀏覽器支持的語言類型，并且優(yōu)先支持靠前的語言類型
例如：zh-CN,zh;q=0.8

Connection

當(dāng)瀏覽器與服務(wù)器通信時對于長連接如何進(jìn)行處理：close/keep-alive

Cookie

向服務(wù)器返回cookie，這些cookie是之前服務(wù)器發(fā)給瀏覽器的

Host

請求的服務(wù)器URL
例如：www.baidu.com

Referer

該頁面的來源URL
例如：http://www.baidu.com/

User-Agent

用戶使用的客戶端的一些必要信息，比如操作系統(tǒng)、瀏覽器及版本、瀏覽器渲染引擎等。
例如：Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

X-Requested-With

判斷是否為ajax請求如果沒有該屬性則說明為傳統(tǒng)請求

Cache-Control

指定請求和響應(yīng)遵循的緩存機(jī)制

Pragma

值為no-cache
意義與Cache-control相同 禁止緩存的指令。

獲取響應(yīng)頭全部以及響應(yīng)參數(shù)

$.ajax({
      type : "get" ,
      url : "https://www.zhihu.com/question/20795144",
      success : function (data, status, xhr) {
      //獲取響應(yīng)頭全部參數(shù)信息
      alert(xhr.getAllResponseHeaders());
      alert(xhr.getResponseHeader("Date"));
   }
});

參考鏈接：
HTTP簡介：http://www.cnblogs.com/ranyonsue/p/5984001.html
Referrer Policy：https://imququ.com/post/referrer-policy.html
Date：http://blog.csdn.net/xifeijian/article/details/46460631
content-type：http://baike.baidu.com/link?url=tnRXRpiJON2kcva3SMXts6hFqa55-FSbTH7IN8FbQPp4DgpXp4NPZxc8zuVTIuKPcIrc7xMP5XXldOM-FL5lZpkdTPJ-mG_fk7g-I5qi6b7
content-type：http://blog.csdn.net/blueheart20/article/details/45174399
Transfer-Encoding：https://imququ.com/post/transfer-encoding-header-in-http.html
Content-Encoding：http://guojuanjun.blog.51cto.com/277646/667067/
http://baike.baidu.com/link?
Cache-Control和Expires：http://baike.baidu.com/link?url=itzaYOBiXX82BU7Ly9fP1wbQ03RZxFMUItaewhdaNuQAyc9gD6KNKX0xTJCQdA6aMMd7GBWJ4MdWSVLGoT-UFO1ArMtJVFQK7JdDgLT0eri
Vary：Accept-Encoding：http://blog.csdn.net/dazhi_100/article/details/50061297
偶然發(fā)現(xiàn)的常用對照表也許對你有幫助：
http://tool.oschina.net/commons?type=5
http://www.cnblogs.com/Joans/p/3956490.html