http2中多路復用的示例分析

這篇文章主要介紹了http2中多路復用的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

回顧http1.1協議，我們了解到，雖然http1.1實現了tcp的長連接，在一個tcp鏈接通道中，我們可以連續處理多個http請求響應，但是這個處理過程是半雙工模式，也就是同一時刻只能處理一個request的請求或者響應，后面的request必須等到前面的請求響應之后才能進行。

瀏覽器為了更加快速的加載頁面資源，于是針對同一域名設置了最大并發數，這樣做能稍微加快速度，但是也帶了一些問題，參看上一篇文章http1.1相對http2有哪些不足。

http2完全摒棄http1.1半雙工通信的方式，實現了全雙工通信，具體表現為：瀏覽器針對同一個域名的資源，只建立一個tcp連接通道，所有的針對這個域名的請求全部在這個通道中完成，并且引入了流的機制，這條通道可以同時處理多個request，這不同于http1.1的pepeline，http2的多路復用，對于request的響應并不會因為上一個request的響應未完成而阻塞，http2徹底解決了http層面的隊頭阻塞。

http2中在一個tcp通道中的所有http請求不分先后，不會阻塞，同樣是一個頁面中多個資源同時去請求，用http2來實現的話，過程如圖：

這張圖與上一篇文章中http1.1版本中的圖是有區別的，可以看到這里http請求并不會因為前面的請求未響應而阻塞。

我們來通過幾張圖來演示一下http1.1到http1.1的pipeline在到http2的進化。

先看第一張圖：

仔細觀察上圖，發現在http1.1版本中的一個tcp通道中，這是一個單通道，同一時刻只能處理一個http請求，并且必須按照順序。

再看第二張圖：

仔細觀察這張圖，雖然在一個tcp通道中實現了多個http并發，但是返回的時候是會阻塞的，誰先到達，誰先返回，順序絕對不能亂，這就是http1.1pipeline的弊端。還有另一個pipeline的限制，只能是冪等請求（get、head等）才能應用pipeline，大部分瀏覽器默認是關閉pipeline的。

再看第三張圖：

這張圖中在一個tcp鏈接通道中，同時進行多個http請求和響應，仔細觀察請求順序和響應順序無關，速度相對于上面兩張圖明顯變快，并且頁面中的資源請求都在一個tcp通道中完成，有效的避免了tcp競速，慢啟動等因素。

上面只是演示了http2的傳輸方式，那么他是如何實現的呢？

http1.1是明文協議，解析http1.1的明文是基于文本。http2.0的協議采用的是二進制格式。

http2為什么要采用二進制格式呢？

1、基于文本解析的話，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多。

2、二進制則只認0和1的組合，解析速度更快。

那么在不改動 HTTP/1.1 的語義、?法、狀態碼、URI 以及?部字段等等的情況下, HTTP/2 是如何過渡到http1.1呢? 

關鍵之?就是在應?層(HTTP/2)和傳輸層(TCP or UDP)之間增加?個?進制分幀層。如圖：

在?進制分幀層中， HTTP/2 會將所有傳輸的信息分割為更?的消息并封裝在幀（frame）中,并對它們采??進制格式的編碼 ，其中 HTTP1.1的?部信息會被封裝到 HEADER frame，?相應的 Request Body 則封裝到 DATA frame ??。如上圖的HEADER frame和DATA frame分別對應http1.1的請求頭和請求體。

對比如圖：

并且，HTTP/2 通信都在?個tcp連接上完成，這個連接會同時處理多個http的request，http2給每個http的request都分配唯一的streamId，而每個request切割出來的fram都共用這個streamId，這樣的話http2就可以基于這個streamid將切割的信息還原，http2通道中同時處理多個request的方式類似處理多個流，所以有些文章會指出http2實現了流方式傳遞信息。如圖：

上圖中每個大的藍色方塊代表一個http的request，每個request被切割為多個fream，并且被編號，我們用黃紅綠三種顏色分別代表三個stream流，不同的顏色代表不同的streamid，http2接收到數據會根據其streamid自動還原數據，這樣就實現了在一個TCP連接通道中的流式傳輸，多個request都會復用這個TCP通道，實現了高效的復用。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“http2中多路復用的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!