發送時，文件（html、js、css、圖像等）被分解成更小的、單獨的數據包，數據隨著時間的推移而傳輸。
http/1.1 旨在為每個文件提供自己的連接。隨著網站變得越來越複雜，需要更多的文件來加載每個頁面。
瀏覽器限制了可用的並行連接數量，從而造成瓶頸並減慢加載時間。這導致了一些必要的變通方法來最大化性能，例如域分片和圖像精靈。
通過引入多路復用，http/2 解決了由連接限制引起的問題，允許通過單個連接傳輸多個文件。
另一個主要改進是引入了更好的標頭壓縮，以及一些在實踐中證明不太成功的其他功能。
然而，這些改進並沒有解決 tcp 協議的所有問題。
tcp按時間順序傳輸數據包，這意味著如果丟失了數據包，則整個連接將保持不變，直到成功接收到數據包。這個問題，被稱為線頭阻塞，否定了多路復用的一些好處。
tcp 的另一個挑戰是它完全脫離了 tls 協議。這是設計使然，因為網站可能既安全又不安全。
因此，伺服器和客戶端在傳輸數據之前必須進行多次往返來協商連接。
http/3 如何解決這些問題。
通過從 tcp 遷移到 udp，http/3 引入了三個使其與 http/1.1 和 http/2 不同的主要特性。
獨立位元組流
http/3 通過為單個文件引入獨立的位元組流來解決行頭阻塞問題。在重新發送丟失的數據包時，僅阻止單個流的數據，而不是整個連接。
為了進一步說明這一點，值得回想一下tom anthony在他關於 http/2（現已更新為http/3）的開創性演示中使用的奇妙的卡車類比。
基本前提是，使用 http/1.1，最終會有多輛卡車在同一條道路上排隊（連接）。
相比之下，http/2 允許多輛卡車同時在同一車道上。
不幸的是，使用 tcp 時，如果卡車熄火，整條道路都會被阻塞，直到卡車再次開始行駛。
使用 http/3 和 udp，其他卡車可以繞過它。
tls 集成
通過將 tls 1.3 併入 http/3 本身，而不是讓兩個不同的協議獨立運行，只需一次握手即可將往返次數從兩次（或如果使用 tls 1.2，則為三次）減少到一次。
這一變化意味著更快、更安全的用戶連接。
此更改的一個後果是 http/3 只能在安全站點上使用，因為 tls 和 udp 緊密交織在一起。有趣的是，http/2 並非如此，從技術上講，它可以在不安全的站點上使用——儘管沒有一個主要的瀏覽器允許您這樣做。
連接遷移
http/3 不是使用 ip 來路由數據包，而是使用連接 id
通過這樣做，它可以處理網絡更改而無需重新建立連接。
這在移動優先的世界中非常有利，用戶經常在 wifi 和蜂窩網絡之間切換，無論是在速度還是連接穩定性方面。
回到我們的卡車類比，這就像來到一個路口，必須再次排隊才能繼續前進到下一條道路。
使用 http/3，有一條支路，允許您在兩者之間無縫交換。