How to Configure Windows Server 2022 for Containers

HTTP/2 Overview and Benefits

HTTP/2, standardized in RFC 7540 (2015), is a major revision of the HTTP protocol designed to address the head-of-line blocking and overhead problems inherent in HTTP/1.1. Its key features — multiplexing, header compression (HPACK), server push, and binary framing — dramatically improve page load performance, particularly for resource-heavy applications that previously required techniques like domain sharding, CSS sprites, and inlining assets to work around HTTP/1.1’s one-request-per-connection constraint.

On Windows Server 2022, IIS 10 ships with HTTP/2 support enabled by default. There is no additional module to install. However, there are several prerequisites and configuration decisions that determine whether clients actually negotiate HTTP/2, and understanding them is essential for maximizing the performance benefits.

HTTP/2 Requirements in IIS 10

For HTTP/2 to be negotiated between a client and IIS on Windows Server 2022, all of the following conditions must be met:

1. TLS 1.2 or higher must be used. HTTP/2 is only supported over HTTPS in all major browsers. The TLS handshake uses ALPN (Application-Layer Protocol Negotiation) to agree on HTTP/2 before the first HTTP byte is sent. Plain-text HTTP/2 (h2c) is technically defined in the spec but not supported by IIS or any mainstream browser.

2. Windows Server 2016 or later. HTTP/2 support in IIS was introduced in Server 2016 / IIS 10. Windows Server 2012 R2 (IIS 8.5) does not support HTTP/2 regardless of the TLS configuration.

3. The cipher suite must support HTTP/2. HTTP/2 requires a cipher suite that supports forward secrecy (ECDHE or DHE key exchange). Specifically, HTTP/2 blacklists cipher suites from the TLS_NULL, TLS_RSA, RC4, DES, and 3DES families. Ensure your IIS TLS configuration uses modern ECDHE-based cipher suites.

4. The client must support HTTP/2. All modern browsers (Chrome 41+, Firefox 36+, Edge 12+, Safari 9+) support HTTP/2. HTTP clients like cURL support HTTP/2 with the --http2 flag when compiled with nghttp2.

Verifying HTTP/2 is Enabled in IIS

HTTP/2 is enabled globally by default in IIS 10. Verify the protocol settings:

# Check the HTTP/2 protocol setting at the site level
Get-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" `
  -filter "system.applicationHost/sites/site[@name='Default Web Site']/limits" `
  -name "*"

# Check server-level HTTP/2 settings
Get-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" `
  -filter "system.applicationHost/protocols/add[@name='http']" `
  -name "*"

HTTP/2 can be explicitly disabled at the site level, which is sometimes done for compatibility with older proxies or load balancers that don’t understand HTTP/2 framing:

# Disable HTTP/2 for a specific site (rarely needed)
Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" `
  -filter "system.applicationHost/sites/site[@name='MySite']" `
  -name "protocols" -value "http"  # Excludes "http2"

# Re-enable HTTP/2 for a site
Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST" `
  -filter "system.applicationHost/sites/site[@name='MySite']" `
  -name "protocols" -value "http,http2"

You can also disable HTTP/2 system-wide via registry if needed for troubleshooting:

# Disable HTTP/2 globally (requires IIS restart)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesHTTPParameters" `
  -Name "EnableHttp2Tls" -Value 0 -PropertyType DWORD -Force

# Re-enable
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesHTTPParameters" `
  -Name "EnableHttp2Tls" -Value 1

iisreset /restart

Testing HTTP/2 with curl

The fastest way to confirm a server is serving HTTP/2 is with cURL. Windows Server 2022 ships with cURL 7.x which supports HTTP/2:

# Test HTTP/2 - should show "HTTP/2 200" in the response
curl -I --http2 https://www.yourdomain.com

# Verbose output showing ALPN negotiation
curl -v --http2 https://www.yourdomain.com 2>&1 | Select-String -Pattern "ALPN|HTTP/"

# Force HTTP/1.1 for comparison
curl -I --http1.1 https://www.yourdomain.com

A successful HTTP/2 response looks like:

* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Mon, 17 May 2026 10:00:00 GMT
server: Microsoft-IIS/10.0

If you see HTTP/1.1 200 instead of HTTP/2 200, HTTP/2 negotiation failed. This most commonly means TLS is not configured, the TLS cipher suite is incompatible with HTTP/2, or the site’s protocols setting excludes http2.

Testing HTTP/2 in Browser Developer Tools

In Chrome or Edge, open Developer Tools (F12), go to the Network tab, right-click the column headers, and enable the Protocol column. Each request will show h2 for HTTP/2 or http/1.1 for HTTP/1.1. You can also type chrome://net-internals/#http2 in Chrome’s address bar to see active HTTP/2 sessions and stream details.

In Firefox, the Network tab shows the protocol column by default. Requests served over HTTP/2 display HTTP/2 in the Protocol column.

Troubleshooting HTTP/2 Fallback to HTTP/1.1

When HTTP/2 negotiation fails, IIS falls back transparently to HTTP/1.1. This is by design — ALPN allows the client and server to agree on the best mutually supported protocol. However, if you expect HTTP/2 and are seeing HTTP/1.1, diagnose systematically:

