HTTP3

如果一个序列号较低的数据段还没有接收到，即使其他序列号较高的段已经接收到，TCP的接收机滑动窗口也不会继续处理。这将导致TCP流瞬间挂起，在更糟糕的情况下，即使所有的段中有一个没有收到，也会导致关闭连接。这个问题被称为TCP流的行头阻塞（HoL）

虽然TCP确实允许在应用层之间建立多个逻辑连接，但它不允许在一个TCP流中复用数据包。使用HTTP/2时，浏览器只能与服务器打开一个TCP连接，并使用同一个连接来请求多个对象，如CSS、JavaScript等文件。在接收这些对象的同时，TCP会将所有对象序列化在同一个流中。因此，它不知道TCP段的对象级分区。

QUIC引入了连接上的多路流复用的概念。QUIC通过设计实现了单独的、针对每个流的流控，解决了整个连接的行头阻塞问题。

TCP的拥塞控制机制是刚性的。该协议每次检测到拥塞时，都会将拥塞窗口大小减少一半。相比之下，QUIC的拥塞控制设计得更加灵活，可以更有效地利用可用的网络带宽，从而获得更好的吞吐量。

UIC使用增强的丢失恢复机制和转发纠错功能，以更好地处理错误数据包。该功能对于那些只能通过缓慢的无线网络访问互联网的用户来说是一个福音，因为这些网络用户在传输过程中经常出现高错误率。

QUIC使用相同的TLS模块进行安全连接。然而，与TCP不同的是，QUIC的握手机制经过优化，避免了每次两个已知的对等者之间建立通信时的冗余协议交换。

HTTP/3还使用了一种新的HTTP头压缩机制，称为QPACK，是对HTTP/2中使用的HPACK的增强。在QPACK下，HTTP头可以在不同的QUIC流中不按顺序到达。与HTTP/2中的TCP确保数据包的按顺序传递不同，QUIC流是不按顺序传递的，在不同的流中可能包含不同的HTTP头。因此，QPACK使用查找表机制对报头进行编码和解码。

HTTP可能不是物联网的首选协议，但在某些情况下，基于HTTP的通信非常适合特定的应用。HTTP/3可以解决从传感器收集数据的移动电话的无线连接损耗问题。这个问题同样适用于安装在车辆或可移动资产上的独立IoT设备。通过HTTP来访问这些设备，可以更加可靠。

全球各地的企业都在觉醒，意识到从多个部门收集数据的潜力，并将其整合成更大的信息共享API，供内部和外部受众共享。这些API也为数据的货币化铺平了道路，通过托管这些数据作为流API服务可以实现数据的货币化。随着时间的推移，这些服务会吐出海量的数据。通过HTTP/3托管的流API将使它们比HTTP/2更健壮、更有弹性。

随着浏览器能力的提升，内容格局正在快速变化。其中一个领域就是基于网络的VR。虽然还处于起步阶段，但有很多的用例可以让VR在加强协作方面发挥关键作用。网络在促进VR互动方面占据了核心位置。VR应用需要更多的带宽来渲染虚拟场景中的复杂细节，因此迁移到HTTP/3会大有收获。

HTTP/3被广泛采用的另一个问题是，它是基于QUIC的，在UDP上运行。大多数的Web流量，以及IETF定义的知名服务都是在TCP之上运行的。这也是为什么长时间运行HTTP/3的UDP会话会被防火墙的默认数据包过滤策略所影响的原因。

过渡到HTTP/3不仅涉及到应用层的变化，还涉及到底层传输层的变化。因此，与它的前身HTTP/2相比，HTTP/3的采用更具挑战性，因为后者只需要改变应用层。传输层承受着网络中的大量中间层审查。这些中间层，如防火墙、代理、NAT设备等会进行大量的深度数据包检查，以满足其功能需求。因此，新的传输机制的引入对IT基础设施和运维团队来说有一些影响。

HTTP/3由于过于繁琐从而无法采用。许多IoT应用部署的设备的外形尺寸非常小。因此，它们的RAM和CPU功率都是有限的。为了使设备在电池功率、低比特率和有损连接等限制条件下高效运行，必须执行此要求。HTTP/3在现有的UDP之上，以QUIC的形式在传输层处理，增加了HTTP/3在整个协议栈中的占用空间。这使得HTTP/3较为笨重，不适合那些IoT设备。但这种情况很少出现，而且存在专门的协议，这就避免了直接在此类设备上支持HTTP的需要。此外，还有以物联网为核心的协议，如MQTT。