重溫Http

司空見慣的Http，訪問網頁，請求接口，可謂無處不在，那麼什麼是Http呢？這篇文章，會給你們作一個簡單的總結，雖說，在開發中咱們即使不去了解，也不會影響到咱們，但對於常見的面試環節，這個不得不顯得尤其重要，知之總比不知強。

什麼是Http?

說白了，它是一個標準，好比你去作火車，須要憑藉火車票或有效證件才能去乘坐，那麼這就是標準，標準，是人制定的，須要按照它去執行的，要否則沒有這個標準，一我的有一我的的想法，這樣將會很是的混亂，一樣，咱們的Http，它也是一個標準，一個協議，是因特網上應用最爲普遍的一種網絡傳輸協議，全部的WWW文件都必須遵照這個標準。英文全稱，HyperText Transfer Protocol，翻譯爲：超文本傳輸協議，這個須要簡單的瞭解一下。

HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。

HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

Http1.0和Http1.1:

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

緩存處理，在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。

Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。

長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

Http的主要特色：

1、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

2、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

3.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

5、支持B/S及C/S模式。

B/S及C/S模式【擴展】

C/S模式：
　　C/S(Client/Server,客戶/服務器)方式的網絡計算模式，A、服務器負責管理數據庫的訪問，並對客戶機/服務器網絡結構中的數據庫安全層加鎖，進行保護；B、客戶機負責與用戶的交互，收集用戶信息，經過網絡向服務器發送請求。C、C/S模式中，資源明顯不對等，是一種「胖客戶機(fat client)」或「瘦服務器(thin server)」結構。D、客戶程序（前臺程序）在客戶機上運行，數據庫服務程序（後臺程序）在應用服務器上運行。
　　
B/S模式：

　　B/S(Browser/Server,瀏覽器/服務器)方式的網絡結構，A、客戶端統一採用瀏覽器如：Netscape和IE，經過Web瀏覽器向Web服務器提出請求，由Web服務器對數據庫進行操做，並將結果傳回客戶端。B、B/S結構簡化了客戶機的工做，但服務器將擔負更多的工做，對數據庫的訪問和應用程序的執行都將在這裏完成。即當瀏覽器發出請求後，其數據請求、加工、返回結果、動態網頁生成等工做所有由Web服務器完成。

Http之URL

HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。

http://www.vipandroid.cn/cert/get_news_speak.php?open_id=100#name

從上面的URL能夠看出，一個完整的URL包括如下幾部分：

1.協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符

2.域名部分：該URL的域名部分爲「www.vipandroid.cn」。一個URL中，也可使用IP地址做爲域名使用

3.端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口

4.虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/cert/」

5.文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「get_news_speak.php」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

6.錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分

7.參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「open_id=100」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符。

URI與URL區別

不少人會混淆這兩個名詞。

URL：(Uniform/Universal Resource Locator 的縮寫，統一資源定位符)。

URI：(Uniform Resource Identifier 的縮寫，統一資源標識符)（表明一種標準）。

關係：

URI 屬於 URL 更高層次的抽象，一種字符串文本標準。

就是說，URI 屬於父類，而 URL 屬於 URI 的子類。URL 是 URI 的一個子集。

兩者的區別在於，URI 表示請求服務器的路徑，定義這麼一個資源。而 URL 同時說明要如何訪問這個資源（http://）。

URI 示例

你們把瀏覽器地址欄裏訪問網站的地址認爲是URL就行了，也就是以HTTP/HTTPS開頭的URI子集。　

端口與URL標準格式　

何爲端口？端口(Port)，至關於一種數據的傳輸通道。用於接受某些數據，而後傳輸給相應的服務，而電腦將這些數據處理後，再將相應的回覆經過開啓的端口傳給對方。

端口的做用：由於 IP 地址與網絡服務的關係是一對多的關係。因此實際上因特網上是經過 IP 地址加上端口號來區分不一樣的服務的。

端口是經過端口號來標記的，端口號只有整數，範圍是從0 到65535。

URL標準格式

一般而言，咱們所熟悉的 URL 的常見定義格式爲：

scheme://host[:port#]/path/.../[;url-params][?query-string][#anchor]

scheme //有咱們很熟悉的http、https、ftp以及著名的ed2k，迅雷的thunder等。

