基于QUIC 協定的HTTP/3

HTTP/2 存在一些比較嚴重的與 TCP 協定相關的缺陷，但由于 TCP 協定僵化，我們幾乎不可能通過修改 TCP 協定自身來解決這些問題，那麼解決問題的思路是繞過 TCP 協定，發明一個 TCP 和 UDP 之外的新的傳輸協定。但是這也面臨着和修改 TCP 一樣的挑戰，因為中間裝置的僵化，這些裝置隻認 TCP 和 UDP，如果采用了新的協定，新協定在這些裝置同樣不被很好地支援。

HTTP/3 選擇了一個折衷的方法——UDP 協定，基于 UDP 實作了類似于 TCP 的多路資料流、傳輸可靠性等功能，我們把這套功能稱為 QUIC 協定。關于 HTTP/2 和 HTTP/3 協定棧的比較。

通過上圖我們可以看出，HTTP/3 中的 QUIC 協定集合了以下幾點功能。

• 實作了類似 TCP 的流量控制、傳輸可靠性的功能。雖然 UDP 不提供可靠性的傳輸，但 QUIC 在 UDP 的基礎之上增加了一層來保證資料可靠性傳輸。它提供了資料包重傳、擁塞控制以及其他一些 TCP 中存在的特性。
• 內建了 TLS 加密功能。目前 QUIC 使用的是 TLS1.3，相較于早期版本 TLS1.3 有更多的優點，其中最重要的一點是減少了握手所花費的 RTT 個數。
• 實作了 HTTP/2 中的多路複用功能。和 TCP 不同，QUIC 實作了在同一實體連接配接上可以有多個獨立的邏輯資料流。實作了資料流的單獨傳輸，就解決了 TCP 中隊頭阻塞的問題。
• 實作了快速握手功能。由于 QUIC 是基于 UDP 的，是以 QUIC 可以實作使用 0-RTT 或者 1-RTT 來建立連接配接，這意味着 QUIC 可以用最快的速度來發送和接收資料，這樣可以大大提升首次打開頁面的速度。

通過上面的分析，我們相信在技術層面，HTTP/3 是個完美的協定。不過要将 HTTP/3 應用到實際環境中依然面臨着諸多嚴峻的挑戰，這些挑戰主要來自于以下三個方面。

第一，從目前的情況來看，伺服器和浏覽器端都沒有對 HTTP/3 提供比較完整的支援。Chrome 雖然在數年前就開始支援 Google 版本的 QUIC，但是這個版本的 QUIC 和官方的 QUIC 存在着非常大的差異。

第二，部署 HTTP/3 也存在着非常大的問題。因為系統核心對 UDP 的優化遠遠沒有達到 TCP 的優化程度，這也是阻礙 QUIC 的一個重要原因。

第三，中間裝置僵化的問題。這些裝置對 UDP 的優化程度遠遠低于 TCP，據統計使用 QUIC 協定時，大約有 3%～7% 的丢包率。

此文章為2月Day16學習筆記，内容來源于極客時間《浏覽器工作原理與實踐》，推薦該課程。