[[172535]]

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

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

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

HTTP 是什么

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

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

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

GET /index.html 

服務端對應的返回類似如下：

(response body) 
(connection closed) 

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

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

如同你所看到的，當時的 HTTP 協(xié)議只是一塊基礎的墊腳石。

HTTP/1.0 - 1996

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

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

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

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

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

一個對上述請求的響應例子如下所示：

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 之后就附帶一個原因短語(你可以用來描述狀態(tài)碼)。

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

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

三次握手

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

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

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

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

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

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

HTTP/1.1 - 1999

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

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

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

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

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

我不打算在這里討論所有 HTTP/1.1 的特性，因為你可以圍繞這個話題找到很多關于這些的討論。我建議你閱讀 HTTP/1.0 和 HTTP/1.1 版本之間的主要差異，希望了解更多可以讀原始的 RFC。

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

SPDY - 2009

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

SPDY 是谷歌的商標，而不是一個縮寫。

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

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

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

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

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

HTTP/2 - 2015

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

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

1. 二進制協(xié)議

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

幀和流

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

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

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

2. 多路傳輸

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

3. HPACK 請求頭部壓縮

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

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

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

4. 服務器推送

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

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

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

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

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

6. 安全性

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

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

如果你想更深入的了解細節(jié)，請訪問該規(guī)范的鏈接和 HTTP/2 性能提升演示的鏈接。請在留言板寫下你的疑問或者評論，***如果你發(fā)現(xiàn)有錯誤，請同樣留言指出。

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