（一）.HTTP發展到1.1存在的問題：
- 線頭阻塞：TCP連接上只能發送一個請求，前面的請求未完成前，後續的請求都在排隊等待。
- 多個TCP連接：雖然HTTP/1.1管線化可以支持請求併發，但是瀏覽器很難實現，chrome、firefox等都禁用了管線化。所以1.1版本請求併發依賴於多個TCP連接，建立TCP連接成本很高，還會存在慢啓動的問題。
- 頭部冗餘，採用文本格式HTTP/1.X版本是採用文本格式，首部未壓縮，而且每一個請求都會帶上cookie、user-agent等完全相同的首部。
- 客戶端需要主動請求
（二）http 2.0
1.二進制分幀層：HTTP2性能提升的核心就在於二進制分幀層。HTTP2是二進制協議，他採用二進制格式傳輸數據而不是1.x的文本格式。
1.1響應是文本格式，而2.0把響應劃分成了兩個幀，也就是說一條HTTP響應，劃分成了兩個幀來傳輸，並且採用二進制來編碼。
一個TCP連接上可以有任意數量的流。
流（Stream）：已建立的TCP連接上的雙向字節流，可以承載一個或多個消息。
消息（Message）：一個完整的HTTP請求或響應，由一個或多個幀組成。特定消息的幀在同一個流上發送，這意味着一個HTTP請求或響應只能在一個流上發送。
幀（Frame）：通信的基本單位。
2.多路複用
HTTP/1.1的線頭阻塞和多個TCP連接的問題，HTTP2的多路複用完美解決。HTTP2讓所有的通信都在一個TCP連接上完成，真正實現了請求的併發。
3.頭部壓縮：在1.X版本中，首部用文本格式傳輸，通常會給每個傳輸增加500-800字節的開銷。而每個請求帶的一些首部字段都是相同的，例如cookie、user-agent等。HTTP2爲此採用HPACK壓縮格式來壓縮首部。頭部壓縮需要在瀏覽器和服務器端之間：
維護一份相同的靜態字典，包含常見的頭部名稱，以及常見的頭部名稱和值的組合
維護一份相同的動態字典，可以動態的添加內容
通過靜態Huffman編碼對傳輸的首部字段進行編碼
4.服務器端推送：主動推送到客戶端。
例如：客戶端請求index.html，服務器端能夠額外推送script.js和style.css。
實現原理就是客戶端發出頁面請求時，服務器端能夠分析這個頁面所依賴的其他資源，主動推送到客戶端的緩存，當客戶端收到原始網頁的請求時，它需要的資源已經位於緩存。
參考文章：https://juejin.im/post/5c0ce870f265da61171c8c66#heading-4
（三）websocket協議和 HTTP2 有關係麼？
WebSocket是HTML5出的（協議），由於使用HTTP和HTTPS的端口，因此TCP連接建立後的握手消息是基於HTTP的，但是WebSocket連接除了建立和關閉時的握手，數據傳輸和HTTP沒丁點關係了。
WebSocket則提供使用一個TCP連接進行雙向通訊的機制，包括網絡協議和API，以取代網頁和服務器採用HTTP輪詢進行雙向通訊的機制。
HTTP/2 完全不能替代websocket，各有各的適用場景。做app還是偏向於websocket
原因：
- HTTP/2 Server Push 不能被代碼使用，所以還得配合SSE(Server sentevent)，無論從coder還是運維的角度來看，這混搭增加了複雜度。 IE對http2以及SSE都支持的不好
- HTTP/2連接不確定性會永遠保持連接，而websocket有onclose事件，對代碼友好
- 多個tab頁windows頁可能共用一個HTTP/2連接，你無法知道Server Push來自哪一個 由於多路複用
- 實際狀態 HTTP2 vs Websocket 顯而易見，http2 在瀏覽器服務器上限制頗多，而 websocket 基本普及。