其次QUIC 价格昂贵因为它单独加密每个数据包

adnanhridoy2844

这比使用 TCP 上的 TLS 慢，因为您可以分块加密数据包（一次最多大约 16 KB 或 11 个数据包），这更环保。这是 QUIC 中的有意权衡，因为批量加密可以实现其自己的 HoL 封锁形式。

与主要因素不同，我们可以上传额 手机号数据库列表 外的 API 来使 UDP（以及 QUIC ）更快，但这里 QUIC 总是比 TCP+TLS 具有固有的危险。然而，这在实践中也是相当容易管理的，例如，得益于优化的加密库和允许对 QUIC 数据包标头进行批量加密的巧妙方法。

因此，虽然 Google 最早版本的 QUIC 仍然比 TCP+TLS 慢两个版本，但事情实际上已经取得了进展。例如，在当前的测试中，微软经过深度优化的 QUIC 堆栈能够获得 785 Gbps 的速度，而同一台机器上 TCP+TLS 的速度为 1185 Gbps（所以在这里，QUIC 的准备速度比 TCP 快 66%） +TLS）。

当前的 Windows 更新使 UDP 更快（为了进行完整的评估，该系统上的 UDP 吞吐量变为 195 Gbps）。 Google QUIC 堆栈的优化模型目前比 TCP+TLS 慢约 20%。在一台不太先进的机器上通过 Fastly 进行的早期测试甚至声称具有相同的整体性能（大约 450 Mbps），并带有一些提示，这表明 QUIC 可以根据用例真正与 TCP 竞争。

然而，尽管 QUIC 的速度是 TCP+TLS 的两倍，但它已经不再那么可怕了。首先，QUIC 和 TCP+TLS 处理通常不再是服务器上发生的最重的元素，因为需要执行其他好的判断（例如缓存、代理等）。因此，您实际上不需要两倍的服务器来运行 QUIC（但是，考虑到没有主要雇主发布这方面的统计数据，现在还不清楚它将对真实数据设施产生多大影响）。

其次，QUIC 未来的实施还有很多优化的可能性。例如，随着时间的推移，一些 QUIC 实现将（部分）传递到正在运行的小工具内核（很像 TCP ）或跳过它（一些已经执行过，包括 MsQuic 和 Quant ）。我们还可以期待 QUIC 专用硬件的推出。

尽管如此，在某些用例中也可能需要 TCP+TLS。例如，Netflix 表示，它可能不会每次都很快切换到 QUIC，因为它已经投入了大量资金来定制其 FreeBSD 设置，以通过 TCP+TLS 传输视频。

同样，Facebook 表示，QUIC 在大多数情况下可以在终端用户和 CDN 之间使用，而不是在事实设备之间或方面节点和起始服务器之间使用，因为这样会带来更好的开销。众所周知，带宽非常大的情况可能会继续需要 TCP+TLS，特别是在未来几年。