# Check TLS version and cipher suite negotiated
# Run this on the server to test its own TLS configuration
$tcpClient = [System.Net.Sockets.TcpClient]::new("localhost", 443)
$sslStream = [System.Net.Security.SslStream]::new($tcpClient.GetStream())
$sslStream.AuthenticateAsClient("localhost")
Write-Host "Protocol: $($sslStream.SslProtocol)"
Write-Host "Cipher: $($sslStream.CipherAlgorithm)"
$sslStream.Close(); $tcpClient.Close()

Common causes of HTTP/2 fallback:

1. HTTPS not configured on the site - IIS only uses HTTP/2 over TLS
2. Old cipher suites enabled - HTTP/2 blacklists RC4, DES, 3DES, static RSA key exchange
3. TLS 1.0/1.1 only cipher suites - should use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 etc.
4. Intermediate proxy or load balancer strips HTTP/2 headers
5. Windows HTTP.sys not updated (check Windows Update)
6. IIS protocols setting for the site excludes "http2"

To check which cipher suites are enabled on the server:

Get-TlsCipherSuite | Format-Table Name, Exchange, Cipher, Hash -AutoSize

Ensure at least one ECDHE-based AES-GCM suite is enabled and prioritized. Disable any RC4 or 3DES suites that may be lingering from older OS configurations.

HPACK Header Compression

HTTP/2 uses HPACK (RFC 7541) for header compression. Unlike HTTP/1.1 where headers are sent as plain text with every request, HTTP/2 maintains a dynamic table of previously sent headers on both the client and server. Subsequent requests only send header changes (deltas), dramatically reducing header overhead for applications with many requests per session.

For example, repeated headers like Host, Accept-Encoding, Cookie, Authorization, and User-Agent are sent in full only on the first request. Subsequent requests reference the header by its table index — often a single byte. This can reduce request header size by 85-90% in typical browser sessions. IIS handles HPACK automatically; no administrator configuration is required.

Multiplexing Benefits and Connection Limits

HTTP/2 multiplexing allows multiple requests and responses to be interleaved on a single TCP connection simultaneously. Under HTTP/1.1, browsers open 6-8 parallel TCP connections per origin to work around the one-outstanding-request-per-connection limit. With HTTP/2, a single connection handles all streams concurrently, reducing connection overhead, eliminating head-of-line blocking at the HTTP layer, and improving performance particularly on high-latency connections.

IIS limits the number of concurrent HTTP/2 streams per connection. The default is 100 streams. This can be adjusted via registry if needed for high-volume environments:

# Adjust max concurrent HTTP/2 streams per connection (default: 100)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesHTTPParameters" `
  -Name "Http2MaxConcurrentClientStreams" -Value 200 -PropertyType DWORD -Force

# Adjust HTTP/2 header table size (default: 4096 bytes)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesHTTPParameters" `
  -Name "Http2HeaderTableSize" -Value 8192 -PropertyType DWORD -Force

iisreset /restart

Server Push in IIS

HTTP/2 Server Push allows the server to proactively send resources to the client before the client requests them. For example, when a browser requests an HTML page, the server can push the associated CSS and JavaScript files over the same connection before the browser has even parsed the HTML. This eliminates one round-trip for critical resources.

In IIS, server push is triggered by adding a Link header with the rel=preload attribute and a push policy to the HTTP response:

IIS reads the Link header with rel=preload and converts it into HTTP/2 PUSH_PROMISE frames automatically. The client receives the pushed resources and caches them; when the HTML is parsed and references those resources, the browser loads them from the local push cache instead of making new requests. Note: server push has been deprecated in some scenarios and HTTP/103 Early Hints is emerging as a more reliable alternative.

HTTP/3 and QUIC on Windows Server 2022

HTTP/3 (RFC 9114) replaces TCP with QUIC (RFC 9000), a UDP-based transport protocol that provides built-in TLS 1.3, faster connection establishment, and per-stream flow control that eliminates transport-level head-of-line blocking. Windows Server 2022 includes native QUIC support through MsQuic, and HTTP/3 support in IIS was introduced as an experimental feature in later Windows Server 2022 updates.

To check if HTTP/3 / QUIC support is available and enable it:

# Check Windows version (HTTP/3 experimental support in Server 2022 with recent updates)
[System.Environment]::OSVersion.Version

# Enable HTTP/3 experimental support (requires Windows Server 2022 21H2 or later build)
New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesHTTPParameters" `
  -Name "EnableHttp3" -Value 1 -PropertyType DWORD -Force

iisreset /restart

When HTTP/3 is available, IIS advertises support via the Alt-Svc response header, instructing clients to upgrade on subsequent connections:

Alt-Svc: h3=":443"; ma=2592000

Add this header manually via web.config until full HTTP/3 IIS integration is complete:

HTTP/3 adoption continues to grow — global traffic data from 2025 shows approximately 25% of web requests using HTTP/3. Enabling the Alt-Svc advertisement allows supporting clients to benefit from QUIC’s improved performance on lossy or high-latency connections, while gracefully falling back to HTTP/2 or HTTP/1.1 for clients that do not support it.