Activate HTTP/2 on web servers

Son of SPDY

Apache Manual Labor

The Apache web server has run HTTP/2 since version 2.4.17, which means you have to compile the web server yourself on most Linux distributions if you want to use HTTP/2. Apache requires a whole series of config options to function normally and use the directory layout you are likely familiar with from your distribution. On Red Hat or CentOS, you can take a look at the source RPM from Apache and copy the config option used there. Even better, you can modify the SPEC file for the new Apache version and build an RPM yourself. Admittedly, it is not especially easy to find out which patches you have to delete and which you have to keep to build the package successfully.

To activate HTTP/2, the source code must be configured with the --enable-http2 option, which requires the libnghttp2 library included with CentOS 7. Otherwise, manual installation is initiated. The server also requires the OpenSSL library – at least in version 1.0.2 – for ALPN support, although the older version 1.0.1 is installed in many Linux distros. A complete update is therefore difficult because many applications then have to be relinked to the current OpenSSL version. However, installing a current OpenSSL version in parallel with the old (e.g., in /usr/local) does not pose any problems.

If you have compiled the Apache web server successfully, you must activate the protocol in the server configuration to use HTTP/2:

Protocols h2 http/1.1

The HTTP/2 module must be loaded for this to function. In the same file, the log level of the module can then be set:

LoadModule http2_module modules/mod_http2.so
<IfModule http2_module>
        LogLevel http2:info
</IfModule>

Apache can take advantage of server push if the feature is activated with the H2Push directive. The web server then inspects the link header of a response and spontaneously sends the resources listed there to the client. The H2PushPriority instruction [6] improves performance by setting the order and priority in which pushed responses are sent out.

H2O, the Newcomer

Another interesting candidate to use for testing HTTP/2 sites is H2O [7], a relatively new web server from Japan released under the MIT License. H2O is faster than Nginx in benchmarks and provides a whole range of other much-needed features along with HTTP/2, such as forward secrecy for TLS, support for the proxy protocol, and TLS session resumption, a technique that halves the time needed to make TLS connections and reduces computing time by up to 10%.

H20 does not have as many features as Nginx and Apache, but the most important components for running a professional website have been implemented, such as FastCGI interface support for programming languages. H2O also has a built-in Ruby interface to supply script support for processing requests.

H2O has to be compiled from the source code, but that can be done fairly simply, because the package already contains most of the dependencies. Only the CMake build tool and the libuv library (version 1.0.0 or greater) are needed. If you want to use WebSockets, you have to install libwslay , which is rarely contained in distributions. If the TAR archive has been downloaded and extracted, the following command chain installs the program:

$ cmake -DWITH_BUNDLED_SSL=on .
$ make
$ sudo make install

Although the developers consider LibreSSL to be the better SSL library, because it is deemed safer and provides newer crypto-algorithms, they recommend the somewhat faster OpenSSL for benchmarks. The program can be compiled with the included library (-DWITH_BUNDLED_SSL) or with an SSL library already installed system wide. To start the server, enter:

$ /usr/local/bin/h2o -c h2o.conf

For HTTP/2, the developers have developed a technique called CASPer (cache-aware server push), to ensure the efficient interaction of browser cache and HTTP/2 server push. It makes little sense for the server to transfer files that the browser already has saved in its cache; to prevent this, CASPer, with the use of checksums and cookies, keeps a record of files that have already been transferred. More advanced features in H2O include a proxy function for WebSockets and smart caching of file descriptors.

Conclusion

HTTP/2 is in more widespread use than you would think, as you can see if you pay attention to the HTTP/2 indicator on your browser as you surf. For instance, large sites like Google and Twitter naturally make use of HTTP/2. Web hosts like CloudFlare and content delivery networks like Akamai also are already offering HTTP/2 to their customers.

Few sources of error crop up after updating to HTTP/2. When activated, websites function as expected. If you are lucky, your performance will benefit from lower overhead. If your website depends on every ounce of performance, you should perform comprehensive tests, because common tweaks to HTTP/1 could backfire with HTTP/2. In the future, web server improvements such as server push are expected, as the newcomer H2O demonstrates.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=