Why Chrome does not support HTTP/2 websites.

Why Chrome does not support HTTP/2 websites.
GuideWhen I occasionally cleared the Chrome plug-in last night, I found that my "HTTP/2 and SPDY indicator" plug-in was not on for a long time. This plug-in will light up when you access a website that supports HTTP/2 (or the previous SPDY protocol), and I clearly remember that it was designed to support HTTP/2 at https://linux.cn.

Is there a problem with this plug-in my first response? Open the Chrome debugging tool and find that the request and response are both HTTP/1.1!

After some research, it was originally from Chrome 51. before December 31, May 31, 2016, HTTP/2 websites that support the authorization protocol; and then only support ALPN protocol HTTP/2 site-and currently ALPN protocol is only a few releases support openssl-1.0.2 support.

What happened?Server

We know that the original Web access protocol was HTTP/1, including the previous HTTP/1.0 and the HTTP/1.1 currently adopted by most websites (HTTP/0.9 is an experimental protocol and has been abandoned ). However, as Web applications become increasingly complex, the previous HTTP/1.x protocol seems unable to meet the increasingly complex Web service requirements. For example, plaintext requests and request reuse. Therefore, Google developed a new transport layer protocol named SPDY. Since all the people who used this new agreement agreed, Google submitted the agreement to IETF. Then everyone thought that SPDY was not a good name (SPDY is a registered trademark of Google ), just call HTTP/2!

The SPDY protocol is based on SSL/TLS. Google developed an SSL/TLS extension called the next-generation protocol negotiation (PNP), which is used to determine whether to use the HTTP/2 protocol when the client connects to the server. The SPDY protocol is implemented and supported by Web servers, while the Protocol is implemented by SSL such as OpenSSL.

However, as SPDY was submitted to IETF and then changed to HTTP/2, Google also gave up SPDY development and made full efforts to invest in HTTP/2 Development, previously, the application-layer protocol negotiation, ALPN, was also replaced by a new negotiation protocol. The NNS and ALPN are incompatible. Their main differences are:

• On the client side, you can select the protocol list supported by server sending. ALPN is the list sent by the client and selected by the server.
• In, the final selection result is sent to the server after the Change Cipher Spec, that is, it is encrypted. In ALPN, all negotiation is in plain text.

The main benefit of doing so is security considerations, but this creates a problem that the openssl-1.0.2 has been widely supported by OpenSSL, while ALPN is currently only supported by the latest. The OpenSSL versions of several mainstream Linux distributions and the supported negotiation protocols are as follows:

Linux releaseOpenSSL versionSupported negotiation protocolsCentOS/Oracle Linux/RHEL 5.10 + 0.9.8e does not support CentOS/Oracle Linux/RHEL 6.5 +, 7.0 + 1.0.1eNPNUbuntu 12.04 LTS1.0.1NPNUbuntu 14.04 lts1.0.1fgbeUbuntu 16.04 LTS1.0.2gALPN andDebian 7.01.0.1eNPNDebian 8.01.0.1kNPN

From the above we can see that basically all server-level Linux distributions do not support OpenSSL and ALPN, And the only supported Ubuntu 16.04 LTS is obviously not much used. Do not underestimate the differences in version 0.0.1. For other software, the differences in version 0.0.1 can basically be ignored, but for OpenSSL, they are two versions of intergenerational. OpenSSL is a fairly underlying library and many important software depends on it. Therefore, the attitude of each release version when upgrading OpenSSL is quite conservative, for example, we can see which software in the CentOS system uses OpenSSL:

$ lsof | grep libssl | awk '{print $1}' | sort | uniqanvilfail2bangdbusgmainhttpdpostfixmysqldNetworkManagernginxphp-fpmpuppetsshdsudotunedzabbix_agent

Without adequate testing, the Linux release version will not be upgraded in a product-level (server-level) environment. To solve security problems in earlier versions (1.0.1), they would rather port the security fixes in the new version (1.0.2) back to the old version, nor upgrade it to the new version (1.0.2) with new features ), this is why you have seen various versions 1.0.1e and 1.0.1k.

Of course, you can compile a new OpenSSL to replace the openssl-1.0.1 in your system, but I don't think you will do that, right?

By the way, the two can coexist, but the client will give priority to ALPN.

Browser (Chrome)

Since Chrome 51, Google has removed support for SPDY, but this is not a problem, because not only does SPDY have fewer Web servers, in addition, upgrading from SPDY to HTTP/2 is also very simple. In this regard, the configuration of Nginx, Apache and other servers is very simple.

However, unfortunately, Google also removed the support for the on Chrome 51! If your Web server uses versions below the openssl-1.0.2 and does not support ALPN negotiation, Chrome 51 and later will access your website over HTTP/1.

Google gave a brief explanation of the rejection of the support, but in any case, the Protocol will not come back again After Chrome 51. On the other hand, OpenSSL will not continue to release a new version of the openssl-1.0.1 series after December 31, 2016, so far as the security fix.

In this case, the new features provided by HTTP/2, such as connection multiplexing, That you originally supported HTTP/2, have achieved a good access experience in Chrome, but now it has fallen back to the old state.

What should we do?

There are several methods:

Change Browser

If the mountains don't come, I will go to the mountains. Chrome 51 + does not support HTTP/2 websites with a remote code. As a browser, you can use other browsers, such as Safari and Edge. In this way, you can use the new protocol to access the world's 10% Web servers supporting HTTP/2.

However, as a server operator, you cannot ignore more than 50% of Chrome users.

Change Server

As shown above, Ubuntu 16.04 LTS is currently the only official support for openssl-1.0.2 Linux release, if you have been using Ubuntu as a server, consider upgrading it. The LTS version is supported for up to five years.

Of course, in the product environment, even if you are a Ubuntu server, updating the version is also a major issue. Please be careful.

Recompile

Since changing the server is not a good choice, you still have a solution, that is, re-compile your Web server with the new openssl-1.0.2 source code, such as nginx.

Next I will briefly introduce how to compile nginx with openssl-1.0.2. (The latest version of the 1.0.2 series is 1.0.2j. Of course, if you do not use 1.1.0, I have nothing to say ......)

First download and unzip the openssl-1.0.2j:

# wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz# tar -zxvf openssl-1.0.2j.tar.gz

Then use the -- with-openssl = ../openssl option and your other options when compiling nginx:

./configure --with-openssl=../openssl --with-http_v2_module --with-http_ssl_module

After configuring and compiling, you can use nginx-V to check your OpenSSL version in nginx.

The advantage of this self-compilation is high flexibility, but you need to pay attention to whether each component has serious security vulnerabilities at any time, and re-compile after fixing the version.

Container

In addition to self-compilation, if your system environment already has container support, you can also run an Ubuntu 16.04 LTS In the container and run the Web server in it.

Summary

The above is the story between HTTP/2 and Chrome. Are you going to upgrade HTTP/2 to support it? You must know that you will not want to return to HTTP/1 any more than HTTP/2.

From: https://linux.cn/article-7934-1.html

Address: http://www.linuxprobe.com/chrome-http2.html