HTTP/3
/ aitch-tee-tee-pee THREE /
HTTP/2 讓單一條連線承載許多交錯的串流，卻留下一個頑固的瑕疵：它仍搭在 TCP 上，而 TCP 嚴格依序交付所有位元組。一旦丟失一個封包，TCP 就會凍結共用該連線的每一條串流，直到遺失的封包被重送——連跟這次遺失毫不相干的串流也照凍。HTTP/3 的對策是徹底拋棄 TCP。它改跑在 QUIC 之上，那是一個較新的傳輸，坐落在 UDP 之上，並針對每條串流重新實作可靠性與排序。
做法是這樣。QUIC 跑在 UDP 上（UDP 不可靠、不排序），但自己把可靠性、壅塞控制與排序加回來，而且是放在應用程式自己的軟體裡，而非作業系統核心。關鍵在於，QUIC 分別追蹤每一條 HTTP 串流：丟失的封包只會卡住它所承載資料的那一條串流，其餘每條串流照樣流動。QUIC 還把加密一併納入（TLS 交握被內建進 QUIC，因此沒有獨立的 TLS 往返），而且能在更少的往返內完成建立，有時讓資料在第一個封包上就開始流動。一句話：HTTP/3 就是跑在 QUIC 上的 HTTP。
為什麼要大費周章？因為殘留的瓶頸是傳輸層的行頭阻塞，而要除掉它的唯一辦法，就是別再使用單一條依序的 TCP 位元組串流。其取捨是誠實的：QUIC 較複雜、住在使用者空間（所以由 App 更新它，而非作業系統），而且比成熟的 TCP 耗更多 CPU；又因為它以 UDP 為基礎，某些只預期 TCP 的舊防火牆與中間盒可能會干擾它。但對於易丟封包的行動與 Wi-Fi 網路——正是封包遺失常見之處——各串流獨立交付是一項真實、可量測的勝利，這就是為什麼主要瀏覽器與大型站台採用了 HTTP/3。
在一個訊號不穩的手機連線上，你載入一個有許多串流的頁面。某個承載部分影像的 UDP 封包遺失了。在 HTTP/2-over-TCP 下，每條串流都凍結，直到那個封包被重送。在 HTTP/3-over-QUIC 下，只有那一張影像卡住；文字與其他影像照常渲染，因為 QUIC 把每條串流獨立交付。
藉由改用跑在 UDP 上的 QUIC，HTTP/3 讓一個遺失的封包只卡住它自己的串流，而非全部。
HTTP/3 並不會神奇地把網路變快，也打不過光速——傳播延遲毫無改變。它的勝利在於避開傳輸層的行頭阻塞、並削減交握往返，這在易丟封包或高延遲的連結上最為重要。