【发布时间】：2016-07-28 00:48:21
【问题描述】：
HTTP/2 如何影响代理服务器的实现？特别是，例如，当客户端向仅支持 HTTP/1.x 的内容服务器发送 HTTP/2 请求时，代理服务器是否应该在将客户端请求定向到之前将 HTTP/2 请求转换为 HTTP/1.x 请求内容服务器？并且在收到来自内容服务器的响应后，代理服务器是否应该将响应转换为 HTTP/2 格式，然后再将其发送回客户端？
【问题讨论】：
标签： reverse-proxy http2
【发布时间】：2016-07-28 00:48:21
【问题描述】：
正如设计所讨论的，您的理解是正确的。
但是我认为值得指出的是，在您的边缘连接（即您的反向代理）上，HTTP/2 仍然具有巨大的优势，因为 HTTP/2 解决的问题（主要是延迟）比通常较短的问题要小，通常是从反向代理到内容服务器的高带宽跳跃。
例如，如果您在边缘的反向代理有 100 毫秒的延迟，而反向代理和内容服务器之间只有 1 毫秒的延迟，那么内容服务器向代理服务器发送 HTTP/1.1 的事实可能不会由于超快的 1ms 延迟，对性能有很大影响。因此，终端客户端（对反向代理使用 HTTP/2）仍然可以看到 HTTP/1.1 的巨大性能。
【讨论】：
-
反向代理是否必须记住 h2 连接中的所有 cookie，以便当它为下游应用程序将请求转换为 http1 时，它可以发送整个 cookie 负载？
-
您的意思是因为 HTTP/2 下的标头压缩吗？如果是这样，这应该会发生——尽管这会自动成为运行 HTTP/2 服务器的一部分。 HTTP/2 连接打开（在这种情况下，服务器需要管理标头压缩并能够解压缩）或连接未打开，原始请求将需要在第一个请求中发送所有 cookie 并构建提高标头压缩值。
是的，正如你所说。从 HTTP/2 到 HTTP/1.1 的转换必须发生在一个方向上，而从 HTTP/1.1 到 HTTP/2 的转换必须发生在另一个方向上。
实际上，这意味着虽然 HTTP/2 协议不需要传统的基于文本的解析器，但全面的 HTTP/2 服务器需要 HTTP/1.1 解析器，而不仅仅是与仅支持 HTTP/1.1 的客户端一起工作（其中包括爬虫），也用于与内部应用程序对话。
通过使用，最重要的应用程序协议之一是 FastCGI。 FastCGI 还需要解析来自应用程序的 HTTP/1.1 响应并将其转换为给客户端的 HTTP/2 响应。
【讨论】：
-
如果是这种情况，我可以这样理解吗：代理服务器比以前更有帮助，因为它还支持 HTTP/2 客户端和内容服务器之间的通信，只有支持 HTTP/1.1 而无需将内容服务器升级到 HTTP/2？
-
当然。我建造了这样一只野兽，ShimmerCat。
-
有人可以修复答案中的链接