[[420219]]

面試中關(guān)于HTTP 2.0的面試題并不多，但基于HTTP 2.0的應(yīng)用已經(jīng)很多了，比如谷歌的gRPC框架就是基于HTTP 2.0來提升效率的。同時，HTTP 1.0中的存在的很多缺陷也都在HTTP 2.0中得到了解決。

所以，如果你在面試中脫穎而出，同時，在實踐中更好的理解類似gRPC這類框架的實現(xiàn)，了解HTTP 2.0還是非常必要的。而且HTTP 2.0也在很多場景下逐步替代HTTP 1.0。

HTTP 1.0存在的問題

了解過HTTP 1.0的協(xié)議實現(xiàn)之后，會發(fā)現(xiàn)它存在不少問題。

問題一：TCP連接數(shù)限制。為了避免網(wǎng)絡(luò)擁堵，占用過多的CPU和內(nèi)存。因此，不同的瀏覽器會限制TCP連接的數(shù)量。

問題二：隊頭阻塞問題。隊頭阻塞(Head Of Line Blocking)，每個TCP同時只能處理一個HTTP請求，瀏覽器遵循FIFO原則，如果上一個沒返回后續(xù)請求會被阻塞。

雖然提出了管道化(Pipelining)方案，但依舊存在諸多問題。比如，第一個響應(yīng)慢還是會阻塞后續(xù)響應(yīng);服務(wù)器為了按序返回需要緩存多個響應(yīng)，占用更多資源;瀏覽器中途斷連重試服務(wù)器可能得重新處理多個請求;還有必須客戶端 - 代理 - 服務(wù)器都支持管線化。

問題三：Header內(nèi)容過多，每次都需重復(fù)發(fā)送，沒有相應(yīng)的壓縮傳輸優(yōu)化方案;

問題四：為了減少請求數(shù)，需做文件合并等優(yōu)化工作，但同時會增加單個請求的延遲;

問題五：明文傳輸不安全;

HTTP 2.0的出現(xiàn)

針對HTTP 1.0的問題，RFC 7540定義了HTTP 2.0的協(xié)議規(guī)范和細(xì)節(jié)。HTTP 2.0的實現(xiàn)是基于SPDY協(xié)議的一些標(biāo)準(zhǔn)來實現(xiàn)的。

HTTP 2.0提供了：二進制分幀、首部壓縮、多路復(fù)用、請求優(yōu)先級、服務(wù)器推送等優(yōu)化。

HTTP 2.0是在SPDY(An experimental protocol for a faster web, The Chromium Projects)基礎(chǔ)上形成的下一代互聯(lián)網(wǎng)通信協(xié)議。HTTP/2 的目的是通過支持請求與響應(yīng)的多路復(fù)用來較少延遲，通過壓縮HTTPS首部字段將協(xié)議開銷降低，同時增加請求優(yōu)先級和服務(wù)器端推送的支持。

什么是SPDY協(xié)議

SPDY是Google開發(fā)的基于TCP協(xié)議的應(yīng)用層協(xié)議。目標(biāo)是優(yōu)化HTTP協(xié)議的性能，通過壓縮、多路復(fù)用和優(yōu)先級等技術(shù)，縮短網(wǎng)頁的加載時間并提高安全性。協(xié)議的核心思想是盡量減少TCP連接數(shù)。SPDY并不是一種用于替代HTTP的協(xié)議，而是對HTTP協(xié)議的增強。

互聯(lián)網(wǎng)工程任務(wù)組(IETF)對谷歌提出的SPDY協(xié)議進行了標(biāo)準(zhǔn)化，于2015年5推出了類似于SPDY協(xié)議的HTTP 2.0協(xié)議標(biāo)準(zhǔn)(簡稱HTTP/2)。谷歌因此宣布放棄對SPDY協(xié)議的支持，轉(zhuǎn)而支持HTTP/2。

下面詳細(xì)了解一下HTTP 2.0提供的新特性。

二進制分幀層 (Binary Framing Layer)

在保證HTTP1.x不受到影響的情況下，HTTP 2.0是怎樣突破HTTP 1.1的性能限制，改進傳輸性能，實現(xiàn)低延遲高吞吐量的呢?關(guān)鍵之一就是在應(yīng)用層(HTTP)和傳輸層(TCP)之間增加一個二進制分幀層。二進制分幀層，是HTTP 2.0性能增強的核心。

