瞭解 HTTP/1.x 的 keep-alive 嗎？它與 HTTP/2 多路複用的區別是什麼？

引言

本文分爲如下三部分按部就班走進 HTTP/1.x 的 keep-alive 與 HTTP/2 多路複用：

• HTTP/1.x keep-alive 是什麼
• HTTP/2 多路複用
• HTTP/1.x keep-alive 與 HTTP/2 多路複用區別

下面正式開始吧

HTTP/1.x keep-alive

在一文走進 TCP 與 HTTP 中，咱們介紹過，HTTP 協議是創建在 TCP 協議上的應用層協議， HTTP 協議最初是一個很是簡單的協議，通訊方式也是採起簡答的請求-應答的模式，即：客戶端與服務器端的的每次請求都須要建立 TCP 鏈接，服務器響應後斷開 TCP 鏈接，再請求再建立斷開。

在 HTTP/0.9 與 早期 HTTP/1.0 中，默認的就是這種，但這種頻繁的建立、斷開鏈接無疑是極大的消耗性能

TCP鏈接的新建成本很高，由於客戶端和服務器創建鏈接時須要「三次握手」，發送 3 個數據包，須要 1 個 RTT；關閉鏈接是「四次揮手」，4 個數據包須要 2 個 RTT，而且開始時發送速率較慢（slow start），隨着網頁加載的外部資源愈來愈多，這個問題就愈發突出了

因此 HTTP/1.0 引入了 keep-alive 長鏈接，HTTP/1.0 中是默認關閉的，能夠經過 Connection: keep-alive; 開啓 ，HTTP/1.1 默認是開啓的，不管加沒加 Connection: keep-alive;

所謂長鏈接，即在 HTTP 請求創建 TCP 鏈接時，請求結束，TCP 鏈接不斷開，繼續保持一段時間（timeout），在這段時間內，同一客戶端向服務器發送請求都會複用該 TCP 鏈接，並重置 timeout 時間計數器，在接下來 timeout 時間內還能夠繼續複用 TCP 。這樣無疑省略了反覆建立和銷燬 TCP 鏈接的損耗。

timeout 時間到了以後，TCP會當即斷開鏈接嗎？

若兩小時（timeout）沒有收到客戶的數據，服務器就發送一個探測報文段，之後則每隔 75 秒發送一次。若一連發送 10 個探測報文段後仍無客戶的響應，服務器就認爲客戶端出了故障，接着就關閉這個鏈接。

——摘自謝希仁《計算機網絡》

HTTP/2 多路複用

爲何 HTTP/2 引入多路複用？

這是由於：

• HTTP/1.x 雖然引入了 keep-alive 長鏈接，但它每次請求必須等待上一次響應以後才能發起，
• 因此，在 HTTP/1.1 中提出了管道機制（默認不開啓），下一次的請求不須要等待上一個響應來以後再發送，但這要求服務端必須按照請求發送的順序返回響應，當順序請求多個文件時，其中一個請求由於某種緣由被阻塞時，在後面排隊的全部請求也一併被阻塞，這就是隊頭阻塞 (Head-Of-Line Blocking)
• 人們採起了不少方法去解決，例如使用多個域名、引入雪碧圖、將小圖內聯等，但都沒有從根本上解決問題

HTTP/2 是怎麼作的喃？

• 首先它引入了 幀（frame）和流（stream），由於 HTTP/1.x 是基於文本的，由於是文本，就致使了它必須是個總體，在傳輸是不可切割的，只能總體去傳
• 既然，HTTP/2 是基於二進制流的，它就能夠把 HTTP 消息分解爲獨立的幀，交錯發送，而後在另外一端經過幀中的標識從新組裝，這就是多路複用
• 這就實現了在同一個TCP鏈接中，同一時刻能夠發送多個請求和響應，且不用按照順序一一對應，即便某個請求任務耗時嚴重，也不會影響到其它鏈接的正常執行

HTTP/1.x keep-alive 與 HTTP/2 多路複用區別

總結一下，HTTP/1.x keep-alive 與 HTTP/2 多路複用區別：

• HTTP/1.x 是基於文本的，只能總體去傳；HTTP/2 是基於二進制流的，能夠分解爲獨立的幀，交錯發送

• HTTP/1.x keep-alive 必須按照請求發送的順序返回響應；HTTP/2 多路複用不按序響應

• HTTP/1.x keep-alive 爲了解決隊頭阻塞，將同一個頁面的資源分散到不一樣域名下，開啓了多個 TCP 鏈接；HTTP/2 同域名下全部通訊都在單個鏈接上完成

• HTTP/1.x keep-alive 單個 TCP 鏈接在同一時刻只能處理一個請求（兩個請求的生命週期不能重疊）；HTTP/2 單個 TCP 同一時刻能夠發送多個請求和響應

天天三分鐘，進階一個前端小 tip 面試題庫 算法題庫