目前越來越多的網(wǎng)站開始使用 HTTP/2搓劫，那么我們就需要加深一下對HTTP/2的了解
- HTTP/2 相對于 HTTP/1.1 的優(yōu)勢
- 部署HTTP/2
- 如何使用 HTTP/2 提升性能https://www.w3ctech.com/topic/1563#tip7sharding
HTTP/2 相對于 HTTP/1.1 的優(yōu)勢
可以使用「Akamai 這個頁面」來直觀的感受一下兩者的區(qū)別。
多路復用
多路復用允許同時通過單一的 HTTP/2 連接發(fā)起多重的請求-響應消息橡羞。
在 HTTP/1.1 協(xié)議中 瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數(shù)量限制谣旁。超過限制數(shù)目的請求會被阻塞秦陋。不同瀏覽器的限制數(shù)目也不盡相同。
由此產(chǎn)生的多種技術：
- 多個靜態(tài)資源 CDN 域名
- 雪碧圖 CSS Sprite
- 內(nèi)嵌圖片 inline image
都是為了解決瀏覽器針對同一域名的請求限制阻塞問題导俘。
因此 HTTP/2 可以很容易的去實現(xiàn)多流并行而不用依賴建立多個 TCP 連接众旗，HTTP/2 把 HTTP 協(xié)議通信的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的消息趟畏。并行地在同一個 TCP 連接上雙向交換信息贡歧。
二進制分幀
在不改動 HTTP/1.x 的語義、方法、狀態(tài)碼利朵、URI 以及首部字段….. 的情況下, HTTP/2 是如何做到「突破 HTTP1.1 的性能限制律想，改進傳輸性能，實現(xiàn)低延遲和高吞吐量」的 ?
關鍵之一就是在 應用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個二進制分幀層绍弟。
在二進制分幀層中技即， HTTP/2 會將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對它們采用二進制格式的編碼 ，其中 HTTP1.x 的首部信息會被封裝到 HEADER frame樟遣，而相應的 Request Body 則封裝到 DATA frame 里面而叼。
HTTP/2 通信都在一個連接上完成，這個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流豹悬。
在過去葵陵， HTTP 性能優(yōu)化的關鍵并不在于高帶寬，而是低延遲瞻佛。TCP 連接會隨著時間進行自我「調(diào)諧」脱篙，起初會限制連接的最大速度，如果數(shù)據(jù)成功傳輸伤柄，會隨著時間的推移提高傳輸?shù)乃俣劝砝А＿@種調(diào)諧則被稱為 TCP 慢啟動。由于這種原因适刀，讓原本就具有突發(fā)性和短時性的 HTTP 連接變的十分低效秤朗。
HTTP/2 通過讓所有數(shù)據(jù)流共用同一個連接，可以更有效地使用 TCP 連接笔喉，讓高帶寬也能真正的服務于 HTTP 的性能提升取视。
總結(jié)：
- 單連接多資源的方式，減少服務端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大
- 由于 TCP 連接的減少而使網(wǎng)絡擁塞狀況得以改善然遏，同時慢啟動時間的減少,使擁塞和丟包恢復速度更快
首部壓縮
HTTP/1.1并不支持 HTTP 首部壓縮贫途，為此 SPDY 和 HTTP/2 應運而生， SPDY 使用的是通用的 DEFLATE 算法待侵，而 HTTP/2 則使用了專門為首部壓縮而設計的 HPACK 算法丢早。
服務端推送
服務端推送是一種在客戶端請求之前發(fā)送數(shù)據(jù)的機制。在 HTTP/2 中秧倾，服務器可以對客戶端的一個請求發(fā)送多個響應怨酝。Server Push 讓 HTTP1.x 時代使用內(nèi)嵌資源的優(yōu)化手段變得沒有意義；如果一個請求是由你的主頁發(fā)起的那先，服務器很可能會響應主頁內(nèi)容农猬、logo 以及樣式表，因為它知道客戶端會用到這些東西售淡。這相當于在一個 HTML 文檔內(nèi)集合了所有的資源斤葱，不過與之相比慷垮，服務器推送還有一個很大的優(yōu)勢：可以緩存！也讓在遵循同源的情況下揍堕，不同頁面之間可以共享緩存資源成為可能料身。
一個常見的問題是：「如果客戶端早已在緩存中有了一份 copy 怎么辦？」
一個推薦的解決方案是衩茸，客戶端使用一個簡潔的 Cache Digest 來告訴服務器芹血，哪些東西已經(jīng)在緩存，因此服務器也就會知道哪些是客戶端所需要的楞慈。
瀏覽器客戶端可以通過一個連接發(fā)送少于 1K 字節(jié)的 Packets 給服務端幔烛，通知哪些是已經(jīng)在緩存中存在的。
部署HTTP/2
參考其他大神的文章：
如何使用 HTTP/2 提升性能
參考其他大神的文章：
