一、HTTP簡(jiǎn)介

HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫，“超文本”即不僅僅是文本，還可以傳輸HTML 文件, 圖片文件等。

HTTP協(xié)議工作于客戶端-服務(wù)端架構(gòu)為上。瀏覽器作為HTTP客戶端通過URL向HTTP服務(wù)端即WEB服務(wù)器發(fā)送所有請(qǐng)求。Web服務(wù)器根據(jù)接收到的請(qǐng)求后，向客戶端發(fā)送響應(yīng)信息。

二、主要特點(diǎn)

• 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
• 無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。
• 無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。
• 支持B/S及C/S模式。

三、基礎(chǔ)概念

URL

URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。

• URI（Uniform Resource Identifier，統(tǒng)一資源標(biāo)識(shí)符）
• URL（Uniform Resource Locator，統(tǒng)一資源定位符）
• URN（Uniform Resource Name，統(tǒng)一資源名稱）

三者的區(qū)別

• URI用來唯一的標(biāo)識(shí)一個(gè)資源。Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個(gè)來URI來標(biāo)識(shí)的。URI一般由三部組成：①訪問資源的命名機(jī)制 ②存放資源的主機(jī)名 ③資源自身的名稱，由路徑表示，著重強(qiáng)調(diào)于資源。
• URL是一種具體的URI，即URL可以用來標(biāo)識(shí)一個(gè)資源，而且還指明了如何locate這個(gè)資源。采用URL可以用一種統(tǒng)一的格式來描述各種信息資源，包括文件、服務(wù)器的地址和目錄等。URL一般由三部組成：①協(xié)議(或稱為服務(wù)方式) ②存有該資源的主機(jī)IP地址(有時(shí)也包括端口號(hào)) ③主機(jī)資源的具體地址。如目錄和文件名等
• URN是通過名字來標(biāo)識(shí)資源，比如mailto:[email protected]。

一個(gè)URL的例子

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個(gè)完整的URL包括以下幾部分：

1.協(xié)議部分： 該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁使用的是HTTP協(xié)議。在Internet中可以使用多種協(xié)議，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議。在"HTTP"后面的“//”為分隔符

2.域名部分： 該URL的域名部分為“www.aspxfans.com”。一個(gè)URL中，也可以使用IP地址作為域名使用

3.端口部分： 跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個(gè)URL必須的部分，如果省略端口部分，將采用默認(rèn)端口

4.虛擬目錄部分： 從域名后的第一個(gè)“/”開始到最后一個(gè)“/”為止，是虛擬目錄部分。虛擬目錄也不是一個(gè)URL必須的部分。本例中的虛擬目錄是“/news/”

5.文件名部分： 從域名后的最后一個(gè)“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個(gè)“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個(gè)“/”開始到結(jié)束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個(gè)URL必須的部分，如果省略該部分，則使用默認(rèn)的文件名

6.錨部分： 從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個(gè)URL必須的部分

7.參數(shù)部分： 從“？”開始到“#”為止之間的部分為參數(shù)部分，又稱搜索部分、查詢部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個(gè)參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

請(qǐng)求和響應(yīng)報(bào)文

1. 請(qǐng)求報(bào)文

請(qǐng)求報(bào)文由請(qǐng)求行（request line）、請(qǐng)求頭部（header）、空行和請(qǐng)求數(shù)據(jù)四個(gè)部分組成。

第一部分：請(qǐng)求行，用來說明請(qǐng)求類型,要訪問的資源以及所使用的HTTP版本

GET說明請(qǐng)求類型為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源，該行的最后一部分說明使用的是HTTP1.1版本。

第二部分：請(qǐng)求頭部，緊接著請(qǐng)求行（即第一行）之后的部分，用來說明服務(wù)器要使用的附加信息

從第二行起為請(qǐng)求頭部，HOST將指出請(qǐng)求的目的地.User-Agent,服務(wù)器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測(cè)邏輯的重要基礎(chǔ).該信息由你的瀏覽器來定義,并且在每個(gè)請(qǐng)求中自動(dòng)發(fā)送等等

第三部分：空行，請(qǐng)求頭部后面的空行是必須的

即使第四部分的請(qǐng)求數(shù)據(jù)為空，也必須有空行

第四部分：請(qǐng)求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)

2. 響應(yīng)報(bào)文

HTTP響應(yīng)也由四個(gè)部分組成，分別是：狀態(tài)行、消息報(bào)頭、空行和響應(yīng)正文。

第一部分：狀態(tài)行，由HTTP協(xié)議版本號(hào)， 狀態(tài)碼， 狀態(tài)消息 三部分組成。

第一行為狀態(tài)行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態(tài)碼為200，狀態(tài)消息為（ok）

第二部分：消息報(bào)頭，用來說明客戶端要使用的一些附加信息

