发送时，文件（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，有一条支路，允许您在两者之间无缝交换。