[[172535]]

自從我寫了上一篇博文之后，就再也找不到空閑時(shí)間寫文章了。今天我終于可以抽出時(shí)間寫一些關(guān)于 HTTP 的東西。

我認(rèn)為每一個(gè) web 開發(fā)者都應(yīng)該對這個(gè)支撐了整個(gè) Web 世界的 HTTP 協(xié)議有所了解，這樣才能幫助你更好的完成開發(fā)任務(wù)。

在這篇文章中，我將討論什么是 HTTP，它是怎么產(chǎn)生的，它的地位，以及我們應(yīng)該怎么使用它。

HTTP 是什么

首先我們要明白 HTTP 是什么。HTTP 是一個(gè)基于 TCP/IP 的應(yīng)用層通信協(xié)議，它是客戶端和服務(wù)端在互聯(lián)網(wǎng)互相通訊的標(biāo)準(zhǔn)。它定義了內(nèi)容是如何通過互聯(lián)網(wǎng)進(jìn)行請求和傳輸?shù)摹TTP 是在應(yīng)用層中抽象出的一個(gè)標(biāo)準(zhǔn)，使得主機(jī)(客戶端和服務(wù)端)之間的通信得以通過 TCP/IP 來進(jìn)行請求和響應(yīng)。TCP 默認(rèn)使用的端口是 80，當(dāng)然也可以使用其它端口，比如 HTTPS 使用的就是 443 端口。

HTTP/0.9 - 單行協(xié)議 (1991)

HTTP 最早的規(guī)范可以追溯到 1991 年，那時(shí)候的版本是 HTTP/0.9，該版本極其簡單，只有一個(gè)叫做 GET的請求方式。如果客戶端要訪問服務(wù)端上的一個(gè)頁面，只需要如下非常簡單的請求：

GET /index.html 

服務(wù)端對應(yīng)的返回類似如下：

(response body) 
(connection closed) 

就這么簡單，服務(wù)端捕獲到請求后立馬返回 HTML 并且關(guān)閉連接，在這之中

• 沒有頭信息(headers)
• 僅支持 GET 這一種請求方法
• 必須返回 HTML

如同你所看到的，當(dāng)時(shí)的 HTTP 協(xié)議只是一塊基礎(chǔ)的墊腳石。

HTTP/1.0 - 1996

在 1996 年，新版本的 HTTP 對比之前的版本有了極大的改進(jìn)，同時(shí)也被命名為 HTTP/1.0。

與 HTTP/0.9 只能返回 HTML 不同的是，HTTP/1.0 支持處理多種返回的格式，比如圖片、視頻、文本或者其他格式的文件。它還增加了更多的請求方法(如 POST 和 HEAD)，請求和響應(yīng)的格式也相應(yīng)做了改變，兩者都增加了頭信息;引入了狀態(tài)碼來定義返回的特征;引入了字符集支持;支持多段類型(multi-part)、用戶驗(yàn)證信息、緩存、內(nèi)容編碼格式等等。

一個(gè)簡單的 HTTP/1.0 請求大概是這樣的：

