使用 HTTP/2 甚至 HTTP/3 进行反向代理和后端之间的连接有哪些优点和缺点？
我还没有真正遇到过这种情况，只见过 H2 和 H2 部署在反向代理和 CDN 前面。ASFIK H2 和 H3 通常（H2C 是一种东西，对吧？）需要 TLS，如果你想在后端之外进行 TLS 终止，这将使它不适合。
H2 的设置和配置也可能比基本的 HTTP/1.1 后端更困难。从好的方面来看，与反向代理为 HTTP/1.1 后端连接打开的 n 个 TCP 连接相比，多路复用难道不是对固定数量的并发请求的改进吗？
在 CPU、内存和 IO 负载方面，节省和成本有哪些？
有人有这方面的真实经验吗？
答案1
我写关于这个话题的答案在 Stack Overflow 上它仍然非常相关。
HTTP/2（和 HTTP/3）的好处主要在于前端。您不太可能在后端看到任何真正的、明显的好处。而且，鉴于这些较新的协议通常缺乏支持，我不会因为收益如此之少而麻痹自己去启用它。
一个有趣的点（正如我在链接答案底部所指出的）是将前端的 HTTP/2（或 3）降级为后端的 HTTP/1.1 时可能出现的安全问题。这些主要是由于 HTTP/1.1 中的问题（2 和 3 旨在解决这些问题）以及这些边缘情况的错误实现造成的，但是，如果可能的话，这确实给出了一个很好的理由来避免使用 HTTP/1.1。
目前 HTTP/3 肯定是有成本的，我不建议在后端使用它（或者老实说，你管理的前端也不建议使用它——在我看来，通过 CDN 使用才是最佳方式）。它仍然太新了（最终的 RFC 甚至还没有发布！），我们花了数年时间在操作系统和整个网络堆栈中优化 TCP。QUIC 位于用户空间而不是内核中，这一事实对未来有很多优势，但速度和效率并不是其中之一。差距正在缩小（因为来自 Fastly 的这份报告显示）但它仍然存在。
因此，一旦 HTTP/2 变得无处不在（这比大多数人想象的要快！），我就会使用它，但我不会为后端而感到压力（这是值得在前端付出额外努力的事情）。HTTP/3 落后 5 年，而且刚刚完成，因此目前更不推荐在后端使用它。但我真的相信 QUIC 和 HTTP/3 在未来会令人兴奋，所以绝对值得关注。