第二行和第三行為消息報(bào)頭， Date:生成響應(yīng)的日期和時(shí)間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

第三部分：空行，消息報(bào)頭后面的空行是必須的

第四部分：響應(yīng)正文，服務(wù)器返回給客戶端的文本信息。

空行后面的html部分為響應(yīng)正文。

四、HTTP 方法

根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請(qǐng)求可以使用多種請(qǐng)求方法。HTTP1.0定義了三種請(qǐng)求方法：GET, POST 和 HEAD方法。HTTP1.1新增了五種請(qǐng)求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。后來又引入了PATCH方法，是對(duì)PUT方法的補(bǔ)充。

GET

請(qǐng)求指定的頁面信息，并返回實(shí)體主體。

HEAD

類似于get請(qǐng)求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報(bào)頭。主要用于確認(rèn) URL 的有效性以及資源更新的日期時(shí)間等。

POST

POST 主要用來傳輸數(shù)據(jù)，而 GET 主要用來獲取資源。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。

PUT

從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。由于自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件，因此存在安全性問題，一般不使用該方法。

DELETE

請(qǐng)求服務(wù)器刪除指定的頁面。與 PUT 功能相反，并且同樣不帶驗(yàn)證機(jī)制。

CONNECT

要求在與代理服務(wù)器通信時(shí)建立隧道

使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

CONNECT www.example.com:443 HTTP/1.1

OPTIONS

查詢支持的方法

查詢指定的 URL 能夠支持的方法。

會(huì)返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內(nèi)容。

TRACE

追蹤路徑

服務(wù)器會(huì)將通信路徑返回給客戶端。

發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個(gè)服務(wù)器就會(huì)減 1，當(dāng)數(shù)值為 0 時(shí)就停止傳輸。

通常不會(huì)使用 TRACE，并且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。主要用于測(cè)試或診斷。

PATCH

對(duì)資源進(jìn)行部分修改

PUT 也可以用于修改資源，但是只能完全替代原始資源，PATCH 允許部分修改。

五、HTTP 狀態(tài)碼

服務(wù)器返回的 響應(yīng)報(bào)文 中第一行為狀態(tài)行，包含了狀態(tài)碼以及原因短語，用來告知客戶端請(qǐng)求的結(jié)果。

1XX 信息

• 100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)響應(yīng)。

2XX 成功

• 200 OK
• 204 No Content ：請(qǐng)求已經(jīng)成功處理，但是返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息，而不需要返回?cái)?shù)據(jù)時(shí)使用。
• 206 Partial Content ：表示客戶端進(jìn)行了范圍請(qǐng)求，響應(yīng)報(bào)文包含由 Content-Range 指定范圍的實(shí)體內(nèi)容。

3XX 重定向

• 301 Moved Permanently ：永久性重定向
• 302 Found ：臨時(shí)性重定向
• 303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源。
• 注：雖然 HTTP 協(xié)議規(guī)定 301、302 狀態(tài)下重定向時(shí)不允許把 POST 方法改成 GET 方法，但是大多數(shù)瀏覽器都會(huì)在 301、302 和 303 狀態(tài)下的重定向把 POST 方法改成 GET 方法。
• 304 Not Modified ：如果請(qǐng)求報(bào)文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務(wù)器會(huì)返回 304 狀態(tài)碼。
• 307 Temporary Redirect ：臨時(shí)重定向，與 302 的含義類似，但是 307 要求瀏覽器不會(huì)把重定向請(qǐng)求的 POST 方法改成 GET 方法。

4XX 客戶端錯(cuò)誤

• 400 Bad Request ：請(qǐng)求報(bào)文中存在語法錯(cuò)誤。
• 401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC 認(rèn)證、DIGEST 認(rèn)證）。如果之前已進(jìn)行過一次請(qǐng)求，則表示用戶認(rèn)證失敗。
• 403 Forbidden ：請(qǐng)求被拒絕。
• 404 Not Found

5XX 服務(wù)器錯(cuò)誤

• 500 Internal Server Error ：服務(wù)器正在執(zhí)行請(qǐng)求時(shí)發(fā)生錯(cuò)誤。
• 503 Service Unavailable ：服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無法處理請(qǐng)求。

六、HTTP 首部

有 4 種類型的首部字段：通用首部字段、請(qǐng)求首部字段、響應(yīng)首部字段和實(shí)體首部字段。

各種首部字段及其含義如下（不需要全記，僅供查閱）：

通用首部字段

請(qǐng)求首部字段

響應(yīng)首部字段

實(shí)體首部字段

七、具體應(yīng)用

連接管理

1. 短連接與長(zhǎng)連接

當(dāng)瀏覽器訪問一個(gè)包含多張圖片的 HTML 頁面時(shí)，除了請(qǐng)求訪問 HTML 頁面資源，還會(huì)請(qǐng)求圖片資源。如果每進(jìn)行一次 HTTP 通信就要新建一個(gè) TCP 連接，那么開銷會(huì)很大。

