quic - HTTP/3 及其影响

Question

最近 Chrome、Firefox、cURL 等宣布支持 HTTP/3（之前称为 HTTP-over-QUIC）。

您如何从以下变化的角度看待其适应影响：

1. 应用程序（基于网络的、移动的、基于纯套接字的等）

2. 托管基础设施（网络/应用服务器、防火墙、负载平衡器、CDN、路由器、交换机等）和 ISP 等。

3. 安全性（新威胁、漏洞、VAPT 工具的前景等）

4. 拥塞控制

Answer 1

一个非常主观的问题，所以不确定是否适合这里，但这是我的两分钱：

1. 不应该对 HTTP/2 所做的事情产生任何进一步的影响。它关闭了其中的一个边缘情况（丢失的数据包会使 HTTP/2 在 HTTP/2 上比 HTTP/1.1 慢）并且还可能为初始连接设置带来一些性能改进。如果您尚未迁移到 HTTP/2 或针对 HTTP/2 进行优化，那么可能希望在准备时考虑这一点。优先事项也将在 HTTP/3 中重新考虑，但尚未决定如何进行。归根结底，这是传输层的变化，HTTP/2 的基本语义没有改变，因此对于更高级别的应用程序，它应该是相当无缝的——就像 HTTP/2 主要针对 HTTP/1.1 用户一样。

2. 它基于 UDP（回退到基于 TCP 的 HTTP/2 和/或 HTTP/1.1），启用和设置会很有趣！TLS 库也需要更改以支持它，因此可能需要一段时间才能在某些服务器中看到它。CDN 已经处于领先地位，并且将是实现这一目标的最简单方法。像 HTTP/2 一样，将它放在边缘服务器上可能是最重要的，然后降级到 HTTP/2 甚至 HTTP/1.1 以用于超出此范围的内部流量。它也更加完全加密，这将使得难以嗅探和重新路由流量，因为中间框可以读取的信息少于 TCP。

3. 请参阅上面的答案 2，这将使嗅探流量变得更加困难。此外，它还很新（在撰写本文时甚至还没有完全完成和批准），因此可能存在像 HTTP/2 那样的实现错误（例如），并且某些产品最初不支持它。从好的方面来说，它只能通过 HTTPS 使用，这对安全性有好处。