HTTP/2 Support

Description

Varnish Enterprise supports HTTP/2 for client connections. HTTP/2 is turned off by default and is controlled by the http2 feature flag. Once enabled, Varnish will accept HTTP/2 in three ways:

Over TLS, negotiated with ALPN. When TLS is terminated in Varnish and the http2 feature is enabled, Varnish advertises h2 during the TLS handshake, and clients that support it will use HTTP/2. No extra configuration is needed beyond enabling the feature.
Cleartext upgrade (h2c), where a client sends an HTTP/1.1 request with an Upgrade: h2c header and Varnish switches the connection to HTTP/2.
Cleartext with prior knowledge, where a client that already knows the server speaks HTTP/2 opens the connection with the HTTP/2 preface directly.

Note: Hitch is no longer required for HTTP/2. Earlier versions relied on Hitch to terminate TLS and negotiate h2 via ALPN. Varnish Enterprise now terminates TLS in-process (see Client SSL/TLS), and HTTP/2 is negotiated by Varnish itself.

Enabling HTTP/2

Enable the http2 feature by passing -p feature=+http2 on the varnishd command line.

Update the systemd unit file’s ExecStart= line as described in the unit file configuration tutorial:

[Service]
ExecStart=/usr/sbin/varnishd -a :443,https -p feature=+http2 ...

If Varnish is already running, HTTP/2 can be toggled at runtime over the CLI. This does not survive a restart, so make the change permanent in the unit file as well:

$ varnishadm param.set feature +http2

To confirm the feature is active:

$ varnishadm param.show feature

For HTTPS, configure TLS termination in Varnish as described in Client SSL/TLS. With TLS in place and the http2 feature enabled, ALPN negotiation of h2 happens automatically.

Tuning HTTP/2

The following parameters control HTTP/2 behavior. They can be set on the command line with -p or at runtime with varnishadm param.set. Use varnishadm param.show <name> to inspect the current value and full description.

Protocol SETTINGS

These parameters map to the values Varnish sends in the initial SETTINGS frame when a new HTTP/2 session is established.

Parameter	Default	Description
`h2_header_table_size`	`4k`	Size of the HPACK dynamic decoding table (`SETTINGS_HEADER_TABLE_SIZE`).
`h2_max_concurrent_streams`	`100`	Maximum number of requests active at the same time on a single connection (`SETTINGS_MAX_CONCURRENT_STREAMS`).
`h2_initial_window_size`	`65535b`	Initial flow-control window size (`SETTINGS_INITIAL_WINDOW_SIZE`).
`h2_max_frame_size`	`16k`	Largest per-frame payload Varnish will accept (`SETTINGS_MAX_FRAME_SIZE`).
`h2_max_header_list_size`	`0b`	Maximum size of an uncompressed header list. Exceeding it closes the connection immediately. `0` is interpreted as 150% of `http_req_size`. The value advertised to clients as `SETTINGS_MAX_HEADER_LIST_SIZE` comes from `http_req_size`, not this parameter.

Flow control

These affect flow control for incoming request bodies (POST, PUT, etc.).

Parameter	Default	Description
`h2_rx_window_low_water`	`10M`	Receive window low-water mark. Varnish tries to keep the window at least this large.
`h2_rx_window_increment`	`1M`	Size of the credits sent in `WINDOW_UPDATE` frames.
`h2_window_timeout`	`5s`	How long a stream may wait for the client to credit the window before giving up.

Rapid Reset protection

These mitigate the HTTP/2 Rapid Reset attack (CVE-2023-44487) by rate-limiting streams that are reset shortly after being opened.

Parameter	Default	Description
`h2_rapid_reset`	`1.0s`	Threshold for how soon a `RST_STREAM` must follow a `HEADERS` frame for the stream to be treated as suspect.
`h2_rapid_reset_limit`	`100`	Maximum number of suspect stream resets allowed within `h2_rapid_reset_period` before the connection is closed. `0` disables the limit.
`h2_rapid_reset_period`	`60s`	Sliding-window duration over which `h2_rapid_reset_limit` is counted.

Buffering

Parameter	Default	Description
`h2_rxbuf_storage`	`Transient`	Storage backend that HTTP/2 receive buffers are allocated from. Requires a restart to change.