長(zhǎng)連接只需要建立一次 TCP 連接就能進(jìn)行多次 HTTP 通信。

• 從 HTTP/1.1 開始默認(rèn)是長(zhǎng)連接的，如果要斷開連接，需要由客戶端或者服務(wù)器端提出斷開，使用 Connection : close；
• 在 HTTP/1.1 之前默認(rèn)是短連接的，如果需要使用長(zhǎng)連接，則使用 Connection : Keep-Alive。

那么http如何判斷一個(gè)報(bào)文結(jié)束？所有http不外乎2情況：

• 無entity body，則"\r\n\r\n"(兩個(gè)回車符)，判斷。
• 有entity body，則用"Content-Length“字段值判斷。

參考http消息包的結(jié)束標(biāo)記

2. 流水線

默認(rèn)情況下，HTTP 請(qǐng)求是按順序發(fā)出的，下一個(gè)請(qǐng)求只有在當(dāng)前請(qǐng)求收到響應(yīng)之后才會(huì)被發(fā)出。由于會(huì)受到網(wǎng)絡(luò)延遲和帶寬的限制，在下一個(gè)請(qǐng)求被發(fā)送到服務(wù)器之前，可能需要等待很長(zhǎng)時(shí)間。

流水線是在同一條長(zhǎng)連接上發(fā)出連續(xù)的請(qǐng)求，而不用等待響應(yīng)返回，這樣可以避免連接延遲。

Cookie

HTTP 協(xié)議是無狀態(tài)的，主要是為了讓 HTTP 協(xié)議盡可能簡(jiǎn)單，使得它能夠處理大量事務(wù)。HTTP/1.1 引入 Cookie 來保存狀態(tài)信息。

Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器之后向同一服務(wù)器再次發(fā)起請(qǐng)求時(shí)被攜帶上，用于告知服務(wù)端兩個(gè)請(qǐng)求是否來自同一瀏覽器。由于之后每次請(qǐng)求都會(huì)需要攜帶 Cookie 數(shù)據(jù)，因此會(huì)帶來額外的性能開銷（尤其是在移動(dòng)環(huán)境下）。

Cookie 曾一度用于客戶端數(shù)據(jù)的存儲(chǔ)，因?yàn)楫?dāng)時(shí)并沒有其它合適的存儲(chǔ)辦法而作為唯一的存儲(chǔ)手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲(chǔ)方式，Cookie 漸漸被淘汰。新的瀏覽器 API 已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲(chǔ)到本地，如使用 Web storage API（本地存儲(chǔ)和會(huì)話存儲(chǔ)）或 IndexedDB。

1. 用途

• 會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)、購(gòu)物車、游戲分?jǐn)?shù)或其它需要記錄的信息）
• 個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）
• 瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

2. 創(chuàng)建過程

服務(wù)器發(fā)送的響應(yīng)報(bào)文包含 Set-Cookie 首部字段，客戶端得到響應(yīng)報(bào)文后把 Cookie 內(nèi)容保存到瀏覽器中。

HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry[page content]

客戶端之后對(duì)同一個(gè)服務(wù)器發(fā)送請(qǐng)求時(shí)，會(huì)從瀏覽器中取出 Cookie 信息并通過 Cookie 請(qǐng)求首部字段發(fā)送給服務(wù)器。

GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry

3. 分類

• 會(huì)話期 Cookie：瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除，也就是說它僅在會(huì)話期內(nèi)有效。
• 持久性 Cookie：指定一個(gè)特定的過期時(shí)間（Expires）或有效期（max-age）之后就成為了持久性的 Cookie。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

4. 作用域

Domain 標(biāo)識(shí)指定了哪些主機(jī)可以接受 Cookie。如果不指定，默認(rèn)為當(dāng)前文檔的主機(jī)（不包含子域名）。如果指定了 Domain，則一般包含子域名。例如，如果設(shè)置 Domain=mozilla.org，則 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path 標(biāo)識(shí)指定了主機(jī)下的哪些路徑可以接受 Cookie（該 URL 路徑必須存在于請(qǐng)求 URL 中）。以字符 %x2F ("/") 作為路徑分隔符，子路徑也會(huì)被匹配。例如，設(shè)置 Path=/docs，則以下地址都會(huì)匹配：

• /docs
• /docs/Web/
• /docs/Web/HTTP

5. JavaScript

通過 document.cookie 屬性可創(chuàng)建新的 Cookie，也可通過該屬性訪問非 HttpOnly 標(biāo)記的 Cookie。

document.cookie = "yummy_cookie=choco";document.cookie = "tasty_cookie=strawberry";console.log(document.cookie);

6. HttpOnly

