http1的缺點
線頭阻塞：方式為，若干個請求排隊串行化單線程處理，后面的請求等待前面請求的返回才能獲得執(zhí)行機會，一旦有某請求超時等，后續(xù)請求只能被阻塞，毫無辦法，也就是人們常說的線頭阻塞；
沒有充分的利用TCP鏈接： HTTP 1.x 中，如果想并發(fā)多個請求，必須使用多個 TCP 鏈接，且瀏覽器為了控制資源，還會對單個域名有 6-8個的TCP鏈接請求限制
http2優(yōu)點
多路復(fù)用：最有價值的優(yōu)點，解決了線頭阻塞的問題，允許單一的http2連接可以發(fā)送多重的請求和響應(yīng)，充分的利用TCP。 使得 資源分域名、雪碧圖、內(nèi)聯(lián)樣式等不再適用。
header壓縮：HTTP2.0可以在客戶端和服務(wù)器端維護靜態(tài)字典和動態(tài)字典用來壓縮和差量更新HTTP頭部，大大降低因頭部傳輸產(chǎn)生的流量。非兩個字典內(nèi)的header可以適用哈夫曼壓縮方式進行壓縮。
新的二進制格式：http1.x 是文本格式傳輸，http2是二進制格式傳輸。
服務(wù)端推送：服務(wù)器端可以主動向客戶端推送資源。
二進制分幀
先來理解幾個概念：
幀：HTTP/2 數(shù)據(jù)通信的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應(yīng)等，消息由一個或多個幀組成。
流：存在于連接中的一個虛擬通道。流可以承載雙向消息，每個流都有一個唯一的整數(shù)ID。
HTTP/2 采用二進制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進制協(xié)議解析起來更高效。 HTTP / 1 的請求和響應(yīng)報文，都是由起始行，首部和實體正文（可選）組成，各部分之間以文本換行符分隔。HTTP/2 將請求和響應(yīng)數(shù)據(jù)分割為更小的幀，并且它們采用二進制編碼。
HTTP/2 中，同域名下所有通信都在單個連接上完成，該連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個數(shù)據(jù)流都以消息的形式發(fā)送，而消息又由一個或多個幀組成。多個幀之間可以亂序發(fā)送，根據(jù)幀首部的流標識可以重新組裝。
多路復(fù)用
多路復(fù)用，代替原來的序列和阻塞機制。所有就是請求的都是通過一個 TCP連接并發(fā)完成。 HTTP 1.x 中，如果想并發(fā)多個請求，必須使用多個 TCP 鏈接，且瀏覽器為了控制資源，還會對單個域名有 6-8個的TCP鏈接請求限制，如下圖，紅色圈出來的請求就因域名鏈接數(shù)已超過限制，而被掛起等待了一段時間：
在 HTTP/2 中，有了二進制分幀之后，HTTP /2 不再依賴 TCP 鏈接去實現(xiàn)多流并行了，在 HTTP/2中：
- 同域名下所有通信都在單個連接上完成。
- 單個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。
- 數(shù)據(jù)流以消息的形式發(fā)送，而消息又由一個或多個幀組成，多個幀之間可以亂序發(fā)送，因為根據(jù)幀首部的流標識可以重新組裝。
這一特性，使性能有了極大提升：
- 同個域名只需要占用一個 TCP 連接，消除了因多個 TCP 連接而帶來的延時和內(nèi)存消耗。
- 單個連接上可以并行交錯的請求和響應(yīng)，之間互不干擾。
- 在HTTP/2中，每個請求都可以帶一個31bit的優(yōu)先值，0表示最高優(yōu)先級， 數(shù)值越大優(yōu)先級越低。有了這個優(yōu)先值，客戶端和服務(wù)器就可以在處理不同的流時采取不同的策略，以最優(yōu)的方式發(fā)送流、消息和幀。
服務(wù)器推送
服務(wù)端可以在發(fā)送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請求再響應(yīng)。例如服務(wù)端可以主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時再發(fā)送這些請求。
服務(wù)端可以主動推送，客戶端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動推送也遵守同源策略，服務(wù)器不會隨便推送第三方資源給客戶端。
頭部壓縮
HTTP 1.1請求的大小變得越來越大，有時甚至?xí)笥赥CP窗口的初始大小，因為它們需要等待帶著ACK的響應(yīng)回來以后才能繼續(xù)被發(fā)送。HTTP/2對消息頭采用HPACK（專為http/2頭部設(shè)計的壓縮格式）進行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量。而HTTP/1.x每次請求，都會攜帶大量冗余頭信息，浪費了很多帶寬資源。
HTTP每一次通信都會攜帶一組頭部，用于描述這次通信的的資源、瀏覽器屬性、cookie等，例如
為了減少這塊的資源消耗并提升性能，HTTP/2對這些首部采取了壓縮策略：
- HTTP/2在客戶端和服務(wù)器端使用“字典表”來跟蹤和存儲之前發(fā)送的鍵－值對，對于相同的數(shù)據(jù)，不再通過每次請求和響應(yīng)發(fā)送；
- 字典表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進地更新;
- 每個新的首部鍵－值對要么被追加到當前表的末尾，要么替換表中之前的值。
- 字典表包括動態(tài)字典表和靜態(tài)字典表
例如：下圖中的兩個請求， 請求一發(fā)送了所有的頭部字段，第二個請求則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷。
我們來看一個實際的例子，下面是用WireShark抓取的訪問google首頁的包：
上圖是是訪問https://www.google.com/抓到的第一個請求的頭部，可以看到頭部的內(nèi)容，總共占用了437 bytes，我們選中頭部的cookie，可以看到cookie總共占用了118 bytes。接下來我們看看第二個請求的頭部：
從上圖可以看到，得益于頭部壓縮，第二個請求中cookie只占用了1個字節(jié)，我們來看看變化了的Accept字段：
由于Accept字段與請求一中的內(nèi)容不同，需要發(fā)送給服務(wù)器，所以占用了29 bytes。
結(jié)語
- HTTP/2的通過支持請求與響應(yīng)的多路復(fù)用來減少延遲
- 通過壓縮HTTP首部字段將協(xié)議開銷降至最低
- 增加對請求優(yōu)先級和服務(wù)器端推送的支持。
在進行 HTTP/2 網(wǎng)站性能優(yōu)化時很重要一點是「使用盡可能少的連接數(shù)」，本文提到的頭部壓縮是其中一個很重要的原因：同一個連接上產(chǎn)生的請求和響應(yīng)越多，動態(tài)字典積累得越全，頭部壓縮效果也就越好。所以，針對 HTTP/2 網(wǎng)站，最佳實踐是不要合并資源，不要散列域名(因為每一個不同的域名下，需要單開一個TCP鏈接，并且維護一份header字典值)
默認情況下，瀏覽器會針對這些情況使用同一個連接：
- 同一域名下的資源；
- 不同域名下的資源，但是滿足兩個條件：1、解析到同一個 IP；2、使用同一個證書
