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