標(biāo)記為 HttpOnly 的 Cookie 不能被 JavaScript 腳本調(diào)用。跨站腳本攻擊 (XSS) 常常使用 JavaScript 的 document.cookie API 竊取用戶的 Cookie 信息，因此使用 HttpOnly 標(biāo)記可以在一定程度上避免 XSS 攻擊。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

7. Secure

標(biāo)記為 Secure 的 Cookie 只能通過被 HTTPS 協(xié)議加密過的請(qǐng)求發(fā)送給服務(wù)端。但即便設(shè)置了 Secure 標(biāo)記，敏感信息也不應(yīng)該通過 Cookie 傳輸，因?yàn)?Cookie 有其固有的不安全性，Secure 標(biāo)記也無法提供確實(shí)的安全保障。

8. Session

除了可以將用戶信息通過 Cookie 存儲(chǔ)在用戶瀏覽器中，也可以利用 Session 存儲(chǔ)在服務(wù)器端，存儲(chǔ)在服務(wù)器端的信息更加安全。

Session 可以存儲(chǔ)在服務(wù)器上的文件、數(shù)據(jù)庫(kù)或者內(nèi)存中。也可以將 Session 存儲(chǔ)在 Redis 這種內(nèi)存型數(shù)據(jù)庫(kù)中，效率會(huì)更高。

使用 Session 維護(hù)用戶登錄狀態(tài)的過程如下：

• 用戶進(jìn)行登錄時(shí)，用戶提交包含用戶名和密碼的表單，放入 HTTP 請(qǐng)求報(bào)文中；
• 服務(wù)器驗(yàn)證該用戶名和密碼，如果正確則把用戶信息存儲(chǔ)到 Redis 中，它在 Redis 中的 Key 稱為 Session ID；
• 服務(wù)器返回的響應(yīng)報(bào)文的 Set-Cookie 首部字段包含了這個(gè) Session ID，客戶端收到響應(yīng)報(bào)文之后將該 Cookie 值存入瀏覽器中；
• 客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求時(shí)會(huì)包含該 Cookie 值，服務(wù)器收到之后提取出 Session ID，從 Redis 中取出用戶信息，繼續(xù)之前的業(yè)務(wù)操作。

應(yīng)該注意 Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取，那么就不能產(chǎn)生一個(gè)容易被猜到的 Session ID 值。此外，還需要經(jīng)常重新生成 Session ID。在對(duì)安全性要求極高的場(chǎng)景下，例如轉(zhuǎn)賬等操作，除了使用 Session 管理用戶狀態(tài)之外，還需要對(duì)用戶進(jìn)行重新驗(yàn)證，比如重新輸入密碼，或者使用短信驗(yàn)證碼等方式。

9. 瀏覽器禁用 Cookie

此時(shí)無法使用 Cookie 來保存用戶信息，只能使用 Session。除此之外，不能再將 Session ID 存放到 Cookie 中，而是使用 URL 重寫技術(shù)，將 Session ID 作為 URL 的參數(shù)進(jìn)行傳遞。

10. Cookie 與 Session 選擇

• Cookie 只能存儲(chǔ) ASCII 碼字符串，而 Session 則可以存取任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復(fù)雜性時(shí)首選 Session；
• Cookie 存儲(chǔ)在瀏覽器中，容易被惡意查看。如果非要將一些隱私數(shù)據(jù)存在 Cookie 中，可以將 Cookie 值進(jìn)行加密，然后在服務(wù)器進(jìn)行解密；
• 對(duì)于大型網(wǎng)站，如果用戶所有的信息都存儲(chǔ)在 Session 中，那么開銷是非常大的，因此不建議將所有的用戶信息都存儲(chǔ)到 Session 中。

緩存

1. 優(yōu)點(diǎn)

• 緩解服務(wù)器壓力；
• 降低客戶端獲取資源的延遲：緩存通常位于內(nèi)存中，讀取緩存的速度更快。并且緩存在地理位置上也有可能比源服務(wù)器來得近，例如瀏覽器緩存。

2. 實(shí)現(xiàn)方法

• 讓代理服務(wù)器進(jìn)行緩存；
• 讓客戶端瀏覽器進(jìn)行緩存。

3. Cache-Control

HTTP/1.1 通過 Cache-Control 首部字段來控制緩存。

3.1 禁止進(jìn)行緩存

no-store 指令規(guī)定不能對(duì)請(qǐng)求或響應(yīng)的任何一部分進(jìn)行緩存。

Cache-Control: no-store

3.2 強(qiáng)制確認(rèn)緩存

no-cache 指令規(guī)定緩存服務(wù)器需要先向源服務(wù)器驗(yàn)證緩存資源的有效性，只有當(dāng)緩存資源有效才將能使用該緩存對(duì)客戶端的請(qǐng)求進(jìn)行響應(yīng)。

Cache-Control: no-cache

3.3 私有緩存和公共緩存

