HTTP/2 可以說是google早些年推出的SPDY方案的升級版，HTTP2.0 跟 SPDY 不同的地方主要是以下兩點：
- HTTP2.0 支持明文 HTTP 傳輸，SPDY 強制使用 HTTPS
- HTTP2.0 消息頭的壓縮算法采用 HPACK，而非 SPDY 采用的 DEFLATE
HTTP/2 相較與HTTP/1.1 基本語義是不變的，主要的變化在於以下幾點：
1、多路復用
多路復用允許同時通過單一的 HTTP連接發起多重的請求-響應消息，這樣就可以實現多流並行而不用依賴建立多個 TCP 連接。如圖所示：
2、二進制幀
HTTP/1.1報文是文本格式，HTTP/2中則為二進制格式：
3、首部壓縮
HTTP2.0在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發送的鍵-值對，對於相同的數據，不再通過每次請求和響應發送；通信期間幾乎不會改變的通用鍵-值對（用戶代理、可接受的媒體類型，等等）只需發送一次。事實上, 如果請求中不包含首部（例如對同一資源的輪詢請求），那么首部開銷就是零字節。此時所有首部都自動使用之前請求發送的首部。
如果首部發生變化了，那么只需要發送變化了數據在Headers幀里面，新增或修改的首部幀會被追加到“首部表”，如下圖所示。首部表在 HTTP2.0的連接存續期內始終存在,由客戶端和服務器共同漸進地更新。
4、服務端推送
在HTTP/1.1中，當瀏覽器請求一個網頁后，服務器將會發回HTML，服務器需要等待瀏覽器解析HTML后發送所有內嵌資源的請求，在瀏覽器發送了資源的請求后服務器才開始發送這些JavaScript、圖片和CSS。HTTP/2 的服務器推送所作的工作就是，服務器在收到客戶端對某個資源的請求時，會判斷客戶端十有八九還要請求其他的什么資源，然后一同把這些資源都發送給客戶端，即便客戶端還沒有明確表示它需要這些資源。客戶端可以選擇把額外的資源放入緩存中（所以這個特點也叫 Cache push），也可以選擇發送一個 RST_STREAM frame 拒絕任何它不想要的資源。
服務器推送是 HTTP/2 協議里面，唯一一個需要開發者自己配置的功能。其他功能都是服務器和瀏覽器自動實現，不需要開發者關心。
服務器推送有一個很麻煩的問題。所要推送的資源文件，如果瀏覽器已經有緩存，推送就是浪費帶寬。即使推送的文件版本更新，瀏覽器也會優先使用本地緩存。一種解決辦法是，只對第一次訪問的用戶開啟服務器推送。下面是 Nginx 官方給出的示例，根據 Cookie 判斷是否為第一次訪問：
server { listen 443 ssl http2 default_server; ssl_certificate ssl/certificate.pem; ssl_certificate_key ssl/key.pem; root /var/www/html;http2_push_preload on; location = /demo.html { add_header Set-Cookie "session=1"; add_header Link $resources; }}map $http_cookie $resources {"~*session=1""";default"</style.css>; as=style; rel=preload";}
服務器推送可以提高性能，大概會比HTTP/1.1快了幾百毫秒，提升程度也不是特別多，而且，也不建議一次推送太多資源，這樣反而會拖累性能，因為瀏覽器不得不處理所有推送過來的資源。只推送 CSS 樣式表可能是一個比較好的選擇。
5、主動重置鏈接
HTTP消息被送出之后，我們就很難中斷它了。當然，通常我們可以斷開整個TCP鏈接（但也不總是可以這樣），但這樣導致的代價就是需要重新通過三次握手建立一個新的TCP連接。比如，很多app客戶端都有取消圖片下載的功能場景，對於http1.x來說，是通過設置tcp segment里的reset flag來通知對端關閉連接的，這種方式會直接斷開連接，下次再發請求就必須重新建立連接。http2.0引入RST_STREAM類型的frame，使用它來讓客戶端在已有的連接中發送重置請求，這樣可以在不斷開連接的前提下取消某個request的stream，即中斷或者放棄響應。當瀏覽器進行頁面跳轉或者用戶取消下載時，它可以防止建立新連接。