The most informative tutorial about HTTP2 configuration on Nginx
Created#More Posted time:Nov 3, 2016 17:24 PM
Nearly one year has passed since May 14, 2015 when the official version of HTTP/2 protocol was released. More and more websites have deployed HTTP2. The extensive application of HTTP2 enables a better browsing experience. Modern browsers all support it, so HTTP2 deployment won't be too much trouble.
Although h2c (HTTP/2 Cleartext) is available in HTTP/2 (h2) to enable transmission through unencrypted channels, few browsers are supporting this feature in the early stage. Presently, encrypted channels are still required for HTTP/2 deployment. However, because of the vigorous promotion of free and low-cost licenses by Let's Encrypt, HTTP/2 deployment does not require a high cost.
HTTP 2.0, that is, Hypertext Transfer Protocol 2.0, is the next generation of HTTP. It is developed by the Hypertext Transfer Protocol Bis (httpbis) team of IETF (Internet Engineering Task Force), and is the first update since the release of HTTP 1.1 in 1999.
HTTP/2 evolves from SPDY which has accomplished its mission and will soon withdraw from the historical arena (for example, Chrome ended its support for SPDY in early 2016; Nginx and Apache also support HTTP/2 in an all-round way and no longer support SPDY).
We usually abbreviate HTTP2 to h2, though some friends may be reluctant to agree. However, this abbreviation has been widely accepted, as proved by its extensive usage in browsers.
The access to general HTTPS websites is a little slower than to HTTP websites, because the former needs to process encryption tasks. But if h2 is configured, the access will be faster and more stable than HTTP websites in low latency.
Internet traffic hijacking occurs frequently these days. After the website is configured with HTTPS encryption, most hijackings (not all of them) can be eradicated. For the e-commerce industry or similar industries, HTTPS encryption is a standard configuration. From this perspective, deployment of h2 is imperative.
The nginx compiled by default does not contain the h2 module. We need to add parameters to compile it. **As of press time**, Nginx 1.9 developer version and above requires developers to add the compilation parameters on their own in the source code. The code downloaded from the software source repository requires developers to add the parameters for compilation by default. Tengine supports simultaneous deployment of h2 and SPDY to ensure compatibility, while nginx just simply slashes off the support for SPDY.
If h2 module is not supported in your compiled nginx, in ./configure, you can add: --with-http_v2_module. If SSL support is absent, you also need to add --with-http_ssl_module.
Then execute the make && make install command to complete the installation and compilation.
This mainly refers to the configuration of server blocks.
Modify the .conf file of the relevant VM (usually in /usr/local/nginx/conf/vhost/ or /etc/nginx/conf/). You can refer to the instructions on your environment, or post a question after this article. I will try to look into it.
listen 443 ssl http2 default_server;
Note: In server_name www.mf8.biz;, replace www.mf8.biz with your domain name.
Run the /usr/local/nginx/sbin/nginx -t or nginx -t commands to check whether the configuration is correct. Then restart nginx to complete the configuration.
You can check for h2 support in Chrome browsers using the HTTP/2 and SPDY indicator. If the blue lightning is shown in the address bar, it means h2 is supported.
Or you can check in chrome://net-internals/#http2. Note: The version should be the latest version to ensure it looks best.
We all know that the Heartbleed loophole last year has pushed SSL to the teeth of the storm. So we should make some security optimizations to SSL even if h2 support is enabled.
Configure Diffie–Hellman key
openssl dhparam -out dhparam.pem 2048 // Run the command in SSH mode. Here openssl is used to generate the 2048-bit key, instead of being written to the nginx.conf file as a parameter.
ssl_dhparam /path/to/dhparam.pem; //Configured in .conf file.
Disable unsafe SSL protocols and use a safe protocol
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Disable unsafe encryption algorithms
Ease BEAST attacks
This move skips 301 navigation and reduces the risk of attacks by intermediaries. You can configure it in the .conf file.
`add_header Strict-Transport-Security max-age=15768000;`
Jump from Port 80 to Port 443
add_header Strict-Transport-Security max-age=15768000;
return 301 https://www.yourwebsite.com$request_uri;
Cache session credential
resolver 184.108.40.206 220.127.116.11 valid=300s;