private 指令規(guī)定了將資源作為私有緩存，只能被單獨(dú)用戶所使用，一般存儲(chǔ)在用戶瀏覽器中。

Cache-Control: private

public 指令規(guī)定了將資源作為公共緩存，可以被多個(gè)用戶所使用，一般存儲(chǔ)在代理服務(wù)器中。

Cache-Control: public

3.4 緩存過期機(jī)制

max-age 指令出現(xiàn)在請(qǐng)求報(bào)文中，并且緩存資源的緩存時(shí)間小于該指令指定的時(shí)間，那么就能接受該緩存。

max-age 指令出現(xiàn)在響應(yīng)報(bào)文中，表示緩存資源在緩存服務(wù)器中保存的時(shí)間。

Cache-Control: max-age=31536000

Expires 首部字段也可以用于告知緩存服務(wù)器該資源什么時(shí)候會(huì)過期。

Expires: Wed, 04 Jul 2012 08:26:05 GMT

• 在 HTTP/1.1 中，會(huì)優(yōu)先處理 max-age 指令；
• 在 HTTP/1.0 中，max-age 指令會(huì)被忽略掉。

4. 緩存驗(yàn)證

需要先了解 ETag 首部字段的含義，它是資源的唯一標(biāo)識(shí)。URL 不能唯一表示資源，例如 http://www.google.com/ 有中文和英文兩個(gè)資源，只有 ETag 才能對(duì)這兩個(gè)資源進(jìn)行唯一標(biāo)識(shí)。

ETag: "82e22293907ce725faf67773957acd12"

可以將緩存資源的 ETag 值放入 If-None-Match 首部，服務(wù)器收到該請(qǐng)求后，判斷緩存資源的 ETag 值和資源的最新 ETag 值是否一致，如果一致則表示緩存資源有效，返回 304 Not Modified。

If-None-Match: "82e22293907ce725faf67773957acd12"

Last-Modified 首部字段也可以用于緩存驗(yàn)證，它包含在源服務(wù)器發(fā)送的響應(yīng)報(bào)文中，指示源服務(wù)器對(duì)資源的最后修改時(shí)間。但是它是一種弱校驗(yàn)器，因?yàn)橹荒芫_到一秒，所以它通常作為 ETag 的備用方案。如果響應(yīng)首部字段里含有這個(gè)信息，客戶端可以在后續(xù)的請(qǐng)求中帶上 If-Modified-Since 來驗(yàn)證緩存。服務(wù)器只在所請(qǐng)求的資源在給定的日期時(shí)間之后對(duì)內(nèi)容進(jìn)行過修改的情況下才會(huì)將資源返回，狀態(tài)碼為 200 OK。如果請(qǐng)求的資源從那時(shí)起未經(jīng)修改，那么返回一個(gè)不帶有消息主體的 304 Not Modified 響應(yīng)。

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

內(nèi)容協(xié)商

通過內(nèi)容協(xié)商返回最合適的內(nèi)容，例如根據(jù)瀏覽器的默認(rèn)語言選擇返回中文界面還是英文界面。

1. 類型

1.1 服務(wù)端驅(qū)動(dòng)型

客戶端設(shè)置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language，服務(wù)器根據(jù)這些字段返回特定的資源。

它存在以下問題：

• 服務(wù)器很難知道客戶端瀏覽器的全部信息；
• 客戶端提供的信息相當(dāng)冗長(zhǎng)（HTTP/2 協(xié)議的首部壓縮機(jī)制緩解了這個(gè)問題），并且存在隱私風(fēng)險(xiǎn)（HTTP 指紋識(shí)別技術(shù)）；
• 給定的資源需要返回不同的展現(xiàn)形式，共享緩存的效率會(huì)降低，而服務(wù)器端的實(shí)現(xiàn)會(huì)越來越復(fù)雜。

1.2 代理驅(qū)動(dòng)型

服務(wù)器返回 300 Multiple Choices 或者 406 Not Acceptable，客戶端從中選出最合適的那個(gè)資源。

2. Vary

Vary: Accept-Language

在使用內(nèi)容協(xié)商的情況下，只有當(dāng)緩存服務(wù)器中的緩存滿足內(nèi)容協(xié)商條件時(shí)，才能使用該緩存，否則應(yīng)該向源服務(wù)器請(qǐng)求該資源。

例如，一個(gè)客戶端發(fā)送了一個(gè)包含 Accept-Language 首部字段的請(qǐng)求之后，源服務(wù)器返回的響應(yīng)包含 Vary: Accept-Language 內(nèi)容，緩存服務(wù)器對(duì)這個(gè)響應(yīng)進(jìn)行緩存之后，在客戶端下一次訪問同一個(gè) URL 資源，并且 Accept-Language 與緩存中的對(duì)應(yīng)的值相同時(shí)才會(huì)返回該緩存。

內(nèi)容編碼

