前言

HTTP 2.0是由谷歌SPDY進化而來，現有的實現基本都是走SSL（說是可以不用SSL，但基本沒這么干的），傳輸層使用TCP。
HTTP 3.0是由谷歌QUIC進化出來的，QUIC沒有大動HTTP 2.0，在把傳輸層調整為UDP后，為適應UDP而做了一些微調。

HTTP 2問題

前篇已整體介紹HTTP 2，就此，此篇只說下HTTP/2的問題

在底層使用了TCP的情況下，TCP的慢啟動；擁塞窗口尺寸設置不合理導致的性能急劇下降的問題沒有得到解決。基因在此，無法改變
HTTP 2多路復用只是減少了連接數，隊頭阻塞的問題并沒有得到完全解決。如果TCP丟包率超過2%，HTTP/2表現將不如HTTP1.1。因為HTTP1 是分開使用的TCP連接,具體對比如下示意圖所示：

HTTP 3

HTTP 3是在QUIC基礎上發展出來的。底層使用UDP進行數據傳輸，但上層仍然使用HTTP/2。HTTP2與UDP之前存在一個QUIC層，TLS加密過程在此層處理。QUICK存在兩個版本，早期Google打頭陣的QUIC稱之為gQUIC，IETF標準化后稱之為IQUIC。與HTTP對比，HTTP/3整體如下:

整個HTTP家族對比如下：

HTTP3特點:

使用UDP作為傳輸層進行通信
從協議本身保證了安全性，QUIC在建立連接的握手過程中就完成了TLS加密握手

建立連接快，正常只需要1RTT即可建立連接。如果有緩存之前的secret信息，則直接驗證和建立連接，此過程0RTT。建立連接時，也可以帶有少量業務數據。

不和具體底層連接綁定，QUIC為每個連接的兩端分別分配了一個唯一ID，上層連接只認這對邏輯ID。網絡切換或者斷連時，只需要繼續發送數據包即可完成連接的建立

使用QPACK進行頭部壓縮，因為HPACK要求傳輸過程有序，這會導致隊頭阻塞。而QPACK不存在這個問題
HTTP/3在header中定義了一個新header:Alt-Svc: h3=":20003":表示服務器在20003端口開了一個20003端口用于HTTP/3服務

補充

使用以下代碼可以判斷是否有使用HTTP/2

(function(){
  // 保證這個方法只在支持loadTimes的chrome瀏覽器下執行
  if(window.chrome && typeof chrome.loadTimes === 'function') {
      var loadTimes = window.chrome.loadTimes();
      var spdy = loadTimes.wasFetchedViaSpdy;
      var info = loadTimes.npnNegotiatedProtocol || loadTimes.connectionInfo;
      // 就以 「h2」作為判斷標識
      if(spdy && /^h2/i.test(info)) {
          return console.info('本站點使用了HTTP/2');
      }
  }
  console.warn('本站點沒有使用HTTP/2');
})();

QUIC詳細介紹-->維基百科
QPACK詳細介紹-->點擊此處

參考資料

關于HTTP/3背后你所不知道的
HTTP/3 來啦，你還在等什么？趕緊了解一下
What is the QUIC Transport Protocol?
我的HTTP/3學習筆記
一文讀懂 HTTP/2 及 HTTP/3 特性

歡迎大家關注我的公眾號：

總結

以上是生活随笔為你收集整理的HTTP/3 简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。