HTTP 1.1在應(yīng)用層以純文本的形式進行通信，而HTTP 2.0將所有的傳輸信息分割為更小的消息和幀，并對它們采用二進制格式編碼。同時，客戶端和服務(wù)端都需要引入新的二進制編碼和解碼的機制。如下圖所示，HTTP 2.0并沒有改變HTTP 1.x的語義，只是在應(yīng)用層使用二進制分幀方式傳輸。

HTTP/2協(xié)議

關(guān)于二進制分幀，有三個相關(guān)概念：幀、消息和流。

幀：HTTP 2.0通信的最小單位，所有幀都共享一個8字節(jié)的首部，其中包含幀的長度、類型、標(biāo)志、還有一個保留位，并且至少有標(biāo)識出當(dāng)前幀所屬的流的標(biāo)識符，幀承載著特定類型的數(shù)據(jù)，如HTTP首部、負(fù)荷等等。

+-----------------------------------------------+ 
|                 Length (24)                   | 
+---------------+---------------+---------------+ 
|   Type (8)    |   Flags (8)   | 
+-+-------------+---------------+-------------------------------+ 
|R|                 Stream Identifier (31)                      | 
+=+=============================================================+ 
|                   Frame Payload (0...)                      ... 
+---------------------------------------------------------------+ 

基于幀，以二進制傳輸代替原本的明文傳輸，原本的報文消息被劃分為更小的數(shù)據(jù)幀:

HTTP/2協(xié)議

在二進制分幀層上，HTTP 2.0會將所有傳輸?shù)男畔⒎譃楦〉南⒑蛶⒉捎枚M制格式編碼，其中HTTP 1.1的首部信息會被封裝到Headers幀，而Request Body則封裝到Data幀。

消息：比幀大的通訊單位，是指邏輯上的HTTP消息(請求/響應(yīng))，一系列數(shù)據(jù)幀組成了一個完整的消息。比如一系列DATA幀和一個HEADERS幀組成了請求消息。由一個或多個幀組成。

流：比消息大的通訊單位，是TCP連接中的一個虛擬通道，可以承載雙向的消息。每個流都有一個唯一的整數(shù)標(biāo)識符。

為防止兩端流ID沖突，客戶端發(fā)起的流具有奇數(shù)ID，服務(wù)器端發(fā)起的流具有偶數(shù)ID。所有HTTP 2. 0通信都在一個TCP連接上完成， 這個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流Stream。相應(yīng)地，每個數(shù)據(jù)流以消息的形式發(fā)送，而消息由一或多個幀組成，這些幀可以亂序發(fā)送，然后根據(jù)每個幀首部的流標(biāo)識符重新組裝。

HTTP/2協(xié)議

二進制分幀層保留了HTTP的語義不受影響，包括首部、方法等，在應(yīng)用層來看，和HTTP 1.x沒有差別。同時，所有同主機的通信能夠在一個TCP連接上完成。

• 單連接多資源的方式，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大;
• 由于TCP連接的減少而使網(wǎng)絡(luò)擁塞狀況得以改善，同時慢啟動時間的減少,使擁塞和丟包恢復(fù)速度更快。

多路復(fù)用 (MultiPlexing)

多路復(fù)用允許同時通過一個TCP連接發(fā)起多重的請求-響應(yīng)消息。消息由幀構(gòu)成，每幀數(shù)據(jù)上都標(biāo)識屬于哪個流(StreamID)，對方接收時根據(jù)流ID拼接每個流所有幀的數(shù)據(jù)，組成一塊完整的數(shù)據(jù)。這就是HTTP/2的多路復(fù)用。

流的概念實現(xiàn)了單連接上多請求-響應(yīng)并行，解決了“隊頭阻塞(Head of line blocking)”的問題，減少了TCP連接數(shù)量和TCP連接慢啟動的問題。所以HTTP/2對于同一域名只需要創(chuàng)建一個連接，而不是像HTTP/1那樣需要創(chuàng)建6~8個連接。

需要注意的是不同流的數(shù)據(jù)可以交叉發(fā)送，但同一個流的數(shù)據(jù)只能順序發(fā)送。

服務(wù)端推送 (Server Push)

