【发布时间】：2019-10-02 11:51:58
【问题描述】：
最近 Chrome、Firefox、cURL 等宣布支持 HTTP/3（之前称为 HTTP-over-QUIC）。
您如何从以下变化的角度看待其适应影响：
-
应用程序（基于网络的、移动的、基于纯套接字的等）
-
托管基础设施（网络/应用服务器、防火墙、负载平衡器、CDN、路由器、交换机等）和 ISP 等。
-
安全性（新威胁、漏洞、VAPT 工具格局等）
-
拥塞控制
【问题讨论】：
【发布时间】：2019-10-02 11:51:58
【问题描述】：
一个非常主观的问题，所以不确定是否适合这里，但这是我的两分钱：
-
不应该对 HTTP/2 所做的事情产生任何进一步的影响。它关闭了其中的一个边缘情况（丢失的数据包会使 HTTP/2 在 HTTP/2 上比 HTTP/1.1 慢）并且还可能为初始连接设置带来一些性能改进。如果您还没有迁移到 HTTP/2 或针对 HTTP/2 进行优化，那么可能希望在准备时考虑一下。优先事项也将在 HTTP/3 中重新考虑，但尚未决定如何。归根结底，这是传输层的变化，HTTP/2 的基本语义没有改变，因此对于更高级别的应用程序，它应该是相当无缝的 - 就像 HTTP/2 主要用于 HTTP/1.1 用户一样。
它基于 UDP（回退到基于 TCP 的 HTTP/2 和/或 HTTP/1.1），启用和设置会很有趣！还有TLS libraries need to change to support it，所以我们可能需要一段时间才能在某些服务器上看到它。 CDN 已经处于领先地位，并且将是实现这一目标的最简单方法。像 HTTP/2 一样，将它放在边缘服务器上可能是最重要的，然后降级到 HTTP/2 甚至 HTTP/1.1 以用于内部流量。它也更加完全加密，这将使得难以嗅探和重新路由流量，因为与 TCP 相比，中间框可读取的信息更少。
请参阅上面的答案 2，这将使嗅探流量变得更加困难。此外，它非常新（在撰写本文时甚至还没有完全完成和批准），因此可能存在 HTTP/2 (for example) 的实现错误，并且某些产品不支持它最初。从好的方面来说，它只能通过 HTTPS 使用，这有利于安全性。
【讨论】：