HTTP/1 和 HTTP/2，在 HTTP/2 出現之前，開發者需要采取很多變通的方式來解決 HTTP/1 所存在的問題，不過 HTTP/2 在 2018 年就開始得到了大規模的應用，HTTP/1 中存在的一大堆缺陷都得到了解決。
HTTP/2 的一個核心特性是使用了多路複用技術，是以它可以通過一個 TCP 連接配接來發送多個 URL 請求。多路複用技術能充分利用帶寬，最大限度規避了 TCP 的慢啟動所帶來的問題，同時還實作了頭部壓縮、伺服器推送等功能，使得頁面資源的傳輸速度得到了大幅提升。在 HTTP/1.1 時代，為了提升并行下載下傳效率，浏覽器為每個域名維護了 6 個 TCP 連接配接；而采用 HTTP/2 之後，浏覽器隻需要為每個域名維護 1 個 TCP 持久連接配接，同時還解決了 HTTP/1.1 隊頭阻塞的問題。
從目前的情況來看，HTTP/2 似乎可以完美取代 HTTP/1 了，不過 HTTP/2 依然存在一些缺陷，于是就有了 HTTP/3。和通常一樣，介紹 HTTP/3 之前，我們先來看看 HTTP/2 到底有什麼缺陷。
TCP 的隊頭阻塞
雖然 HTTP/2 解決了應用層面的隊頭阻塞問題，不過和 HTTP/1.1 一樣，HTTP/2 依然是基于 TCP 協定的，而 TCP 最初就是為了單連接配接而設計的。你可以把 TCP 連接配接看成是兩台計算機之前的一個虛拟管道，計算機的一端将要傳輸的資料按照順序放入管道，最終資料會以相同的順序出現在管道的另外一頭。
接下來我們就來分析下 HTTP/1.1 協定棧中 TCP 是如何傳輸資料的。為直覺了解，你可以參考下圖：
通過上圖你會發現，從一端發送給另外一端的資料會被拆分為一個個按照順序排列的資料包，這些資料包通過網絡傳輸到了接收端，接收端再按照順序将這些資料包組合成原始資料，這樣就完成了資料傳輸。
不過，如果在資料傳輸的過程中，有一個資料因為網絡故障或者其他原因而丢包了，那麼整個 TCP 的連接配接就會處于暫停狀态，需要等待丢失的資料包被重新傳輸過來。你可以把 TCP 連接配接看成是一個按照順序傳輸資料的管道，管道中的任意一個資料丢失了，那之後的資料都需要等待該資料的重新傳輸。為了直覺了解，你可以參考下圖：
我們就把在 TCP 傳輸過程中，由于單個資料包的丢失而造成的阻塞稱為 TCP 上的隊頭阻塞。
那隊頭阻塞是怎麼影響 HTTP/2 傳輸的呢？首先我們來看正常情況下 HTTP/2 是怎麼傳輸多路請求的，為了直覺了解，你可以參考下圖：
通過該圖，我們知道在 HTTP/2 中，多個請求是跑在一個 TCP 管道中的，如果其中任意一路資料流中出現了丢包的情況，那麼就會阻塞該 TCP 連接配接中的所有請求。這不同于 HTTP/1.1，使用 HTTP/1.1 時，浏覽器為每個域名開啟了 6 個 TCP 連接配接，如果其中的 1 個 TCP 連接配接發生了隊頭阻塞，那麼其他的 5 個連接配接依然可以繼續傳輸資料。
是以随着丢包率的增加，HTTP/2 的傳輸效率也會越來越差。有測試資料表明，當系統達到了 2% 的丢包率時，HTTP/1.1 的傳輸效率反而比 HTTP/2 表現得更好。
TCP 建立連接配接的延時
除了 TCP 隊頭阻塞之外，TCP 的握手過程也是影響傳輸效率的一個重要因素。
為了搞清楚 TCP 協定建立連接配接的延遲問題，我們還是先來回顧下網絡延遲的概念，這會有助于你對後面内容的了解。網絡延遲又稱為 RTT（Round Trip Time）。我們把從浏覽器發送一個資料包到伺服器，再從伺服器傳回資料包到浏覽器的整個往返時間稱為 RTT（如下圖）。RTT 是反映網絡性能的一個重要名額。
那建立 TCP 連接配接時，需要花費多少個 RTT 呢？下面我們來計算下。
我們知道 HTTP/1 和 HTTP/2 都是使用 TCP 協定來傳輸的，而如果使用 HTTPS 的話，還需要使用 TLS 協定進行安全傳輸，而使用 TLS 也需要一個握手過程，這樣就需要有兩個握手延遲過程。
- 在建立 TCP 連接配接的時候，需要和伺服器進行三次握手來确認連接配接成功，也就是說需要在消耗完 1.5 個 RTT 之後才能進行資料傳輸。
- 進行 TLS 連接配接，TLS 有兩個版本——TLS1.2 和 TLS1.3，每個版本建立連接配接所花的時間不同，大緻是需要 1～2 個 RTT，關于 HTTPS 我們到後面到安全子產品再做詳細介紹
總之，在傳輸資料之前，我們需要花掉 3～4 個 RTT。如果浏覽器和伺服器的實體距離較近，那麼 1 個 RTT 的時間可能在 10 毫秒以内，也就是說總共要消耗掉 30～40 毫秒。這個時間也許使用者還可以接受，但如果伺服器相隔較遠，那麼 1 個 RTT 就可能需要 100 毫秒以上了，這種情況下整個握手過程需要 300～400 毫秒，這時使用者就能明顯地感受到“慢”了。
TCP 協定僵化
現在我們知道了 TCP 協定存在隊頭阻塞和建立連接配接延遲等缺點，那我們是不是可以通過改進 TCP 協定來解決這些問題呢？
答案是：非常困難。之是以這樣，主要有兩個原因。
第一個是中間裝置的僵化。要搞清楚什麼是中間裝置僵化，我們先要弄明白什麼是中間裝置。我們知道網際網路是由多個網絡互聯的網狀結構，為了能夠保障網際網路的正常工作，我們需要在網際網路的各處搭建各種裝置，這些裝置就被稱為中間裝置。
這些中間裝置有很多種類型，并且每種裝置都有自己的目的，這些裝置包括了路由器、防火牆、NAT、交換機等。它們通常依賴一些很少更新的軟體，這些軟體使用了大量的 TCP 特性，這些功能被設定之後就很少更新了。
是以，如果我們在用戶端更新了 TCP 協定，但是當新協定的資料包經過這些中間裝置時，它們可能不了解包的内容，于是這些資料就會被丢棄掉。這就是中間裝置僵化，它是阻礙 TCP 更新的一大障礙。
除了中間裝置僵化外，作業系統也是導緻 TCP 協定僵化的另外一個原因。因為 TCP 協定都是通過作業系統核心來實作的，應用程式隻能使用不能修改。通常作業系統的更新都滞後于軟體的更新，是以要想自由地更新核心中的 TCP 協定也是非常困難的
QUIC 協定
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 應用到實際環境中依然面臨着諸多嚴峻的挑戰，這些挑戰主要來自于以下三個方面。
第一，從目前的情況來看，伺服器和浏覽器端都沒有對 HTTP/3 提供比較完整的支援。Chrome 雖然在數年前就開始支援 Google 版本的 QUIC，但是這個版本的 QUIC 和官方的 QUIC 存在着非常大的差異。
第二，部署 HTTP/3 也存在着非常大的問題。因為系統核心對 UDP 的優化遠遠沒有達到 TCP 的優化程度，這也是阻礙 QUIC 的一個重要原因。
第三，中間裝置僵化的問題。這些裝置對 UDP 的優化程度遠遠低于 TCP，據統計使用 QUIC 協定時，大約有 3%～7% 的丢包率。
總結
好了，今天就介紹到這裡，下面我來總結下本文的主要内容。
我們首先分析了 HTTP/2 中所存在的一些問題，主要包括了 TCP 的隊頭阻塞、建立 TCP 連接配接的延時、TCP 協定僵化等問題。
這些問題都是 TCP 的内部問題，是以要解決這些問題就要優化 TCP 或者“另起爐竈”創造新的協定。由于優化 TCP 協定存在着諸多挑戰，是以官方選擇了建立新的 QUIC 協定。
HTTP/3 正是基于 QUIC 協定的，你可以把 QUIC 看成是內建了“TCP+HTTP/2 的多路複用 +TLS 等功能”的一套協定。這是集衆家所長的一個協定，從協定最底層對 Web 的檔案傳輸做了比較徹底的優化，是以等生态相對成熟時，可以用來打造比現在的 HTTP/2 還更加高效的網絡。
- 從标準制定到實踐再到協定優化還需要走很長一段路；
- 因為動了底層協定，是以 HTTP/3 的增長會比較緩慢，這和 HTTP/2 有着本質的差別