您的位置: 首页  >  技术问答  >  HTTP和HTTPS的HTTP/2行为

HTTP和HTTPS的HTTP/2行为

分类: 技术问答 • 2022-05-05 15:17:51
问题描述：

此 https://en.wikipedia.org/wiki/HTTP/2#加密说

为HTTP URI(即未加密)和HTTPS URI(通过TLS(需要TLS 1.2或更高版本))均定义了HTTP/2.[25]

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上进行的测试却得到了不同的结果:

but testing on Google I get different results:

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

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

其他域也是如此.有什么解释吗?

The same goes for other domains. Any explanation?

答

HTTP/2可以通过未加密的通道(称为h2c)进行协商，但是更为复杂，因为客户端如何知道服务器是否会理解相对较新的HTTP /2协议?另外，代理服务器在未加密发送时通常会遇到处理此类新协议的问题，但在加密发送时会很好地处理它们(因为在这种情况下，它们无法使用新协议查看其协议).

HTTP/2 can be negotiated over unencrypted channels (known as h2c) but it's more complicated as how does the client know whether the server will understand the relatively new HTTP/2 protocol? Additionally proxy servers often have problems handling new protocols like this when sent unencrypted but handle them fine when sent encrypted (because they cannot see its using a new protocol in this case).

对于加密的连接，在发送第一个HTTP请求之前，使用ALPN扩展(或其替换的较旧的NPN扩展)将HTTP/2(加密后称为h2)作为HTTPS协商的一部分.

For encrypted connections, HTTP/2 (known as h2 when encrypted) is negotiated as part of HTTPS negotiation using the ALPN extension (or the older NPN extension it has replaced) before the first HTTP request is sent.

对于未加密的连接，如果没有HTTPS协商，则有两个选项:

For unencrypted connections, where there is no HTTPS negotiation, there are two options:

  1. 假定服务器使用HTTP/2，并且立即开始使用HTTP/2.这有点推测，但理论上讲，如果失败则退回到HTTP/1，则可以使用.在许多方面，这与使HTTPS成为默认值并回退到HTTP的讨论类似-它需要大量的资源才能使之有价值.

  1. Assume the server speaks HTTP/2 and just start talking HTTP/2 immediately. This is a bit presumptious but in theory would work if you fell back to HTTP/1 if that failed. In many ways it's similar to the discussion on making HTTPS default and falling back to HTTP - it needs critical mass to make this worthwhile.

发送初始请求作为HTTP/1请求，并带有upgrade: h2c HTTP标头(并将基本的64 HTTP/2设置帧作为另一个HTTP标头).这询问服务器是否可以为下一个请求切换到HTTP/2.服务器应该发送带有类似升级头的HTTP/1响应，此时下一个请求可以作为HTTP/2请求发送.此过程在 HTTP/2规范的第3.2节中进行了详细说明.

Send the initial request as a HTTP/1 request and with an upgrade: h2c HTTP Header (and a base 64 HTTP/2 settings frame as another HTTP header). This asks the server if we can switch to HTTP/2 for the next request. The server should send the HTTP/1 response with a similar upgrade header at which point the next request can be sent as a HTTP/2 request. This process is detailed in the HTTP/2 spec in section 3.2.

Curl当前仅支持第二种方法，详情如下: https://curl.haxx. se/docs/http2.html ，所以不会马上讲HTTP/2.如果您在详细模式下运行curl -v，则应该看到升级标题.

Curl currently only supports the second method as detailed here: https://curl.haxx.se/docs/http2.html so will not speak HTTP/2 straight away. If you run curl -v for verbose mode then you should see the upgrade headers.

但是没有一个主流的网络浏览器通过未加密的通道支持HTTP/2 (h2c) h2实际上的标准-至少适用于打算供Web浏览器使用的面向公众的服务器.因此，许多Web服务器类似地选择不打扰实现h2c，因为它很少使用.请参阅此页面，以了解有多少实现支持h2c . Google的服务器通常由GFE(Google前端)提供支持，您可以从该列表中看到它们仅支持h2，而不支持h2c.

However none of the mainstream web browsers support HTTP/2 over unencrypted channels (h2c) making h2 the de facto standard - at least for public facing servers intended for use by web browsers. Therefore a lot of web servers have similarly chosen not to bother implementing h2c as it will be so little used. See this page to see how few implementations support h2c. Google's servers are usually powered by GFE (Google Front End) which you can see from that list only supports h2 and not h2c.

相关推荐