內(nèi)容編碼將實(shí)體主體進(jìn)行壓縮，從而減少傳輸?shù)臄?shù)據(jù)量。

常用的內(nèi)容編碼有：gzip、compress、deflate、identity。

瀏覽器發(fā)送 Accept-Encoding 首部，其中包含有它所支持的壓縮算法，以及各自的優(yōu)先級(jí)。服務(wù)器則從中選擇一種，使用該算法對(duì)響應(yīng)的消息主體進(jìn)行壓縮，并且發(fā)送 Content-Encoding 首部來告知瀏覽器它選擇了哪一種算法。由于該內(nèi)容協(xié)商過程是基于編碼類型來選擇資源的展現(xiàn)形式的，在響應(yīng)的 Vary 首部至少要包含 Content-Encoding。

范圍請(qǐng)求

如果網(wǎng)絡(luò)出現(xiàn)中斷，服務(wù)器只發(fā)送了一部分?jǐn)?shù)據(jù)，范圍請(qǐng)求可以使得客戶端只請(qǐng)求服務(wù)器未發(fā)送的那部分?jǐn)?shù)據(jù)，從而避免服務(wù)器重新發(fā)送所有數(shù)據(jù)。

1. Range

在請(qǐng)求報(bào)文中添加 Range 首部字段指定請(qǐng)求的范圍。

GET /z4d4kWk.jpg HTTP/1.1Host: i.imgur.comRange: bytes=0-1023

請(qǐng)求成功的話服務(wù)器返回的響應(yīng)包含 206 Partial Content 狀態(tài)碼。

HTTP/1.1 206 Partial ContentContent-Range: bytes 0-1023/146515Content-Length: 1024...(binary content)

2. Accept-Ranges

響應(yīng)首部字段 Accept-Ranges 用于告知客戶端是否能處理范圍請(qǐng)求，可以處理使用 bytes，否則使用 none。

Accept-Ranges: bytes

3. 響應(yīng)狀態(tài)碼

• 在請(qǐng)求成功的情況下，服務(wù)器會(huì)返回 206 Partial Content 狀態(tài)碼。
• 在請(qǐng)求的范圍越界的情況下，服務(wù)器會(huì)返回 416 Requested Range Not Satisfiable 狀態(tài)碼。
• 在不支持范圍請(qǐng)求的情況下，服務(wù)器會(huì)返回 200 OK 狀態(tài)碼。

分塊傳輸編碼

Chunked Transfer Coding，可以把數(shù)據(jù)分割成多塊，讓瀏覽器逐步顯示頁面。

多部分對(duì)象集合

一份報(bào)文主體內(nèi)可含有多種類型的實(shí)體同時(shí)發(fā)送，每個(gè)部分之間用 boundary 字段定義的分隔符進(jìn)行分隔，每個(gè)部分都可以有首部字段。

例如，上傳多個(gè)表單時(shí)可以使用如下方式：

Content-Type: multipart/form-data; boundary=AaB03x--AaB03xContent-Disposition: form-data; name="submit-name"Larry--AaB03xContent-Disposition: form-data; name="files"; filename="file1.txt"Content-Type: text/plain... contents of file1.txt ...--AaB03x--

虛擬主機(jī)

HTTP/1.1 使用虛擬主機(jī)技術(shù)，使得一臺(tái)服務(wù)器擁有多個(gè)域名，并且在邏輯上可以看成多個(gè)服務(wù)器。

通信數(shù)據(jù)轉(zhuǎn)發(fā)

1. 代理

代理服務(wù)器接受客戶端的請(qǐng)求，并且轉(zhuǎn)發(fā)給其它服務(wù)器。

使用代理的主要目的是：

• 緩存
• 負(fù)載均衡
• 網(wǎng)絡(luò)訪問控制
• 訪問日志記錄

代理服務(wù)器分為正向代理和反向代理兩種：

• 用戶察覺得到正向代理的存在。

• 而反向代理一般位于內(nèi)部網(wǎng)絡(luò)中，用戶察覺不到。

2. 網(wǎng)關(guān)

與代理服務(wù)器不同的是，網(wǎng)關(guān)服務(wù)器會(huì)將 HTTP 轉(zhuǎn)化為其它協(xié)議進(jìn)行通信，從而請(qǐng)求其它非 HTTP 服務(wù)器的服務(wù)。

3. 隧道

使用 SSL 等加密手段，在客戶端和服務(wù)器之間建立一條安全的通信線路。

八、HTTPs

HTTP 有以下安全性問題：

• 使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽；
• 不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝；
• 無法證明報(bào)文的完整性，報(bào)文有可能遭篡改。

HTTPs 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是說 HTTPs 使用了隧道進(jìn)行通信。

通過使用 SSL，HTTPs 具有了加密（防竊聽）、認(rèn)證（防偽裝）和完整性保護(hù)（防篡改）。

