服务器中不支持 ALPN 的 HTTP/2 h2

Question

阅读完 HTTP/2 RFC (#7540)和 TLS-ALPN RFC (#7301)后，我仍然无法弄清楚当一端缺少 ALPN 时的预期行为。

假设我有一个使用 HTTP/2“h2”（通过 TLS）的客户端，该客户端与支持 HTTP/2 的服务器通信，但不在“服务器问候”中发送 ALPN 扩展。客户的预期行为是什么？

到目前为止，我见过的大多数客户端都认为服务器不支持 HTTP/2，并将连接降级到 http/1.1，但很少有人忽略（go-gRPC）继续使用 HTTP/2。

如果使用在客户端（“h2”）和服务器（“h2c”）之间执行 SSL 终止的 AWS classic LB，则此场景可能会更加实用。在此示例中，客户端发送值为“h2”的 ALPN 扩展，LB 在没有 ALPN 的情况下执行 SSL 握手（正如其部分所预期的那样），最终 JAVA gRPC 由于 HTTP/1.1 降级而失败。

Answer 1

这完全取决于客户端和服务器。许多仍然支持 SPDY 和 HTTP/2 支持的旧 NPN TLS 扩展，尽管规范官方表示仅使用 ALPN。

\n\n

例如，在浏览器方面，Chrome、Firefox 和 Opera 现在仅支持基于 ALPN 的 HTTP/2，尽管它们过去都支持基于 NPN 的 HTTP/2。在撰写本文时，Safari、IE 和 Edge 仍然允许使用 NPN 或 ALPN。

\n\n

在服务器端，有些（例如Nginx）支持两者，而有些（例如Apache）仅支持ALPN。

\n\n

我还会质疑 \xe2\x80\x9cdowngrade\xe2\x80\x9d 的术语。ALPN 扩展是使用 h2 的请求，在发送单个 HTTP 消息之前作为 TLS 协商的一部分发生。因此，它\xe2\x80\x99 并不是真正的降级，而是一个不成功的升级请求。

\n