客戶端發(fā)送一個請求，服務(wù)器根據(jù)客戶端的請求，提前返回多個響應(yīng)，這樣客戶端就不用發(fā)起后續(xù)請求。也就是說，在HTTP/2中，服務(wù)器可以對客戶端的一個請求發(fā)送多個響應(yīng)。服務(wù)器向客戶端推送資源無需客戶端明確的請求。

如下圖，客戶端請求Stream 1(/page.html)，服務(wù)端在返回Stream 1消息的同時推送了Stream 2(/script.js)和Stream 4(/style.css)：

HTTP/2協(xié)議

如果一個請求是由主頁發(fā)送的，服務(wù)器可能會響應(yīng)主頁內(nèi)容、logo以及樣式表，因為它知道客戶端會用到這些。這樣不但減輕了數(shù)據(jù)傳送冗余步驟，也加快了頁面響應(yīng)的速度，提高了用戶體驗。

服務(wù)端推送主要是針對資源內(nèi)聯(lián)做出的優(yōu)化，相較于HTTP/1.1資源內(nèi)聯(lián)的優(yōu)勢：

• 客戶端可以緩存推送的資源;
• 客戶端可以拒收推送過來的資源;
• 推送資源可以由不同頁面共享;
• 服務(wù)器可以按照優(yōu)先級推送資源;

推送的缺點：所有推送的資源都必須遵守同源策略。換句話說，服務(wù)器不能隨便將第三方資源推送給客戶端，而必須是經(jīng)過雙方的確認(rèn)才行。

Header 壓縮 (HPACK)

HTTP/1.1并不支持HTTP首部壓縮，為此SPDY和HTTP/2應(yīng)運而生， SPDY使用的是通用的算法，而HTTP/2則使用了專門為首部壓縮而設(shè)計的算法(HPACK算法)。

HTTP/2協(xié)議

HTTP協(xié)議是無狀態(tài)的，每次請求都必須附上所有信息(描述資源屬性)，重傳數(shù)據(jù)達(dá)到幾百甚至幾千字節(jié)。所以，請求頭字段很多都是重復(fù)的，比如Cookie，一樣的內(nèi)容每次請求都必須附帶，會浪費很多帶寬，也影響速度。

其實，對于相同的頭部，只需發(fā)送一次即可。HTTP/2對這一點做了優(yōu)化，引入了頭信息壓縮機制。一方面，頭信息使用gzip或compress壓縮后再發(fā)送;另一方面，客戶端和服務(wù)器同時維護一張頭信息表，所有字段都會存入這個表，產(chǎn)生一個索引號，之后就不發(fā)送同樣字段了，只需發(fā)送索引號。

請求優(yōu)先級

把HTTP消息分為很多獨立幀之后，就可以通過優(yōu)化這些幀的交錯和傳輸順序進一步優(yōu)化性能。HTTP/2中每個Stream都可以設(shè)置依賴 (Dependency) 和權(quán)重，可以按依賴樹分配優(yōu)先級，解決了關(guān)鍵請求被阻塞的問題。

應(yīng)用層的重置連接

對于HTTP/1來說，是通過設(shè)置tcp segment中的reset flag來通知對端關(guān)閉連接的。這種方式會直接斷開連接，下次再發(fā)請求就必須重新建立連接。HTTP/2引入 RST_STREAM類型的 frame，可以在不斷開連接的前提下取消某個request的stream，表現(xiàn)更好。

流量控制

TCP協(xié)議是通過sliding window算法來做流量控制的。發(fā)送方有一個sending window，接收方有一個receive window。HTTP/2的flow control類似receive window，數(shù)據(jù)接收方通知對方字節(jié)的flow window大小，表明還能接收的數(shù)據(jù)量。只有Data類型的frame才有flow control功能。

通過上述方式，可以限制另一端發(fā)送數(shù)據(jù)。對于每個流來說，兩端都必須告訴對方自己還有足夠的空間來處理新的數(shù)據(jù)，而在該窗口被擴大前，另一端只被允許發(fā)送這么多數(shù)據(jù)。

小結(jié)

每一個新的協(xié)議的應(yīng)用普及都需要一個過程，HTTP/2也不例外。還好的是，它是上層協(xié)議，而且只是在HTTP/1和TCP之間添加了一層，逐步被使用必然是趨勢。在了解了HTTP/2的這些新特性之后，或許你已經(jīng)明白，為什么越來越多的瀏覽器、中間件開始采用HTTP/2了。因為，它的確非常高效，值得你學(xué)習(xí)并運用。