前言
本系列基于HTTP/2第17個草案文檔，地址就是：https://tools.ietf.org/html/draft-ietf-httpbis-http2-17。
HTTP/2規(guī)范已經(jīng)通過發(fā)布批準，下面等待分配具體的RFC號碼，不會有所較大的變動了。
本筆記不是直接翻譯，記錄成筆記方便以后學習。
HTTP/1.1的問題
一張圖可以很較為全面的概括了HTTP/1.*存在缺陷：
前端一般采用： - CSS Spriting，小圖合并成大圖，CSS進行分割成小圖顯示 - Inlining，使用DataURL方式內(nèi)嵌Base64編碼格式圖片 - JS Concatenation，多個JS文件合并成一個，缺陷是一旦有文件修改，需要重新合并 - Sharding，將資源/服務部署到多個機器上，均攤/分享請求壓力
HTTP/1.*沒有充分利用TCP特性，再加上同一個站點打開多個連接等，導致網(wǎng)絡資源利用率不高。
HTTP/2改進點
與HTTP/1相比，主要區(qū)別包括：
- HTTP/2采用二進制格式而非文本格式
- 高效緊湊傳輸解析
- 更少錯誤傾向，沒有了所謂的空白行、大寫、換行符、空連接等
- HTTP/2是完全多路復用的，而非有序并阻塞的
- HTTP/1.1默認情況下單個請求單個連接
- HTTP/1.1流水線化pipelining方式導致較大/較慢的響應阻塞后續(xù)任務
- HTTP/1.1無法解決線頭阻塞的問題
- 多路復用可以有效避免線頭阻塞，多個請求-響應同一個連接內(nèi)并行處理
- 只需一個連接即可實現(xiàn)并行
- HTTP/1.*請求處理模型導致同一個站點資源客戶端需要打開若4-8個連接請求
- HTTP/1.*多個連接會占用過多網(wǎng)路資源，導致TCP堵塞和數(shù)據(jù)重傳
- HTTP/2單個連接內(nèi)多個流（請求-響應）之間并行處理，減少網(wǎng)路資源占用，可避免了TCP頻繁的打開、關閉
- 使用報頭壓縮，HTTP/2降低了開銷
- 傳統(tǒng)瀏覽器網(wǎng)路報頭一般在80-1400字節(jié)大小
- 壓縮頭部可讓報頭更緊湊，更快速傳輸，有利于移動網(wǎng)絡環(huán)境等
- 壓縮算法使用HPACK，更為高效、安全
- HTTP/2讓服務器可以將響應主動“推送”到客戶端
- 傳統(tǒng)方式：客戶端請求，服務器響應，客戶端逐一解析需要后續(xù)請求的圖片、樣式等資源，再次一一發(fā)送資源請求
- HTTP/2服務器根據(jù)客戶端請求，計算出響應內(nèi)容所包含的資源，在客戶端發(fā)起請求之前提前發(fā)送給客戶端
- 節(jié)省客戶端主動發(fā)起請求的時間的往返時間
這里有一張圖，可以總體上了解HTTP/2：
HTTP/2的解讀
保留/兼容HTTP/1.1的所有語義，但傳輸語法（或者說傳輸方式）改變，目的在于更充分利用TCP更高效傳輸，多路復用是實現(xiàn)途徑，低延遲是改進方向。
筆記提綱
以上為簡單總體介紹了HTTP/2協(xié)議，要想深入其特性，需要閱讀器規(guī)范。下面為圍繞HTTP/2規(guī)范的各個方面，列出提綱，便于后面一一填充。
- HTTP/2的連接建立
- HTTP/2的多路復用和流的屬性
- HTTP/2的幀定義
- HTTP/2的消息交換
- HTTP/2的錯誤處理和安全事項
名詞解釋
以下名詞會在當前或以后筆記中出現(xiàn)，貼出來方便理解。
- 中介（intermediation），指代包含代理、企業(yè)防火墻、反向代理和CDN等互聯(lián)網(wǎng)設備
- ALPN，Application Layer Protocol Negotiation
- 報頭，報文頭部，請求報文頭部，或響應報文頭部
小結(jié)
HTTP/2相比HTTP/1.1，可以做到更有效的充分利用TCP連接，避免了TCP連接的重復的創(chuàng)建（三次握手）、銷毀（四次揮手）的過程。
引用
- 《HTTP/2 WebRTC all the things !》
- 《Implementing HTTP/2 client in 60 minutes》