[[420219]]

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

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

HTTP 1.0存在的問(wèn)題

了解過(guò)HTTP 1.0的協(xié)議實(shí)現(xiàn)之后，會(huì)發(fā)現(xiàn)它存在不少問(wèn)題。

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

問(wèn)題二：隊(duì)頭阻塞問(wèn)題。隊(duì)頭阻塞(Head Of Line Blocking)，每個(gè)TCP同時(shí)只能處理一個(gè)HTTP請(qǐng)求，瀏覽器遵循FIFO原則，如果上一個(gè)沒(méi)返回后續(xù)請(qǐng)求會(huì)被阻塞。

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

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

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

問(wèn)題五：明文傳輸不安全;

HTTP 2.0的出現(xiàn)

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

HTTP 2.0提供了：二進(jìn)制分幀、首部壓縮、多路復(fù)用、請(qǐng)求優(yōu)先級(jí)、服務(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 的目的是通過(guò)支持請(qǐng)求與響應(yīng)的多路復(fù)用來(lái)較少延遲，通過(guò)壓縮HTTPS首部字段將協(xié)議開(kāi)銷降低，同時(shí)增加請(qǐng)求優(yōu)先級(jí)和服務(wù)器端推送的支持。

什么是SPDY協(xié)議

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

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

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

二進(jìn)制分幀層 (Binary Framing Layer)

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

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

HTTP/2協(xié)議

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

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

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

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

HTTP/2協(xié)議

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

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

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

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

HTTP/2協(xié)議

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

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

多路復(fù)用 (MultiPlexing)

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

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

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

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

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

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

HTTP/2協(xié)議

如果一個(gè)請(qǐng)求是由主頁(yè)發(fā)送的，服務(wù)器可能會(huì)響應(yīng)主頁(yè)內(nèi)容、logo以及樣式表，因?yàn)樗揽蛻舳藭?huì)用到這些。這樣不但減輕了數(shù)據(jù)傳送冗余步驟，也加快了頁(yè)面響應(yīng)的速度，提高了用戶體驗(yàn)。

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

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

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

Header 壓縮 (HPACK)

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

HTTP/2協(xié)議

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

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

請(qǐng)求優(yōu)先級(jí)

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

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

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

流量控制

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

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

小結(jié)

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