淺析HTTP/2的多路複用

HTTP/2有三大特性：頭部壓縮、Server Push、多路複用。前兩個特性意思比較明確，也好理解，惟有多路複用不太好理解，尤爲是和HTTP1.1進行對比的時候，這個問題我想了很長時間，也對比了很長時間，如今把思考的結果分享出來，但願對你們有幫忙。

先來講說Keep-Alive

在沒有Keep-Alive前，咱們與服務器請求數據的流程是這樣：

• 瀏覽器請求//static.mtime.cn/a.js-->解析域名-->HTTP鏈接-->服務器處理文件-->返回數據-->瀏覽器解析、渲染文件
• 瀏覽器請求//static.mtime.cn/b.js-->解析域名-->HTTP鏈接-->服務器處理文件-->返回數據-->瀏覽器解析、渲染文件
• ...
• ...
• ...
• 這樣循環下去，直至所有文件下載完成。

這個流程最大的問題就是：每次請求都會創建一次HTTP鏈接，也就是咱們常說的3次握手4次揮手，這個過程在一次請求過程當中佔用了至關長的時間，並且邏輯上是非必需的，由於不間斷的請求數據，第一次創建鏈接是正常的，之後就佔用這個通道，下載其餘文件，這樣效率多高啊！你猜對了，這就是Keep-Alive。

Keep-Alive解決的問題

Keep-Alive解決的核心問題：必定時間內，同一域名屢次請求數據，只創建一次HTTP請求，其餘請求可複用每一次創建的鏈接通道，以達到提升請求效率的問題。這裏面所說的必定時間是能夠配置的，無論你用的是Apache仍是nginx。

HTTP1.1仍是存在效率問題

如上面所說，在HTTP1.1中是默認開啓了Keep-Alive，他解決了屢次鏈接的問題，可是依然有兩個效率上的問題：

• 第一個：串行的文件傳輸。當請求a文件時，b文件只能等待，等待a鏈接到服務器、服務器處理文件、服務器返回文件，這三個步驟。咱們假設這三步用時都是1秒，那麼a文件用時爲3秒，b文件傳輸完成用時爲6秒，依此類推。（注：此項計算有一個前提條件，就是瀏覽器和服務器是單通道傳輸）
• 第二個：鏈接數過多。咱們假設Apache設置了最大併發數爲300，由於瀏覽器限制，瀏覽器發起的最大請求數爲6，也就是服務器能承載的最高併發爲50，當第51我的訪問時，就須要等待前面某個請求處理完成。

HTTP/2的多路複用

HTTP/2的多路複用就是爲了解決上述的兩個性能問題，咱們來看一下，他是如何解決的。

• 解決第一個：在HTTP1.1的協議中，咱們傳輸的request和response都是基本於文本的，這樣就會引起一個問題：全部的數據必須按順序傳輸，好比須要傳輸：hello world，只能從h到d一個一個的傳輸，不能並行傳輸，由於接收端並不知道這些字符的順序，因此並行傳輸在HTTP1.1是不能實現的。

HTTP/2引入二進制數據幀和流的概念，其中幀對數據進行順序標識，以下圖所示，這樣瀏覽器收到數據以後，就能夠按照序列對數據進行合併，而不會出現合併後數據錯亂的狀況。一樣是由於有了序列，服務器就能夠並行的傳輸數據，這就是流所作的事情。

• 解決第二個問題：HTTP/2對同一域名下全部請求都是基於流，也就是說同一域名無論訪問多少文件，也只創建一路鏈接。一樣Apache的最大鏈接數爲300，由於有了這個新特性，最大的併發就能夠提高到300，比原來提高了6倍！

之前咱們作的性能優化不適用於HTTP/2了

• JS文件的合併。咱們如今優化的一個主要方向就是儘可能的減小HTTP的請求數， 對咱們工程中的代碼，研發時分模塊開發，上線時咱們會把全部的代碼進行壓縮合並，合併成一個文件，這樣無論多少模塊，都請求一個文件，減小了HTTP的請求數。可是這樣作有一個很是嚴重的問題：文件的緩存。當咱們有100個模塊時，有一個模塊改了東西，按照以前的方式，整個文件瀏覽器都須要從新下載，不能被緩存。如今咱們有了HTTP/2了，模塊就能夠單獨的壓縮上線，而不影響其餘沒有修改的模塊。
• 多域名提升瀏覽器的下載速度。以前咱們有一個優化就是把css文件和js文件放到2個域名下面，這樣瀏覽器就能夠對這兩個類型的文件進行同時下載，避免了瀏覽器6個通道的限制，這樣作的缺點也是明顯的，1.DNS的解析時間會變長。2.增長了服務器的壓力。有了HTTP/2以後，根據上面講的原理，咱們就不用這麼搞了，成本會更低。