host //HTTP服務器的IP地址或者域名

port# //HTTP服務器的默認端口是80，這種狀況下端口號能夠省略。若是使用了別的端口，必須指明，例如tomcat的默認端口是8080 http://localhost:8080/

path //訪問資源的路徑

url-params //所帶參數

query-string //發送給http服務器的數據

anchor //錨點定位

URN，uniform resource name，統一資源命名，是經過名字來標識資源，好比mailto:java-net@java.sun.com。

URI與URL的區別【總結】

URI(uniform resource identifier)，意思是統一資源標識符，用於惟一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻等都是用URI來定位的。

一個URI由三部分組成：

訪問資源的命名機制

存放資源的主機名

資源自身名稱，由路徑表示

URL(uniform resource locator)，意思是統一資源定位器，它是一種具體的URI。能夠用來標識一個資源，並且還指明瞭如何鎖定這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各類WWW客戶程序和服務器程序上。採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄 。

一個URL由三部分組成：

協議

存有資源的主機IP地址(包含端口號)

主機資源具體地址

請求方法

根據HTTP標準，HTTP請求可使用多種請求方法。

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

常見狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。

HTTP狀態碼的英文爲HTTP Status Code。

下面是常見的HTTP狀態碼：

200 - 請求成功

301 - 資源（網頁等）被永久轉移到其它URL

404 - 請求的資源（網頁等）不存在

500 - 內部服務器錯誤

HTTP之請求消息Request

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：

請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

請求行以一個方法符號開頭，以空格分開，後面跟着請求的URI和協議的版本。

Get請求例子，使用Charles抓取的request：

第一部分：請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本.

GET說明請求類型爲

GET /cert/get_news_speak.php?open_id=100 HTTP/1.1

爲要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。

第二部分：請求頭部，緊接着請求行（即第一行）以後的部分，用來講明服務器要使用的附加信息

從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,而且在每一個請求中自動發送等等

第三部分：空行，請求頭部後面的空行是必須的

即便第四部分的請求數據爲空，也必須有空行。

第四部分：請求數據也叫主體，能夠添加任意的其餘數據。

這個例子的請求數據爲空。

POST請求例子，使用Charles抓取的request：

第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求數據，第八行。

HTTP之響應消息Response

通常狀況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。

第一行爲狀態行，（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）

第二部分：消息報頭，用來講明客戶端要使用的一些附加信息

第二行和第三行爲消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的application/json,編碼類型是UTF-8

第三部分：空行，消息報頭後面的空行是必須的

第四部分：響應正文，服務器返回給客戶端的文本信息。

空行後面的html部分爲響應正文。

GET和POST的區別

GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.

GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.

GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值。

GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.

HTTP工做原理

HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

一、客戶端鏈接到Web服務器

一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。例如，http://www.oakcms.cn。

二、發送HTTP請求

經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

三、服務器接受請求並返回HTTP響應

Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

四、釋放鏈接TCP鏈接

若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

五、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

例如：在瀏覽器地址欄鍵入URL，按下回車以後會經歷如下流程：

一、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;

二、解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器創建TCP鏈接;

三、瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文做爲 TCP 三次握手的第三個報文的數據發送給服務器;

四、服務器對瀏覽器請求做出響應，並把對應的 html 文本發送給瀏覽器;

五、釋放 TCP鏈接;

六、瀏覽器將該 html 文本並顯示內容; 　

【補充】

經常使用的HTTP請求頭