加密

1. 對(duì)稱密鑰加密

對(duì)稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。

• 優(yōu)點(diǎn)：運(yùn)算速度快；
• 缺點(diǎn)：無法安全地將密鑰傳輸給通信方。

2.非對(duì)稱密鑰加密

非對(duì)稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不同的密鑰。

公開密鑰所有人都可以獲得，通信發(fā)送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進(jìn)行加密，接收方收到通信內(nèi)容后使用私有密鑰解密。

非對(duì)稱密鑰除了用來加密，還可以用來進(jìn)行簽名。因?yàn)樗接忻荑€無法被其他人獲取，因此通信發(fā)送方使用其私有密鑰進(jìn)行簽名，通信接收方使用發(fā)送方的公開密鑰對(duì)簽名進(jìn)行解密，就能判斷這個(gè)簽名是否正確。

• 優(yōu)點(diǎn)：可以更安全地將公開密鑰傳輸給通信發(fā)送方；
• 缺點(diǎn)：運(yùn)算速度慢。

3. HTTPs 采用的加密方式

HTTPs 采用混合的加密機(jī)制，使用非對(duì)稱密鑰加密用于傳輸對(duì)稱密鑰來保證傳輸過程的安全性，之后使用對(duì)稱密鑰加密進(jìn)行通信來保證通信過程的效率。（下圖中的 Session Key 就是對(duì)稱密鑰）

認(rèn)證

通過使用 證書 來對(duì)通信方進(jìn)行認(rèn)證。

數(shù)字證書認(rèn)證機(jī)構(gòu)（CA，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)。

服務(wù)器的運(yùn)營(yíng)人員向 CA 提出公開密鑰的申請(qǐng)，CA 在判明提出申請(qǐng)者的身份之后，會(huì)對(duì)已申請(qǐng)的公開密鑰做數(shù)字簽名，然后分配這個(gè)已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起。

進(jìn)行 HTTPs 通信時(shí)，服務(wù)器會(huì)把證書發(fā)送給客戶端。客戶端取得其中的公開密鑰之后，先使用數(shù)字簽名進(jìn)行驗(yàn)證，如果驗(yàn)證通過，就可以開始通信了。

通信開始時(shí)，客戶端需要使用服務(wù)器的公開密鑰將自己的私有密鑰傳輸給服務(wù)器，之后再進(jìn)行對(duì)稱密鑰加密。

完整性保護(hù)

SSL 提供報(bào)文摘要功能來進(jìn)行完整性保護(hù)。

HTTP 也提供了 MD5 報(bào)文摘要功能，但不是安全的。例如報(bào)文內(nèi)容被篡改之后，同時(shí)重新計(jì)算 MD5 的值，通信接收方是無法意識(shí)到發(fā)生了篡改。

HTTPs 的報(bào)文摘要功能之所以安全，是因?yàn)樗Y(jié)合了加密和認(rèn)證這兩個(gè)操作。試想一下，加密之后的報(bào)文，遭到篡改之后，也很難重新計(jì)算報(bào)文摘要，因?yàn)闊o法輕易獲取明文。

HTTPs 的缺點(diǎn)

• 因?yàn)樾枰M(jìn)行加密解密等過程，因此速度會(huì)更慢；
• 需要支付證書授權(quán)的高額費(fèi)用。

九、HTTP/2.0

HTTP/1.x 缺陷

HTTP/1.x 實(shí)現(xiàn)簡(jiǎn)單是以犧牲性能為代價(jià)的：

• 客戶端需要使用多個(gè)連接才能實(shí)現(xiàn)并發(fā)和縮短延遲；
• 不會(huì)壓縮請(qǐng)求和響應(yīng)首部，從而導(dǎo)致不必要的網(wǎng)絡(luò)流量；
• 不支持有效的資源優(yōu)先級(jí)，致使底層 TCP 連接的利用率低下。

二進(jìn)制分幀層

HTTP/2.0 將報(bào)文分成 HEADERS 幀和 DATA 幀，它們都是二進(jìn)制格式的。

在通信過程中，只會(huì)有一個(gè) TCP 連接存在，它承載了任意數(shù)量的雙向數(shù)據(jù)流（Stream）。

• 一個(gè)數(shù)據(jù)流（Stream）都有一個(gè)唯一標(biāo)識(shí)符和可選的優(yōu)先級(jí)信息，用于承載雙向信息。
• 消息（Message）是與邏輯請(qǐng)求或響應(yīng)對(duì)應(yīng)的完整的一系列幀。
• 幀（Frame）是最小的通信單位，來自不同數(shù)據(jù)流的幀可以交錯(cuò)發(fā)送，然后再根據(jù)每個(gè)幀頭的數(shù)據(jù)流標(biāo)識(shí)符重新組裝。

服務(wù)端推送

