HTTP/2 vs HTTP/3: Performance, Security, and How to Enable Both

HTTP/2 and HTTP/3 are the modern protocols that power fast, secure web experiences. Both require TLS, both support multiplexing, and both eliminate many of the performance hacks (domain sharding, sprite sheets, concatenation) that HTTP/1.1 demanded. But they differ fundamentally in their transport layer: HTTP/2 runs on TCP, while HTTP/3 runs on QUIC, a UDP-based transport with TLS 1.3 built in.

This article compares the two protocols across performance, security, browser support, and server configuration. It is part of the SSL/TLS Configuration Guide. Verify your setup with the HTTP/2 Test and HTTP/3 Test tools on GF.dev.

HTTP/2: The First Major Upgrade

HTTP/2 was standardized in 2015 (RFC 7540, updated by RFC 9113) and is now supported by every modern browser. It introduced three key improvements over HTTP/1.1:

• Multiplexing — Multiple requests and responses share a single TCP connection simultaneously, eliminating head-of-line blocking at the HTTP layer.
• Header Compression (HPACK) — HTTP headers are compressed using a static and dynamic table, dramatically reducing overhead for repeated headers (cookies, User-Agent, etc.).
• Server Push — The server can proactively send resources the client has not yet requested. In practice, server push has been poorly adopted and Chrome removed support in 2022. Use 103 Early Hints instead.

HTTP/3: QUIC Changes Everything

HTTP/3 was standardized in 2022 (RFC 9114). Instead of TCP+TLS, it uses QUIC (RFC 9000), which runs on UDP and integrates TLS 1.3 directly into the transport handshake. This architecture change has several consequences:

• Zero transport-level head-of-line blocking — In HTTP/2, a single lost TCP packet stalls all multiplexed streams. In HTTP/3, each QUIC stream is independent, so packet loss on one stream does not affect others.
• Faster connection establishment — QUIC combines the transport and TLS handshakes into a single round trip. For returning connections, 0-RTT allows data in the first packet.
• Connection migration — QUIC connections are identified by a Connection ID, not by the 4-tuple (source IP, source port, dest IP, dest port). This means connections survive network changes (e.g., switching from Wi-Fi to cellular).
• QPACK header compression — Replaces HPACK with a design that avoids head-of-line blocking in the header compression layer itself.

Performance Comparison

HTTP/3 shows the biggest gains on high-latency or lossy connections (mobile networks, intercontinental links). On low-latency, reliable networks (data center to nearby CDN), the difference is less noticeable.

Security Differences

Both protocols require TLS, but HTTP/3 mandates TLS 1.3 specifically, which means:

• No weak cipher suites (TLS 1.3 only allows AEAD ciphers with forward secrecy).
• No renegotiation attacks.
• Encrypted transport headers (QUIC encrypts far more of the packet than TCP+TLS does).

For more on TLS 1.3 cipher suites, see TLS Cipher Suites Ranked.

Browser and Server Support (2026)

HTTP/2 is universally supported by all browsers and virtually all web servers. HTTP/3 support is now mainstream:

• Browsers: Chrome, Firefox, Safari, and Edge all support HTTP/3 by default.
• Servers: Nginx 1.25+ (mainline), Caddy (native), LiteSpeed (native), Apache (via mod_http3, experimental).
• CDNs: Cloudflare, Fastly, AWS CloudFront, Google Cloud CDN, and Akamai all support HTTP/3.

Enabling HTTP/2 on Nginx

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    # ... rest of config
}

Note: In Nginx 1.25+, the http2 directive replaces the old listen 443 ssl http2; syntax.

Enabling HTTP/2 on Apache

# Enable the module
sudo a2enmod http2

# In your VirtualHost
Protocols h2 http/1.1

sudo systemctl restart apache2

Enabling HTTP/3 on Nginx

server {
    listen 443 quic reuseport;
    listen 443 ssl;
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # Advertise HTTP/3 support
    add_header Alt-Svc 'h3=":443"; ma=86400' always;
}

The Alt-Svc header tells the browser that HTTP/3 is available. The browser will upgrade on the next connection.

Enabling HTTP/3 on Caddy

Caddy supports HTTP/3 out of the box with zero configuration. Simply run:

caddy reverse-proxy --from example.com --to localhost:8080

Caddy automatically provisions a TLS certificate, enables HTTP/2, and advertises HTTP/3.

Verifying Your Setup

After enabling HTTP/2 or HTTP/3, verify that clients are actually negotiating the new protocols:

1. Use the GF.dev HTTP/2 Test to confirm HTTP/2 is negotiated.
2. Use the GF.dev HTTP/3 Test to confirm HTTP/3 is advertised and reachable.
3. In Chrome DevTools, the Network tab's Protocol column shows h2 or h3 for each request.
4. Use curl --http3 (requires curl 7.88+ built with HTTP/3 support) to test from the command line.

Should You Enable Both?

Yes. HTTP/3 is not a replacement for HTTP/2 — it is a complement. Firewalls or networks that block UDP will prevent HTTP/3, and the client will fall back to HTTP/2 over TCP. Deploy both protocols so every client gets the best experience their network allows.

For the full TLS configuration that underpins both protocols, see the SSL/TLS Configuration Guide.