GET / HTTP/1.0 
Host: kamranahmed.info 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) 
Accept: */* 

正如你所看到的，在請求中附帶了客戶端中的一些個(gè)人信息、響應(yīng)類型要求等內(nèi)容。這些是在 HTTP/0.9 無法實(shí)現(xiàn)的，因?yàn)槟菚r(shí)候沒有頭信息。

一個(gè)對上述請求的響應(yīng)例子如下所示：

HTTP/1.0 200 OK 
Content-Type: text/plain 
Content-Length: 137582 
Expires: Thu, 05 Dec 1997 16:00:00 GMT 
Last-Modified: Wed, 5 August 1996 15:55:28 GMT 
Server: Apache 0.84 
(response body) 
(connection closed) 

從 HTTP/1.0 (HTTP 后面跟的是版本號)早期開始，在狀態(tài)碼 200 之后就附帶一個(gè)原因短語(你可以用來描述狀態(tài)碼)。

在這個(gè)較新一點(diǎn)的版本中，請求和響應(yīng)的頭信息仍然必須是 ASCII 編碼，但是響應(yīng)的內(nèi)容可以是任意類型，如圖片、視頻、HTML、文本或其他類型，服務(wù)器可以返回任意內(nèi)容給客戶端。所以這之后，HTTP 中的“超文本(Hyper Text)”成了名不副實(shí)。 HMTP (超媒體傳輸協(xié)議(Hypermedia transfer protocol))可能會更有意義，但是我猜我們還是會一直沿用這個(gè)名字。

HTTP/1.0 的一個(gè)主要缺點(diǎn)就是它不能在一個(gè)連接內(nèi)擁有多個(gè)請求。這意味著，當(dāng)客戶端需要從服務(wù)器獲取東西時(shí)，必須建立一個(gè)新的 TCP 連接，并且處理完單個(gè)請求后連接即被關(guān)閉。需要下一個(gè)東西時(shí)，你必須重新建立一個(gè)新的連接。這樣的壞處在哪呢?假設(shè)你要訪問一個(gè)有 10 張圖片，5 個(gè)樣式表(stylesheet)和 5 個(gè) JavaScript 的總計(jì) 20 個(gè)文件才能完整展示的一個(gè)頁面。由于一個(gè)連接在處理完成一次請求后即被關(guān)閉，所以將有 20 個(gè)單獨(dú)的連接，每一個(gè)文件都將通過各自對應(yīng)的連接單獨(dú)處理。當(dāng)連接數(shù)量變得龐大的時(shí)候就會面臨嚴(yán)重的性能問題，因?yàn)?TCP 啟動需要經(jīng)過三次握手，才能緩慢開始。

三次握手

三次握手是一個(gè)簡單的模型，所有的 TCP 連接在傳輸應(yīng)用數(shù)據(jù)之前都需要在三次握手中傳輸一系列數(shù)據(jù)包。

• SYN - 客戶端選取一個(gè)隨機(jī)數(shù)，我們稱為 x，然后發(fā)送給服務(wù)器。
• SYN ACK - 服務(wù)器響應(yīng)對應(yīng)請求的 ACK 包中，包含了一個(gè)由服務(wù)器隨機(jī)產(chǎn)生的數(shù)字，我們稱為 y，并且把客戶端發(fā)送的 x+1，一并返回給客戶端。
• ACK - 客戶端在從服務(wù)器接受到 y 之后把 y 加上 1 作為一個(gè) ACK 包返回給服務(wù)器。

一旦三次握手完成后，客戶端和服務(wù)器之間就可以開始交換數(shù)據(jù)。值得注意的是，當(dāng)客戶端發(fā)出***一個(gè) ACK 數(shù)據(jù)包后，就可以立刻向服務(wù)器發(fā)送應(yīng)用數(shù)據(jù)包，而服務(wù)器則需要等到收到這個(gè) ACK 數(shù)據(jù)包后才能接受應(yīng)用數(shù)據(jù)包。

請注意，上圖有點(diǎn)小問題，客戶端發(fā)回的***一個(gè) ACK 包僅包含 y+1，上圖應(yīng)該是 ACK:y+1 而不是 ACK:x+1,y+1

然而，某些 HTTP/1.0 的實(shí)現(xiàn)試圖通過新引入一個(gè)稱為 Connection: keep-alive 的頭信息來克服這一問題，這個(gè)頭信息意味著告訴服務(wù)器“嘿，服務(wù)器，請不要關(guān)閉此連接，我還要用它”。但是，這并沒有得到廣泛的支持，問題依然存在。

除了無連接之外，HTTP 還是一個(gè)無狀態(tài)的協(xié)議，即服務(wù)器不維護(hù)有關(guān)客戶端的信息。因此每個(gè)請求必須給服務(wù)器必要的信息才能完成請求，每個(gè)請求都與之前的舊的請求無關(guān)。所以，這增加了推波助瀾的作用，客戶端除了需要新建大量連接之外，在每次連接中還需要發(fā)送許多重復(fù)的數(shù)據(jù)，這導(dǎo)致了帶寬的大量浪費(fèi)。

HTTP/1.1 - 1999

HTTP/1.0 經(jīng)過僅僅 3 年，下一個(gè)版本，即 HTTP/1.1 就在 1999 年發(fā)布了，改進(jìn)了它的前身很多問題，主要的改進(jìn)包括：

• 增加了許多 HTTP 請求方法，包括 PUT、PATCH、HEAD、OPTIONS、DELETE。
• 主機(jī)標(biāo)識符 Host 在 HTTP/1.0 并不是必須的，而在 HTTP/1.1 是必須的。
• 如上所述的持久連接。在 HTTP/1.0 中每個(gè)連接只有一個(gè)請求并在該請求結(jié)束后被立即關(guān)閉，這導(dǎo)致了性能問題和增加了延遲。 HTTP/1.1 引入了持久連接，即連接在默認(rèn)情況下是不關(guān)閉并保持開放的，這允許多個(gè)連續(xù)的請求使用這個(gè)連接。要關(guān)閉該連接只需要在頭信息加入 Connection: close，客戶通常在***一個(gè)請求里發(fā)送這個(gè)頭信息就能安全地關(guān)閉連接。
• 新版本還引入了“管線化(pipelining)”的支持，客戶端可以不用等待服務(wù)器返回響應(yīng)，就能在同一個(gè)連接內(nèi)發(fā)送多個(gè)請求給服務(wù)器，而服務(wù)器必須以接收到的請求相同的序列發(fā)送響應(yīng)。但是你可能會問了，客戶端如何知道哪里是***個(gè)響應(yīng)下載完成而下一個(gè)響應(yīng)內(nèi)容開始的地方呢?要解決這個(gè)問題，頭信息必須有 Content-Length，客戶可以使用它來確定哪些響應(yīng)結(jié)束之后可以開始等待下一個(gè)響應(yīng)。

。值得注意的是，為了從持久連接或管線化中受益， 頭部信息必須包含 Content-Length，因?yàn)檫@會使客戶端知道什么時(shí)候完成了傳輸，然后它可以發(fā)送下一個(gè)請求(持久連接中，以正常的依次順序發(fā)送請求)或開始等待下一個(gè)響應(yīng)(啟用管線化時(shí))。

。但是，使用這種方法仍然有一個(gè)問題。那就是，如果數(shù)據(jù)是動態(tài)的，服務(wù)器無法提前知道內(nèi)容長度呢?那么在這種情況下，你就不能使用這種方法中獲益了嗎?為了解決這個(gè)問題，HTTP/1.1 引進(jìn)了分塊編碼。在這種情況下，服務(wù)器可能會忽略 Content-Length 來支持分塊編碼(更常見一些)。但是，如果它們都不可用，那么連接必須在請求結(jié)束時(shí)關(guān)閉。

• 在動態(tài)內(nèi)容的情況下分塊傳輸，當(dāng)服務(wù)器在傳輸開始但無法得到 Content-Length 時(shí)，它可能會開始按塊發(fā)送內(nèi)容(一塊接一塊)，并在傳輸時(shí)為每一個(gè)小塊添加 Content-Length。當(dāng)發(fā)送完所有的數(shù)據(jù)塊后，即整個(gè)傳輸已經(jīng)完成后，它發(fā)送一個(gè)空的小塊，比如設(shè)置 Content-Length 為 0 ，以便客戶端知道傳輸已完成。為了通知客戶端塊傳輸?shù)男畔?，服?wù)器在頭信息中包含了 Transfer-Encoding: chunked。
• 不像 HTTP/1.0 中只有 Basic 身份驗(yàn)證方式，HTTP/1.1 包括摘要驗(yàn)證方式(digest authentication)和代理驗(yàn)證方式(proxy authentication)。
• 緩存。
• 范圍請求(Byte Ranges)。
• 字符集。
• 內(nèi)容協(xié)商(Content Negotiation)。
• 客戶端 cookies。
• 支持壓縮。
• 新的狀態(tài)碼。
• 等等。

我不打算在這里討論所有 HTTP/1.1 的特性，因?yàn)槟憧梢試@這個(gè)話題找到很多關(guān)于這些的討論。我建議你閱讀 HTTP/1.0 和 HTTP/1.1 版本之間的主要差異，希望了解更多可以讀原始的 RFC。

HTTP/1.1 在 1999 年推出，到現(xiàn)在已經(jīng)是多年前的標(biāo)準(zhǔn)。雖然，它比前一代改善了很多，但是網(wǎng)絡(luò)日新月異，它已經(jīng)垂垂老矣。相比之前，加載網(wǎng)頁更是一個(gè)資源密集型任務(wù)，打開一個(gè)簡單的網(wǎng)頁已經(jīng)需要建立超過 30 個(gè)連接。你或許會說，HTTP/1.1 具有持久連接，為什么還有這么多連接呢?其原因是，在任何時(shí)刻 HTTP/1.1 只能有一個(gè)未完成的連接。 HTTP/1.1 試圖通過引入管線來解決這個(gè)問題，但它并沒有完全地解決。因?yàn)橐坏┕芫€遇到了緩慢的請求或龐大的請求，后面的請求便被阻塞住，它們必須等待上一個(gè)請求完成。為了克服 HTTP/1.1 的這些缺點(diǎn)，開發(fā)人員開始實(shí)現(xiàn)一些解決方法，例如使用 spritesheets、在 CSS 中編碼圖像、單個(gè)巨型 CSS / JavaScript 文件、域名切分等。

SPDY - 2009

谷歌走在業(yè)界前列，為了使網(wǎng)絡(luò)速度更快，提高網(wǎng)絡(luò)安全，同時(shí)減少網(wǎng)頁的等待時(shí)間，他們開始實(shí)驗(yàn)替代的協(xié)議。在 2009 年，他們宣布了 SPDY。

SPDY 是谷歌的商標(biāo)，而不是一個(gè)縮寫。

顯而易見的是，如果我們繼續(xù)增加帶寬，網(wǎng)絡(luò)性能開始的時(shí)候能夠得到提升，但是到了某個(gè)階段后帶來的性能提升就很有限了。但是如果把這些優(yōu)化放在等待時(shí)間上，比如減少等待時(shí)間，將會有持續(xù)的性能提升。這就是 SPDY 優(yōu)化之前的協(xié)議的核心思想，減少等待時(shí)間來提升網(wǎng)絡(luò)性能。

對于那些不知道其中區(qū)別的人，等待時(shí)間就是延遲，即數(shù)據(jù)從源到達(dá)目的地需要多長時(shí)間(單位為毫秒)，而帶寬是每秒鐘數(shù)據(jù)的傳輸量(比特每秒)。

SPDY 的特點(diǎn)包括：復(fù)用、壓縮、優(yōu)先級、安全性等。我不打算展開 SPDY 的細(xì)節(jié)。在下一章節(jié)，當(dāng)我們將介紹 HTTP/2，這些都會被提到，因?yàn)? HTTP/2 大多特性是從 SPDY 受啟發(fā)的。

SPDY 沒有試圖取代 HTTP，它是處于應(yīng)用層的 HTTP 之上的一個(gè)傳輸層，它只是在請求被發(fā)送之前做了一些修改。它開始成為事實(shí)標(biāo)準(zhǔn)，大多數(shù)瀏覽器都開始支持了。

2015年，谷歌不想有兩個(gè)相互競爭的標(biāo)準(zhǔn)，所以他們決定將其合并到 HTTP 協(xié)議，這樣就導(dǎo)致了 HTTP/2 的出現(xiàn)和 SPDY 的廢棄。

HTTP/2 - 2015

現(xiàn)在想必你明白了為什么我們需要另一個(gè)版本的 HTTP 協(xié)議了。 HTTP/2 是專為了低延遲地內(nèi)容傳輸而設(shè)計(jì)。主要特點(diǎn)和與 HTTP/1.1 的差異包括：

• 使用二進(jìn)制替代明文
• 多路傳輸 - 多個(gè)異步 HTTP 請求可以使用單一連接
• 報(bào)頭使用 HPACK 壓縮
• 服務(wù)器推送 - 單個(gè)請求多個(gè)響應(yīng)
• 請求優(yōu)先級
• 安全性

1. 二進(jìn)制協(xié)議

HTTP/2 通過使其成為一個(gè)二進(jìn)制協(xié)議以解決 HTTP/1.x 中存在的延遲問題。作為一個(gè)二進(jìn)制協(xié)議，它更容易解析，但可讀性卻不如 HTTP/1.x。幀(frames)和流(stream)的概念組成了 HTTP/2 的主要部分。

幀和流

現(xiàn)在 HTTP 消息是由一個(gè)或多個(gè)幀組成的。HEADERS 幀承載了元數(shù)據(jù)(meta data)，DATA 幀則承載了內(nèi)容。還有其他類型的幀(HEADERS、DATA、RST_STREAM、SETTINGS、PRIORITY 等等)，這些你可以通過 HTTP/2 規(guī)范來了解。

每個(gè) HTTP/2 請求和響應(yīng)都被賦予一個(gè)唯一的流 ID，并切分成幀。幀就是一小片二進(jìn)制數(shù)據(jù)。幀的集合稱為流，每個(gè)幀都有個(gè)標(biāo)識了其所屬流的流 ID，所以在同一個(gè)流下的每個(gè)幀具有共同的報(bào)頭。值得注意的是，除了流 ID 是唯一的之外，由客戶端發(fā)起的請求使用了奇數(shù)作為流 ID，從來自服務(wù)器的響應(yīng)使用了偶數(shù)作為流 ID。

除了 HEADERS 幀和 DATA 幀，另一個(gè)值得一提的幀是 RST_STREAM。這是一個(gè)特殊的幀類型，用來中止流，即客戶可以發(fā)送此幀讓服務(wù)器知道，我不再需要這個(gè)流了。在 HTTP/1.1 中讓服務(wù)器停止給客戶端發(fā)送響應(yīng)的唯一方法是關(guān)閉連接，這樣造成了延遲增加，因?yàn)橹笠l(fā)送請求時(shí)，就要必須打開一個(gè)新的請求。而在 HTTP/2，客戶端可以使用 RST_STREAM 來停止接收特定的數(shù)據(jù)流，而連接仍然打開著，可以被其他請求使用。

2. 多路傳輸

因?yàn)?HTTP/2 是一個(gè)二進(jìn)制協(xié)議，而且如上所述它使用幀和流來傳輸請求與響應(yīng)，一旦建立了 TCP 連接，相同連接內(nèi)的所有流都可以同過這個(gè) TCP 連接異步發(fā)送，而不用另外打開連接。反過來說，服務(wù)器也可以使用同樣的異步方式返回響應(yīng)，也就是說這些響應(yīng)可以是無序的，客戶端使用分配的流 ID 來識別數(shù)據(jù)包所屬的流。這也解決了 HTTP/1.x 中請求管道被阻塞的問題，即客戶端不必等待占用時(shí)間的請求而其他請求仍然可以被處理。

3. HPACK 請求頭部壓縮

RFC 花了一篇文檔的篇幅來介紹針對發(fā)送的頭信息的優(yōu)化，它的本質(zhì)是當(dāng)我們在同一客戶端上不斷地訪問服務(wù)器時(shí)，許多冗余數(shù)據(jù)在頭部中被反復(fù)發(fā)送，有時(shí)候僅僅是 cookies 就能增加頭信息的大小，這會占用許多寬帶和增加傳輸延遲。為了解決這個(gè)問題，HTTP/2 引入了頭信息壓縮。

不像請求和響應(yīng)那樣，頭信息中的信息不會以 gzip 或者 compress 等格式壓縮。而是采用一種不同的機(jī)制來壓縮頭信息，客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，儲存了使用了哈夫曼編碼進(jìn)行編碼后的頭信息的值，并且后續(xù)請求中若出現(xiàn)同樣的字段則忽略重復(fù)值(例如用戶代理(user agent)等)，只發(fā)送存在兩邊信息表中它的引用即可。

我們說的頭信息，它們同 HTTP/1.1 中一樣，并在此基礎(chǔ)上增加了一些偽頭信息，如 :scheme，:host 和 :path。

4. 服務(wù)器推送

服務(wù)器推送是 HTTP/2 的另一個(gè)巨大的特點(diǎn)。對于服務(wù)器來說，當(dāng)它知道客戶端需要一定的資源后，它可以把數(shù)據(jù)推送到客戶端，即使客戶端沒有請求它。例如，假設(shè)一個(gè)瀏覽器在加載一個(gè)網(wǎng)頁時(shí)，它解析了整個(gè)頁面，發(fā)現(xiàn)有一些內(nèi)容必須要從服務(wù)端獲取，然后發(fā)送相應(yīng)的請求到服務(wù)器以獲取這些內(nèi)容。

服務(wù)器推送減少了傳輸這些數(shù)據(jù)需要來回請求的次數(shù)。它是如何做到的呢?服務(wù)器通過發(fā)送一個(gè)名字為 PUSH_PROMISE 特殊的幀通知到客戶端“嘿，我準(zhǔn)備要發(fā)送這個(gè)資源給你了，不要再問我要了。”這個(gè) PUSH_PROMISE 幀與要產(chǎn)生推送的流聯(lián)系在一起，并包含了要推送的流 ID，也就是說這個(gè)流將會被服務(wù)器推送到客戶端上。

5. 請求優(yōu)先級

當(dāng)流被打開的時(shí)候，客戶端可以在 HEADERS 幀中包含優(yōu)先級信息來為流指定優(yōu)先級。在任何時(shí)候，客戶端都可以發(fā)送 PRIORITY 幀來改變流的優(yōu)先級。

如果沒有任何優(yōu)先級信息，服務(wù)器將異步地?zé)o序地處理這些請求。如果流分配了優(yōu)先級，服務(wù)器將基于這個(gè)優(yōu)先級來決定需要分配多少資源來處理這個(gè)請求。

6. 安全性

在是否強(qiáng)制使用 TLS 來增加安全性的問題上產(chǎn)生了大范圍的討論，討論的結(jié)果是不強(qiáng)制使用。然而大多數(shù)廠商只有在使用 TLS 時(shí)才能使用 HTTP/2。所以 HTTP/2 雖然規(guī)范上不要求加密，但是加密已經(jīng)約定俗成了。這樣，在 TLS 之上實(shí)現(xiàn) HTTP/2 就有了一些強(qiáng)制要求，比如，TLS 的***版本為 1.2，必須達(dá)到某種級別的***限度的密鑰大小，需要布署 ephemeral 密鑰等等。

到現(xiàn)在 HTTP/2 已經(jīng)完全超越了 SPDY，并且還在不斷成長，HTTP/2 有很多關(guān)系性能的提升，我們應(yīng)該開始布署它了。

如果你想更深入的了解細(xì)節(jié)，請?jiān)L問該規(guī)范的鏈接和 HTTP/2 性能提升演示的鏈接。請?jiān)诹粞园鍖懴履愕囊蓡柣蛘咴u論，***如果你發(fā)現(xiàn)有錯誤，請同樣留言指出。

這就是全部了，我們之后再見~