協議頭	說明	示例	狀態
Accept	可接受的響應內容類型（Content-Types）。	Accept: text/plain	固定
Accept-Charset	可接受的字符集	Accept-Charset: utf-8	固定
Accept-Encoding	可接受的響應內容的編碼方式。	Accept-Encoding: gzip, deflate	固定
Accept-Language	可接受的響應內容語言列表。	Accept-Language: en-US	固定
Accept-Datetime	可接受的按照時間來表示的響應內容版本	Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT	臨時
Authorization	用於表示HTTP協議中須要認證資源的認證信息	Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE==	固定
Cache-Control	用來指定當前的請求/回覆中的，是否使用緩存機制。	Cache-Control: no-cache	固定
Connection	客戶端（瀏覽器）想要優先使用的鏈接類型	Connection: keep-alive Connection: Upgrade	固定
Cookie	由以前服務器經過Set-Cookie（見下文）設置的一個HTTP協議Cookie	Cookie: $Version=1; Skin=new;	固定：標準
Content-Length	以8進製表示的請求體的長度	Content-Length: 348	固定
Content-MD5	請求體的內容的二進制 MD5 散列值（數字簽名），以 Base64 編碼的結果	Content-MD5: oD8dH2sgSW50ZWdyaIEd9D==	廢棄
Content-Type	請求體的MIME類型 （用於POST和PUT請求中）	Content-Type: application/x-www-form-urlencoded	固定
Date	發送該消息的日期和時間（以RFC 7231中定義的"HTTP日期"格式來發送）	Date: Dec, 26 Dec 2015 17:30:00 GMT	固定
Expect	表示客戶端要求服務器作出特定的行爲	Expect: 100-continue	固定
From	發起此請求的用戶的郵件地址	From: user@itbilu.com	固定
Host	表示服務器的域名以及服務器所監聽的端口號。若是所請求的端口是對應的服務的標準端口（80），則端口號能夠省略。	Host: www.itbilu.com:80 Host: www.itbilu.com	固定
If-Match	僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操做。主要用於像 PUT 這樣的方法中，僅當從用戶上次更新某個資源後，該資源未被修改的狀況下，才更新該資源。	If-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Modified-Since	容許在對應的資源未被修改的狀況下返回304未修改	If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT	固定
If-None-Match	容許在對應的內容未被修改的狀況下返回304未修改（ 304 Not Modified ），參考 超文本傳輸協議 的實體標記	If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Range	若是該實體未被修改過，則向返回所缺乏的那一個或多個部分。不然，返回整個新的實體	If-Range: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Unmodified-Since	僅當該實體自某個特定時間以來未被修改的狀況下，才發送迴應。	If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT	固定
Max-Forwards	限制該消息可被代理及網關轉發的次數。	Max-Forwards: 10	固定
Origin	發起一個針對跨域資源共享的請求（該請求要求服務器在響應中加入一個Access-Control-Allow-Origin的消息頭，表示訪問控制所容許的來源）。	Origin: http://www.itbilu.com	固定: 標準
Pragma	與具體的實現相關，這些字段可能在請求/迴應鏈中的任什麼時候候產生。	Pragma: no-cache	固定
Proxy-Authorization	用於向代理進行認證的認證信息。	Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2==	固定
Range	表示請求某個實體的一部分，字節偏移以0開始。	Range: bytes=500-999	固定
Referer	表示瀏覽器所訪問的前一個頁面，能夠認爲是以前訪問頁面的連接將瀏覽器帶到了當前頁面。Referer實際上是Referrer這個單詞，但RFC製做標準時給拼錯了，後來也就將錯就錯使用Referer了。	Referer: http://itbilu.com/nodejs	固定
TE	瀏覽器預期接受的傳輸時的編碼方式：可以使用迴應協議頭Transfer-Encoding中的值（還可使用"trailers"表示數據傳輸時的分塊方式）用來表示瀏覽器但願在最後一個大小爲0的塊以後還接收到一些額外的字段。	TE: trailers,deflate	固定
User-Agent	瀏覽器的身份標識字符串	User-Agent: Mozilla/……	固定
Upgrade	要求服務器升級到一個高版本協議。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	固定
Via	告訴服務器，這個請求是由哪些代理髮出的。	Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1)	固定
Warning	一個通常性的警告，表示在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning	固定

經常使用的HTTP響應頭

