HTTP2.0

標(biāo)簽（空格分隔）： HTTP2.0

HTTP2.0 核心變化：二進制分幀

在應(yīng)用層(HTTP2.0)和傳輸層(TCP、UDP)新增的二進制分幀層。

在二進制分幀層上，HTTP2.0會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶⑦M行二進制格式的編碼，HTTP1.1的head信息會被封裝到Headers幀，request body中的數(shù)據(jù)會封裝到Data幀里面。

PUSH_PROMISE frame(推送幀):這種幀是由server端發(fā)送給client的幀，用來表示server push的幀，這種幀是實現(xiàn)server push的主要幀類型。
RST_STREAM(取消推送幀):這種幀表示請求關(guān)閉幀，簡單講就是當(dāng)client不想接受某些資源或者接受timeout時會向發(fā)送方發(fā)送此幀，和PUSH_PROMISE frame一起使用時表示拒絕或者關(guān)閉server push。

然后，HTTP 2.0 通信都在一個連接上完成，這個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。相應(yīng)地，每個數(shù)據(jù)流以消息的形式發(fā)送，而消息由一或多個幀組成，這些幀可以亂序發(fā)送，然后再根據(jù)每個幀首部的流標(biāo)識符重新組裝。

頭部壓縮

HTTP 2.0 在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲之前發(fā)送的鍵-值對，對于相同的數(shù)據(jù)，不再通過每次請求和響應(yīng)發(fā)送;通信期間幾乎不會改變的通用鍵-值對(用戶代理、可接受的媒體類型,等等)只需發(fā)送一次。事實上,如果請求中不包含首部(例如對同一資源的輪詢請求),那么首部開銷就是零字節(jié)。此時所有首部都自動使用之前請求發(fā)送的首部。

如果首部發(fā)生變化了，那么只需要發(fā)送變化了數(shù)據(jù)在Headers幀里面，新增或修改的首部幀會被追加到“首部表”。首部表在 HTTP 2.0 的連接存續(xù)期內(nèi)始終存在,由客戶端和服務(wù)器共同漸進地更新 。

所有的HTTP請求在一個連接上

HTTP2.0所有通信都是在一個TCP連接上完成。HTTP 2.0 把 HTTP 協(xié)議通信的基本單位縮小為一個一個的幀，這些幀對應(yīng)著邏輯流中的消息。并行地在同一個 TCP 連接上雙向交換消息。就好比，請求一個頁面http://www.qq.com。頁面上所有的資源請求都是客戶端與服務(wù)器上的一條TCP上請求和響應(yīng)的！

HTTP性能的關(guān)鍵在于低延遲而不是高帶寬！大多數(shù)HTTP 連接的時間都很短，而且是突發(fā)性的，但TCP 只在長時間連接傳輸大塊數(shù)據(jù)時效率才最高。HTTP 2.0 通過讓所有數(shù)據(jù)流共用同一個連接，可以更有效地使用TCP 連接，讓高帶寬也能真正的服務(wù)于HTTP的性能提升。

同時，單鏈接多資源的方式，使到至上而下的層面都得到了好處：

1. 可以減少服務(wù)鏈接壓力,內(nèi)存占用少了,連接吞吐量大了
2. 由于 TCP 連接減少而使網(wǎng)絡(luò)擁塞狀況得以改觀;
3. 慢啟動時間減少,擁塞和丟包恢復(fù)速度更快。

并行雙向字節(jié)流的請求和響應(yīng)

在HTTP2.0上，客戶端和服務(wù)器可以把HTTP 消息分解為互不依賴的幀，然后亂序發(fā)送，最后再在另一端把它們重新組合起來。注意，同一鏈接上有多個不同方向的數(shù)據(jù)流在傳輸?？蛻舳丝梢砸贿厑y序發(fā)送stream，也可以一邊接收者服務(wù)器的響應(yīng)，而服務(wù)器那端同理。

把 HTTP 消息分解為獨立的幀,交錯發(fā)送,然后在另一端重新組裝是 HTTP 2.0 最 重要的一項增強。事實上,這個機制會在整個 Web 技術(shù)棧中引發(fā)一系列連鎖反應(yīng), 從而帶來巨大的性能提升,因為:

可以并行交錯地發(fā)送請求,請求之間互不影響;
可以并行交錯地發(fā)送響應(yīng),響應(yīng)之間互不干擾;
只使用一個連接即可并行發(fā)送多個請求和響應(yīng);
消除不必要的延遲,從而減少頁面加載的時間;

HTTP2.0的請求優(yōu)先級

每個HTTP2.0流里面有個優(yōu)先值，這個優(yōu)先值確定著客戶端和服務(wù)器處理不同的流采取不同的優(yōu)先級策略，高優(yōu)先級的流都應(yīng)該優(yōu)先發(fā)送，但又不會絕對的。絕對地準(zhǔn)守，可能又會引入首隊阻塞的問題：高優(yōu)先級的請求慢導(dǎo)致阻塞其他資源交付。分配處理資源和客戶端與服務(wù)器間的帶寬，不同優(yōu)先級的混合也是必須的。

HTTP2.0的服務(wù)器推送

HTTP 2.0 新增的一個強大的新功能，就是服務(wù)器可以對一個客戶端請求發(fā)送多個響應(yīng)。換句話說，服務(wù)器可以強奸你的瀏覽器，哦不，應(yīng)該是，除了對最初請求的響應(yīng)外，服務(wù)器還可以額外向客戶端推送資源，而無需客戶端明確地請求。
當(dāng)瀏覽器請求一個html，服務(wù)器其實大概知道你是接下來要請求資源了，而不需要等待瀏覽器得到html后解析頁面再發(fā)送資源請求。我們常用的內(nèi)嵌圖片也可以理解為一種強制的服務(wù)器推送：我請求html，卻內(nèi)嵌了張黃圖。

有了HTTP2.0的服務(wù)器推送，HTTP1.x時代的內(nèi)嵌資源的優(yōu)化手段也變得沒有意義了。而且使用服務(wù)器推送的資源的方式更加高效，因為客戶端還可以緩存起來，甚至可以由不同的頁面共享（依舊遵循同源策略）。當(dāng)然，你是個正直的瀏覽器，是可以決絕服務(wù)器推送的黃圖的。

測試

接口名稱getReportPage，1.1和2.0部署在不同的機器上，數(shù)據(jù)庫訪問相同。

HTTP 1.1
并發(fā)請求10次，總耗時1s，單個請求返回耗時200ms左右。

HTTP 2.0
并發(fā)請求10次，總耗時0.9s，單個請求400ms左右，單個請求的時間不好對比，因為1.1和2.0的接口不在同一臺服務(wù)器上。

重復(fù)請求request header大小在2.0下有明顯縮小。