HTTP/2 行为与 HTTP 和 HTTPS

Question

这https://en.wikipedia.org/wiki/HTTP/2#Encryption说

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).[25]

但是在 Google 上测试我得到了不同的结果:

curl --http2 -I http://www.google.co.uk
HTTP/1.1 200 OK

curl --http2 -I https://www.google.co.uk
HTTP/2 200 

其他领域也是如此。有什么解释吗？

Answer 1

HTTP/2 可以通过未加密的 channel (称为 h2c)协商，但它更复杂，因为客户端如何知道服务器是否理解相对较新的 HTTP/2 协议(protocol)？此外，代理服务器在未加密发送时通常无法处理像这样的新协议(protocol)，但在加密发送时可以很好地处理它们(因为在这种情况下他们看不到它使用新协议(protocol))。

对于加密连接，在发送第一个 HTTP 请求之前，HTTP/2(加密时称为 h2)作为 HTTPS 协商的一部分使用 ALPN 扩展(或它已替换的旧 NPN 扩展)进行协商。

对于没有 HTTPS 协商的未加密连接，有两种选择:

1. 假设服务器使用 HTTP/2 并立即开始使用 HTTP/2。这有点自以为是，但理论上如果你在失败时回退到 HTTP/1 是可行的。在许多方面，它类似于关于将 HTTPS 设置为默认设置并回退到 HTTP 的讨论 - 它需要足够多的人才能让这一切变得有值(value)。

2. 将初始请求作为 HTTP/1 请求发送，并带有 upgrade: h2c HTTP header (以及作为另一个 HTTP header 的 base 64 HTTP/2 设置框架)。这会询问服务器我们是否可以为下一个请求切换到 HTTP/2。服务器应该发送带有类似升级 header 的 HTTP/1 响应，此时下一个请求可以作为 HTTP/2 请求发送。 HTTP/2 spec in section 3.2 中详细介绍了此过程.

Curl 目前仅支持第二种方法，详见此处:https://curl.haxx.se/docs/http2.html所以不会马上说 HTTP/2。如果您在详细模式下运行 curl -v，那么您应该会看到升级 header 。

但是none of the mainstream web browsers support HTTP/2 over unencrypted channels (h2c) 使 h2 成为事实上的标准 - 至少对于旨在供网络浏览器使用的面向公众的服务器而言。因此，许多 Web 服务器同样选择不去实现 h2c，因为它很少被使用。见 this page to see how few implementations support h2c . Google 的服务器通常由 GFE(Google 前端)提供支持，您可以从该列表中看到它只支持 h2 而不是 h2c。