響應頭	說明	示例	狀態
Access-Control-Allow-Origin	指定哪些網站能夠跨域源資源共享	Access-Control-Allow-Origin: *	臨時
Accept-Patch	指定服務器所支持的文檔補丁格式	Accept-Patch: text/example;charset=utf-8	固定
Accept-Ranges	服務器所支持的內容範圍	Accept-Ranges: bytes	固定
Age	響應對象在代理緩存中存在的時間，以秒爲單位	Age: 12	固定
Allow	對於特定資源的有效動做;	Allow: GET, HEAD	固定
Cache-Control	通知從服務器到客戶端內的全部緩存機制，表示它們是否能夠緩存這個對象及緩存有效時間。其單位爲秒	Cache-Control: max-age=3600	固定
Connection	針對該鏈接所預期的選項	Connection: close	固定
Content-Disposition	對已知MIME類型資源的描述，瀏覽器能夠根據這個響應頭決定是對返回資源的動做，如：將其下載或是打開。	Content-Disposition: attachment; filename="fname.ext"	固定
Content-Encoding	響應資源所使用的編碼類型。	Content-Encoding: gzip	固定
Content-Language	響就內容所使用的語言	Content-Language: zh-cn	固定
Content-Length	響應消息體的長度，用8進制字節表示	Content-Length: 348	固定
Content-Location	所返回的數據的一個候選位置	Content-Location: /index.htm	固定
Content-MD5	響應內容的二進制 MD5 散列值，以 Base64 方式編碼	Content-MD5: IDK0iSsgSW50ZWd0DiJUi==	已淘汰
Content-Range	若是是響應部分消息，表示屬於完整消息的哪一個部分	Content-Range: bytes 21010-47021/47022	固定
Content-Type	當前內容的MIME類型	Content-Type: text/html; charset=utf-8	固定
Date	此條消息被髮送時的日期和時間(以RFC 7231中定義的"HTTP日期"格式來表示)	Date: Tue, 15 Nov 1994 08:12:31 GMT	固定
ETag	對於某個資源的某個特定版本的一個標識符，一般是一個 消息散列	ETag: "737060cd8c284d8af7ad3082f209582d"	固定
Expires	指定一個日期/時間，超過該時間則認爲此迴應已通過期	Expires: Thu, 01 Dec 1994 16:00:00 GMT	固定: 標準
Last-Modified	所請求的對象的最後修改日期(按照 RFC 7231 中定義的「超文本傳輸協議日期」格式來表示)	Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT	固定
Link	用來表示與另外一個資源之間的類型關係，此類型關係是在RFC 5988中定義	Link: ; rel="alternate"	固定
Location	用於在進行重定向，或在建立了某個新資源時使用。	Location: http://www.itbilu.com/nodejs	固定
P3P	P3P策略相關設置	P3P: CP="This is not a P3P policy!	固定
Pragma	與具體的實現相關，這些響應頭可能在請求/迴應鏈中的不一樣時候產生不一樣的效果	Pragma: no-cache	固定
Proxy-Authenticate	要求在訪問代理時提供身份認證信息。	Proxy-Authenticate: Basic	固定
Public-Key-Pins	用於防止中間攻擊，聲明網站認證中傳輸層安全協議的證書散列值	Public-Key-Pins: max-age=2592000; pin-sha256="……";	固定
Refresh	用於重定向，或者當一個新的資源被建立時。默認會在5秒後刷新重定向。	Refresh: 5; url=http://itbilu.com
Retry-After	若是某個實體臨時不可用，那麼此協議頭用於告知客戶端稍後重試。其值能夠是一個特定的時間段(以秒爲單位)或一個超文本傳輸協議日期。	· 示例1:Retry-After: 120 · 示例2: Retry-After: Dec, 26 Dec 2015 17:30:00 GMT	固定
Server	服務器的名稱	Server: nginx/1.6.3	固定
Set-Cookie	設置HTTP cookie	Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1	固定: 標準
Status	通用網關接口的響應頭字段，用來講明當前HTTP鏈接的響應狀態。	Status: 200 OK
Trailer	Trailer用戶說明傳輸中分塊編碼的編碼信息	Trailer: Max-Forwards	固定
Transfer-Encoding	用表示實體傳輸給用戶的編碼形式。包括：chunked、compress、 deflate、gzip、identity。	Transfer-Encoding: chunked	固定
Upgrade	要求客戶端升級到另外一個高版本協議。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	固定
Vary	告知下游的代理服務器，應當如何對之後的請求協議頭進行匹配，以決定是否可以使用已緩存的響應內容而不是從新從原服務器請求新的內容。	Vary: *	固定
Via	告知代理服務器的客戶端，當前響應是經過什麼途徑發送的。	Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3)	固定
Warning	通常性警告，告知在實體內容體中可能存在錯誤。	Warning: 199 Miscellaneous warning	固定
WWW-Authenticate	表示在請求獲取這個實體時應當使用的認證模式。	WWW-Authenticate: Basic	固定