虽然在概念上 QUIC 的 HoL 封锁消除方式

adnanhridoy2844

应该在有损网络上表现更好，但实际上它取决于很多因素。由于网页加载的用例通常倾向于更顺序的复用设置，并且考虑到数据包丢失是不可预测的，因此这种选择通常可能会影响最慢的 1% 的客户。然而，这仍然是一个完全活跃的研究场所，只有时间才能证明一切。

尽管如此，在某些情况下仍然可以有更大的增强。其中大多 手机号数据库列表 数都超出了首次完整网页加载的典型用例，eG 虽然源似乎不会阻塞，但在可以增量处理它们之后，同时流是完全公正的，或者同时发送的信息较少。

示例包括重复访问缓存良好的页面以及单一页面应用程序中的后台下载和 API 调用。例如，Facebook 在使用 /三在其本地应用程序中加载信息时，在消除 HoL 封锁方面有一些明显的好处。

UDP 和 TLS 整体性能
QUIC 和 /third 的第五个整体性能问题是它们在网络上开发和发送数据包时的性能和整体性能。我们将看到 QUIC 使用 UDP 和重度加密，使其比 TCP 慢一些（但情况正在改善）。

首先，我们已经讨论过 QUIC 对 UDP 的使用更多的是灵活性和可部署性，而不是整体性能。事实进一步证明了这一点，直到现在，通过 UDP 发送 QUIC 数据包通常比发送 TCP 数据包慢得多。这部分是因为这些协议通常适用的地点和方式（参见下面的图九）。

TCP 和 QUIC 之间的实现差异
图 9：TCP 和 QUIC 之间的实现差异。 （海量预览）
如上所述，TCP和UDP通常在操作设备的快速内核中同时应用。在评估中，TLS 和 QUIC 实现主要在较慢的用户空间中（请注意，这并不是 QUIC 真正想要的 - 它通常会这样做，因为它更灵活）。这使得 QUIC 已经比 TCP 慢得多。

此外，在从用户空间软件（由浏览器和 Web 服务器组成）发送记录时，我们需要将此记录绕过到正在运行的机器内核，然后内核使用 TCP 或 UDP 通过网络真正发送它。传递此信息是使用内核 API（系统调用）完成的，其中包含与 API 调用同步的大量开销。对于 TCP，这些开销比 UDP 少很多。

这尤其是因为从历史上看，TCP 的使用量比 UDP 多得多。因此，随着时间的推移，TCP 实现和内核 API 中添加了许多优化，以减少数据包发送和接收开销。许多网络接口控制器 (NIC) 甚至具有内置 TCP 硬件卸载。然而，UDP 就没那么幸运了，因为它的使用受到更大的限制，并且不再证明在额外优化方面的投资是合理的。幸运的是，这种情况在过去 5 年里发生了变化，最大工作结构增加了针对 UDP 的优化选项。