How it works
HTTP/2 Dimensioning
This module provides HTTP/2 (RFC 7540) support for the Apache HTTP Server. This module relies on libnghttp2 to provide the core http/2 engine. You must enable HTTP/2 via Protocols in order to use the functionality described in this document. New features with Apache 2.3/2.4; New features with Apache 2.1/2.2; New features with Apache 2.0; Upgrading to 2.4 from 2.2; Apache License; Reference Manual. Compiling and Installing; Starting; Stopping or Restarting; Run-time Configuration Directives; Modules.
Enabling HTTP/2 on your Apache Server has impact on the resource consumption and if you have a busy site, you may need to consider carefully the implications.
The first noticeable thing after enabling HTTP/2 is that your server processes will start additional threads. The reason for this is that HTTP/2 gives all requests that it receives to its own Worker threads for processing, collects the results and streams them out to the client.
In the current implementation, these workers use a separate thread pool from the MPM workers that you might be familiar with. This is just how things are right now and not intended to be like this forever. (It might be forever for the 2.4.x release line, though.) So, HTTP/2 workers, or shorter H2Workers, will not show up in mod_status. They are also not counted against directives such as ThreadsPerChild. However they take ThreadsPerChild as default if you have not configured something else via H2MinWorkers and H2MaxWorkers.
Another thing to watch out for is is memory consumption. Since HTTP/2 keeps more state on the server to manage all the open request, priorities for and dependencies between them, it will always need more memory than HTTP/1.1 processing. There are three directives which steer the memory footprint of a HTTP/2 connection: H2MaxSessionStreams, H2WindowSize and H2StreamMaxMemSize.
H2MaxSessionStreams limits the number of parallel requests that a client can make on a HTTP/2 connection. It depends on your site how many you should allow. The default is 100 which is plenty and unless you run into memory problems, I would keep it this way. Most requests that browsers send are GETs without a body, so they use up only a little bit of memory until the actual processing starts.
H2WindowSize controls how much the client is allowed to send as body of a request, before it waits for the server to encourage more. Or, the other way around, it is the amount of request body data the server needs to be able to buffer. This is per request.
And last, but not least, H2StreamMaxMemSize controls how much response data shall be buffered. The request sits in a H2Worker thread and is producing data, the HTTP/2 connection tries to send this to the client. If the client does not read fast enough, the connection will buffer this amount of data and then suspend the H2Worker.
Multiple Hosts and Misdirected Requests
Many sites use the same TLS certificate for multiple virtual hosts. The certificate either has a wildcard name, such as '*.example.org' or carries several alternate names. Browsers using HTTP/2 will recognize that and reuse an already opened connection for such hosts.
While this is great for performance, it comes at a price: such vhosts need more care in their configuration. The problem is that you will have multiple requests for multiple hosts on the same TLS connection. And that makes renegotiation impossible, in face the HTTP/2 standard forbids it.
So, if you have several virtual hosts using the same certificate and want to use HTTP/2 for them, you need to make sure that all vhosts have exactly the same SSL configuration. You need the same protocol, ciphers and settings for client verification.
If you mix things, Apache httpd will detect it and return a special response code, 421 Misdirected Request, to the client.
Environment Variables
This module can be configured to provide HTTP/2 related information as additional environment variables to the SSI and CGI namespace, as well as in custom log configurations (see %{VAR_NAME}e).
| Variable Name: | Value Type: | Description: |
|---|---|---|
HTTP2 | flag | HTTP/2 is being used. |
H2PUSH | flag | HTTP/2 Server Push is enabled for this connection and also supported by the client. |
H2_PUSH | flag | alternate name for H2PUSH |
H2_PUSHED | string | empty or PUSHED for a request being pushed by the server. |
H2_PUSHED_ON | number | HTTP/2 stream number that triggered the push of this request. |
H2_STREAM_ID | number | HTTP/2 stream number of this request. |
H2_STREAM_TAG | string | HTTP/2 process unique stream identifier, consisting of connection id and stream id separated by -. |
Apache 2.4 Disable Http2
I recently added support for the HTTP/2 protocol on this server and I am really pleased with the additional performance gains. This VPS was already running a functional LAMP stack, so the following steps describe the necessary configuration changes for my setup which relies on Apache with PHP-FPM.
This guide is more extensive than necessary. The USE flags will obviously pull in the needed dependencies so strictly speaking, there is really no need to split the process down to installing individual packages. The threads USE flag can also be set globally instead of per package.
Additional packages
To build Apache with HTTP/2 support we need to add the HTTP/2 C library. Install the nghttp2 package and its dependencies with the command:
PHP-FPM
Before rebuilding Apache with HTTP/2 support, I’ll add the threads USE flag to PHP. Add the threads USE flag to your existing list of PHP flags by editing /etc/portage/package.use/php:
The additional PHP USE flags I’ve selected are needed for my WordPress installation but your taste may differ.
Apache
To use HTTP/2, it’s necessary to switch from the default prefork implementation to the Apache event or worker MPM. The Gentoo Wiki provides additional details here.
With nghttp2 installed, let’s switch to the Apache event MPM and add http2 to the list of Apache modules we want to build. Edit /etc/portage/make.conf:
The proxy and proxy_fcgi Apache modules are needed for running Apache with PHP-FPM. Make sure PHP_TARGETS reflects your installed PHP version(s) if needed. I also recommend having apache2 and php defined as global USE flags.
Apache 2.4 Mod_proxy_http2
We also need to enable the Apache threads USE flag by adding the following directive to /etc/portage/package.use/apache:
Rebuild and configure the system
Finally, the system has to be updated to reflect the necessary changes. Run the following emerge command to rebuild packages with new USE flags:
For a fresh install, emerging PHP will also pull in Apache provided that apache2 Reset premiere pro layout. is defined as a global USE flag.
Enable the http2_module
The last step required is to edit /etc/conf.d/apache2 and to add the HTTP2 variable to your APACHE2_OPTS section.
Adding -D HTTP2 will toggle the following section to true and load the module:
You’ll find the configuration file for HTTP/2 located under /etc/apache2/modules.d/41_mod_http2.conf. It enables the HTTP/2 protocol for all SSL enabled sites.
Restart Apache and verify that everything is working as intended.
ModSecurity
Older implementations of ModSecurity might block HTTP/2 requests due to an unknown protocol versions. Let’s add a “fix” to the core rule set by modifying the section specifying allowed http versions. Modify /etc/apache2/modules.d/80_modsecurity-crs.conf and append HTTP/2.0 to the allowed http version list:
Restart Apache, and we should be good.