說明
浏覽器工作原理與實踐專欄學習筆記
HTTP/3 出現的背景
1999 年設計的 HTTP/1.1 已經不能滿足需求，是以 Google 在 2009 年設計了基于 TCP 的 SPDY，後來 SPDY 的開發組推動 SPDY 成為正式标準，不過最終沒能通過。不過 SPDY 的開發組全程參與了 HTTP/2 的制定過程，參考了 SPDY 的很多設計，是以我們一般認為 SPDY 就是 HTTP/2 的前身。無論 SPDY 還是 HTTP/2，都是基于 TCP 的，TCP 與 UDP 相比效率上存在天然的劣勢，是以 2013 年 Google 開發了基于 UDP 的名為 QUIC 的傳輸層協定，QUIC 全稱 Quick UDP Internet Connections，希望它能替代 TCP，使得網頁傳輸更加高效。後經提議，網際網路工程任務組正式将基于 QUIC 協定的 HTTP （HTTP over QUIC）重命名為 HTTP/3。
在 HTTP/1.1 時代，為了提升并行下載下傳效率，浏覽器為每個域名維護了 6 個 TCP 連接配接；
而采用 HTTP/2 之後，浏覽器隻需要為每個域名維護 1 個 TCP 持久連接配接，同時還解決了 HTTP/1.1 隊頭阻塞的問題。
那麼 HTTP/2 到底有什麼缺陷？
TCP 的隊頭阻塞
雖然 HTTP/2 解決了應用層面的隊頭阻塞問題，不過和 HTTP/1.1 一樣，HTTP/2 依然是基于 TCP 協定的，而 TCP 最初就是為了單連接配接而設計的。
正常情況下的 TCP 傳輸資料過程
從一端發送給另外一端的資料會被拆分為一個個按照順序排列的資料包，這些資料包通過網絡傳輸到了接收端，接收端再按照順序将這些資料包組合成原始資料，這樣就完成了資料傳輸。
TCP 丢包狀态
如果有一個資料因為網絡故障或者其他原因而丢包了，那麼整個 TCP 的連接配接就會處于暫停狀态，需要等待丢失的資料包被重新傳輸過來。
在 TCP 傳輸過程中，由于單個資料包的丢失而造成的阻塞稱為 TCP 上的隊頭阻塞。
HTTP/2 多路複用 vs HTTP/1.1
HTTP/2 中，多個請求是跑在一個 TCP 管道中的，如果其中任意一路資料流中出現了丢包的情況，那麼就會阻塞該 TCP 連接配接中的所有請求。使用 HTTP/1.1 時，浏覽器為每個域名開啟了 6 個 TCP 連接配接，如果其中的 1 個 TCP 連接配接發生了隊頭阻塞，那麼其他的 5 個連接配接依然可以繼續傳輸資料。
随着丢包率的增加，HTTP/2 的傳輸效率也會越來越差。有測試資料表明，當系統達到了 2% 的丢包率時，HTTP/1.1 的傳輸效率反而比 HTTP/2 表現得更好。
TCP 建立連接配接的延時
網絡延遲又稱為 RTT（Round Trip Time）：是反映網絡性能的一個重要名額。
從浏覽器發送一個資料包到伺服器，再從伺服器傳回資料包到浏覽器的整個往返時間稱為 RTT。
建立 TCP 連接配接時，需要花費多少個 RTT 呢？
在傳輸資料之前，需要花掉 3～4 個 RTT。
浏覽器和伺服器的實體距離較近，那麼 1 個 RTT 的時間可能在 10 毫秒以内，總共要消耗掉 30～40 毫秒。
- 在建立 TCP 連接配接的時候，需要和伺服器進行三次握手來确認連接配接成功，需要在消耗完 1.5 個 RTT 之後才能進行資料傳輸。
- 如果使用 HTTPS 進行 TLS 連接配接，（TLS 有兩個版本——TLS1.2 和 TLS1.3）每個版本建立連接配接所花的時間不同，大緻是需要 1～2 個 RTT
TCP 協定僵化
能否通過改進 TCP 協定來解決TCP 協定存在隊頭阻塞和建立連接配接延遲等缺點？
非常困難。
原因有兩個：
1. 中間裝置的僵化
中間裝置：比如路由器、防火牆、NAT、交換機等。
中間裝置僵化：如果用戶端更新了 TCP 協定，但是當新協定的資料包經過這些中間裝置時，它們可能不了解包的内容，于是這些資料就會被丢棄掉。這就是中間裝置僵化，它是阻礙 TCP 更新的一大障礙。
2. 作業系統
TCP 協定都是通過作業系統核心來實作的，應用程式隻能使用不能修改。通常作業系統的更新都滞後于軟體的更新，是以要想自由地更新核心中的 TCP 協定也是非常困難的。
QUIC 協定
HTTP/3 基于 UDP 實作了類似于 TCP 的多路資料流、傳輸可靠性等功能，這套功能稱為 QUIC 協定。
HTTP/2 和 HTTP/3 協定棧
HTTP/3 中的 QUIC 協定實作的功能：
- 實作了類似 TCP 的流量控制、傳輸可靠性的功能
- 內建了 TLS 加密功能
- 實作了 HTTP/2 中的多路複用功能
- 實作了快速握手功能：QUIC 是基于 UDP， 可以實作使用 0-RTT 或者 1-RTT 來建立連接配接
QUIC 協定的多路複用
和 TCP 不同，QUIC 實作了在同一實體連接配接上可以有多個獨立的邏輯資料流（如下圖）。
HTTP/3 的挑戰
1. 從目前的情況來看，伺服器和浏覽器端都沒有對 HTTP/3 提供比較完整的支援。
2.部署 HTTP/3 也存在着非常大的問題。
因為系統核心對 UDP 的優化遠遠沒有達到 TCP 的優化程度，這也是阻礙 QUIC 的一個重要原因。
3.中間裝置僵化的問題。