HTTP/2.0 在客戶端請(qǐng)求一個(gè)資源時(shí)，會(huì)把相關(guān)的資源一起發(fā)送給客戶端，客戶端就不需要再次發(fā)起請(qǐng)求了。例如客戶端請(qǐng)求 page.html 頁面，服務(wù)端就把 script.js 和 style.css 等與之相關(guān)的資源一起發(fā)給客戶端。

首部壓縮

HTTP/1.1 的首部帶有大量信息，而且每次都要重復(fù)發(fā)送。

HTTP/2.0 要求客戶端和服務(wù)器同時(shí)維護(hù)和更新一個(gè)包含之前見過的首部字段表，從而避免了重復(fù)傳輸。

不僅如此，HTTP/2.0 也使用 Huffman 編碼對(duì)首部字段進(jìn)行壓縮。

十、HTTP/1.1 新特性

• 詳細(xì)內(nèi)容請(qǐng)見上文
• 默認(rèn)是長(zhǎng)連接
• 支持流水線
• 支持同時(shí)打開多個(gè) TCP 連接
• 支持虛擬主機(jī)
• 新增狀態(tài)碼 100
• 支持分塊傳輸編碼
• 新增緩存處理指令 max-age

十一、GET 和 POST 比較

數(shù)據(jù)傳輸方式

GET提交的數(shù)據(jù)會(huì)放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456。POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中。(一個(gè)形象地比喻是：當(dāng)執(zhí)行GET請(qǐng)求的時(shí)候，要給汽車貼上GET的標(biāo)簽（設(shè)置method為GET），而且要求把傳送的數(shù)據(jù)放在車頂上（url中）以方便記錄。如果是POST請(qǐng)求，就要在車上貼上POST的標(biāo)簽，并把貨物放在車廂里。)

因?yàn)?URL 只支持 ASCII 碼，因此 GET 的參數(shù)中如果存在中文等字符就需要先進(jìn)行編碼。例如 中文 會(huì)轉(zhuǎn)換為 %E4%B8%AD%E6%96%87，而空格會(huì)轉(zhuǎn)換為 %20。POST 參考支持標(biāo)準(zhǔn)字符集。

保密性

GET方式提交數(shù)據(jù)，會(huì)帶來安全問題，比如一個(gè)登錄頁面，通過GET方式提交數(shù)據(jù)時(shí)，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺(tái)機(jī)器，就可以從歷史記錄獲得該用戶的賬號(hào)和密碼

但是，不能因?yàn)?POST 參數(shù)存儲(chǔ)在實(shí)體主體中就認(rèn)為它的安全性更高，因?yàn)檎諛涌梢酝ㄟ^一些抓包工具（Fiddler）查看。

冪等性

冪等的 HTTP 方法，同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的。換句話說就是，冪等方法不應(yīng)該具有副作用（統(tǒng)計(jì)用途除外）。

所有的安全方法也都是冪等的。

在正確實(shí)現(xiàn)的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。

傳輸數(shù)據(jù)的大小

首先聲明：HTTP協(xié)議沒有對(duì)傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒有對(duì)URL長(zhǎng)度進(jìn)行限制。

而在實(shí)際開發(fā)中存在的限制主要有：

**GET:**特定瀏覽器和服務(wù)器對(duì)URL長(zhǎng)度有限制，例如 IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox等，理論上沒有長(zhǎng)度限制，其限制取決于操作系 統(tǒng)的支持。

因此對(duì)于GET提交時(shí)，傳輸數(shù)據(jù)就會(huì)受到URL長(zhǎng)度的 限制。

**POST:**由于不是通過URL傳值，理論上數(shù)據(jù)不受 限。但實(shí)際各個(gè)WEB服務(wù)器會(huì)規(guī)定對(duì)post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。

安全

安全的 HTTP 方法不會(huì)改變服務(wù)器狀態(tài)，也就是說它只是可讀的。

GET 方法是安全的，而 POST 卻不是，因?yàn)?POST 的目的是傳送實(shí)體主體內(nèi)容，這個(gè)內(nèi)容可能是用戶上傳的表單數(shù)據(jù)，上傳成功之后，服務(wù)器可能把這個(gè)數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，因此狀態(tài)也就發(fā)生了改變。

安全的方法除了 GET 之外還有：HEAD、OPTIONS。

不安全的方法除了 POST 之外還有 PUT、DELETE。

速度

GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。

對(duì)于GET方式的請(qǐng)求，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）；而對(duì)于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）。

—END—

下方二維碼關(guān)注我

互聯(lián)網(wǎng)草根，堅(jiān)持分享技術(shù)、創(chuàng)業(yè)、產(chǎn)品等心得和總結(jié)~

點(diǎn)擊“閱讀原文”，領(lǐng)取 2020 年最新免費(fèi)技術(shù)資料大全

↓↓↓?