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

TCP連接接

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

通用頭 General-Header

Request URL

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

Request Method

請求方法：
GET 請求指定的頁面信息堂湖，并返回實體主體
POST 向指定資源提交數(shù)據(jù)進行處理請求(例如提交表單或者上傳文件)周瞎。數(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：重定向--要完成請求必須進行更進一步的操作
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

請求的遠程地址 例如：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)在大部分瀏覽器默認所采用的。
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é)議先鱼、域名和端口都一致奸鬓，才會被瀏覽器認為是同域串远。
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> 標簽也可以指定 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> 標簽可用的 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樣式的標記
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//需要在表單中進行文件上傳時，就需要使用該格式

Connection

連接 值有兩個keep-alive和close 默認為keep-alive

Content-Length

內(nèi)容長度

Content-Encoding

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

Transfer-Encoding

值為chunked
是一個 HTTP 頭部字段，字面意思是「傳輸編碼」绿淋。實際上闷畸，HTTP 協(xié)議中還有另外一個頭部與編碼有關(guān)：Content-Encoding（內(nèi)容編碼）。Content-Encoding 通常用于對實體內(nèi)容進行壓縮編碼吞滞，目的是優(yōu)化傳輸佑菩，例如用 gzip 壓縮文本文件，能大幅減小體積裁赠。內(nèi)容編碼通常是選擇性的殿漠，例如 jpg / png 這類文件一般不開啟，因為圖片格式已經(jīng)是高度壓縮過的佩捞，再壓一遍沒什么效果不說還浪費 CPU绞幌。
而 Transfer-Encoding 則是用來改變報文格式，它不但不會減少實體內(nèi)容傳輸大小一忱，甚至還會使傳輸變大莲蜘，那它的作用是什么呢？本文接下來主要就是講這個帘营。我們先記住一點票渠，Content-Encoding 和 Transfer-Encoding 二者是相輔相成的，對于一個 HTTP 報文芬迄，很可能同時進行了內(nèi)容編碼和傳輸編碼问顷。
HTTP 運行在 TCP 連接之上，自然也有著跟 TCP 一樣的三次握手、慢啟動等特性杜窄，為了盡可能的提高 HTTP 性能肠骆，使用持久連接就顯得尤為重要了。為此羞芍，HTTP 協(xié)議引入了相應(yīng)的機制哗戈。
HTTP/1.0 的持久連接機制是后來才引入的，通過 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)語言生成。這時候要想準確獲取長度毁靶，只能開一個足夠大的 buffer胧奔，等內(nèi)容全部生成好再計算。但這樣做一方面需要更大的內(nèi)存開銷预吆，另一方面也會讓客戶端等更久龙填。
我們在做 WEB 性能優(yōu)化時，有一個重要的指標叫 TTFB（Time To First Byte）拐叉，它代表的是從客戶端發(fā)出請求到收到響應(yīng)的第一個字節(jié)所花費的時間觅够。大部分瀏覽器自帶的 Network 面板都可以看到這個指標，越短的 TTFB 意味著用戶可以越早看到頁面內(nèi)容巷嚣，體驗越好喘先。可想而知廷粒，服務(wù)端為了計算響應(yīng)實體長度而緩存所有內(nèi)容窘拯，跟更短的 TTFB 理念背道而馳红且。但在 HTTP 報文中，實體一定要在頭部之后涤姊，順序不能顛倒暇番，為此我們需要一個新的機制：不依賴頭部的長度信息，也能知道實體的邊界思喊。
Transfer-Encoding 正是用來解決上面這個問題的壁酬。歷史上 Transfer-Encoding 可以有多種取值，為此還引入了一個名為 TE 的頭部用來協(xié)商采用何種傳輸編碼恨课。但是最新的 HTTP 規(guī)范里舆乔，只定義了一種傳輸編碼：分塊編碼（chunked）。
分塊編碼相當(dāng)簡單剂公，在頭部加入 Transfer-Encoding: chunked 之后希俩，就代表這個報文采用了分塊編碼。這時纲辽，報文中的實體需要改為用一系列分塊來傳輸颜武。每個分塊包含十六進制的長度值和數(shù)據(jù)，長度值獨占一行拖吼，長度不包括它結(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 的分塊再進行 Content-Encoding。

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

Last-Modified

當(dāng)瀏覽器第一次請求某一個URL時增显，服務(wù)器的返回狀態(tài)是200，內(nèi)容是客戶端請求的資源脐帝，同時有一個Last-Modified的屬性標記此文件在服務(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

它用于指定所有緩存機制在整個請求/響應(yīng)鏈中必須服從的指令盒至。這些指令指定用于阻止緩存對請求或響應(yīng)造成不利干擾的行為。這些指令通常覆蓋默認緩存算法士修。緩存指令是單向的枷遂，即請求中存在一個指令不意味著響應(yīng)中將存在同一個指令。
常見的值
public//所有內(nèi)容都將被緩存(客戶端和代理服務(wù)器都可緩存)
private//默認值李命，內(nèi)容只緩存到私有緩存中(僅客戶端可以緩存登淘，代理服務(wù)器不可緩存)
no-cache//必須先與服務(wù)器確認返回的響應(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ù)器/代理以進行重新驗證
max-age=xxx (xxx is numeric)//緩存的內(nèi)容將在 xxx 秒后失效, 這個選項只在HTTP 1.1可用, 并如果和Last-Modified一起使用時, 優(yōu)先級較高

Expires

頭部字段提供一個日期和時間绅这，響應(yīng)在該日期和時間后被認為失效。
例如：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)容時的日期在給定的日期之前浑度，則認為該內(nèi)容沒有失效并從緩存中提取出來。反之鸦概，則認為該內(nèi)容失效箩张，緩存將采取一些措施。

Server

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

Vary

值為Accept-Encoding
告訴代理服務(wù)器緩存兩種版本的資源：壓縮和非壓縮窗市，這有助于避免一些公共代理不能正確地檢測Content-Encoding標頭的問題
當(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會存儲獨立的緩存條目，一個是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ù)器通信時對于長連接如何進行處理：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)遵循的緩存機制

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