在引出http2之前，首先要知道目前互聯(lián)網(wǎng)上大多數(shù)請求都是http1.1 月培。在互聯(lián)網(wǎng)快速發(fā)展的今天，http1.1 已經(jīng)不能適應(yīng)，盡管h2的普及率僅僅只有37.2 %（截止2019年5月份）瞭稼。http1.1 還是主流，但是h2的潮流必然勢不可擋腻惠。
目前我們的站點(diǎn)也在推進(jìn)http2的進(jìn)程环肘。所以寫一篇文章對h2的調(diào)研
HTTP 1.1 的問題
問題：傳輸串行化，效率低
- 高延遲帶來的頁面加載速度降低集灌。盡管帶寬增大悔雹，但是受制于路由器硬件，最后一公里等問題欣喧，其延遲還是大腌零。
- 并發(fā)連接有限。
-
線頭阻塞唆阿，一個HTTP（請求/響應(yīng)）完成之后益涧，才能進(jìn)行下一個。
上圖1可以看到驯鳖，隨著帶寬的增大闲询，延遲變化是有限的，尤其是4Mbps之后就沒有啥變化了浅辙，這受制于網(wǎng)絡(luò)設(shè)備等扭弧，也不完全因?yàn)閭鬏斁嚯x。
上圖2又可以看到记舆，rtt（延遲）越小鸽捻，頁面加載時間越小。
那怎么解決呢？御蒲？
這就要提到長肥管道(高延遲衣赶，高帶寬) 場景，以前是（http1.1）串行的發(fā)送删咱，如果能做到源源不斷的發(fā)和源源不斷的收屑埋，就能解決問題了。(對付長肥管道痰滋，最好的方法就是貼近其極限去發(fā)包摘能，注意不是將帶寬完全打滿，是貼近其極限敲街，這個詳細(xì)請看 長肥管道傳輸之痛與解決之道)
http1.1 做出的努力
為了解決上述問題团搞，其實(shí)http1.1 也做出了很多的事情。
- 比如chrome瀏覽器只允許一個域發(fā)起6個TCP鏈接多艇。那么如果將資源分散到不通的域名逻恐，就能盡可能多發(fā)起一些請求。
- 為了減少請求次數(shù)峻黍，將一些小圖片拼成大圖片复隆，一次性發(fā)送，這種叫做雪碧圖姆涩。
- 為了減少請求次數(shù)挽拂，還做內(nèi)聯(lián)，將圖片內(nèi)容做base64編碼嵌入到css或js中骨饿。
 雪碧圖
|
 內(nèi)聯(lián)
|
|---|
但是盡管如此亏栈，http1.1 還是沒有完美解決其痛點(diǎn)。
HTTP2 橫空出世
http2 為了能更好的推廣宏赘。其更好的發(fā)掘TCP的協(xié)議性能绒北，盡量對現(xiàn)有的HTTP協(xié)議不做改動，提供無縫的將http1.1 升級到 http2 的能力察署，如果客戶端不支持h2,那么可以再降級到http1.1 闷游。十分的友好。
訪問網(wǎng)站 https://http2.akamai.com/demo 可以看到一個 http1.1 和 http2 的對比箕母。其實(shí)這張地球的圖片是由非常多的小圖片組成的储藐。所以會大量對后端進(jìn)行請求。
http1.1
- 左上角 加載時間為5.2 s
- 中間 并發(fā)了 6個連接嘶是，看樣子，每個連接也很耗時呢蛛碌。
- 用的HTTP1.1 右下腳的waterfall 聂喇，越到后面的請求，Stalled越大（灰色部分）注意 size那列全是1.3kB
http2
- 左上角 加載時間為5.2 s
- 中間 只有一條連接，也很迅速希太。
- 用的HTTP2 右下角的waterfall克饶，其實(shí)也有 stalled，但是和http1比起來誊辉，小多了矾湃。注意 size那列全是1.1kB
為什么會有如此的差距呢
原因一：多路復(fù)用
其實(shí)上面也說了，這張地圖的照片是由很多小圖片組成的堕澄，也就是訪問的時候會由十分多的小圖片傳輸 邀跃。而h2是多路復(fù)用，所以當(dāng)然就效率高了蛙紫。
原因二：標(biāo)頭壓縮
在這里拍屑，http2 會將http報(bào)頭中的內(nèi)容進(jìn)行二進(jìn)制壓縮，其原理是利用的霍夫曼編碼（就是利用貪心算法）將數(shù)據(jù)二進(jìn)制化傳輸坑傅。另利用靜態(tài)字典和動態(tài)字典僵驰，如果傳輸過的內(nèi)容，不再重復(fù)傳輸唁毒，如一些請求都是GET請求蒜茴，則Method：Get 不會重復(fù)傳輸。
原因三：服務(wù)端推送
服務(wù)端將數(shù)據(jù)提前推送給客戶端浆西。
瀏覽器如何和服務(wù)端建立一個http2連接呢
h2 不一定必須要tls粉私，但是從瀏覽器發(fā)起的就必須要求是 tls 的∈已瑁基于tls的是 h2 毡鉴，基于 tcp 的是h2c 。所以這里主要介紹 h2 秒赤，而不是h2c猪瞬。
那么客戶端在tls握手階段會發(fā)起一個tls握手，client hello入篮。在client hello 中由一個 ALPN (Application Layer Protocol Negotiation)應(yīng)用層協(xié)議的協(xié)商陈瘦，帶上表示客戶端是支持 h2 的，服務(wù)端不支持h2的化潮售，可以退化到h1.1 痊项。
 client hello
|
 server hello
|
|---|
接下來協(xié)商好 h2 之后，就可以開始h2 的數(shù)據(jù)發(fā)送了酥诽。
參考： 極客時間的 陶輝老師鞍泉。
