Networking · Updated 2026-06-05

HTTP/2 vs HTTP/3

HTTP/3 is the better protocol on paper and a clear win on lossy or mobile networks, because it kills TCP’s connection-level head-of-line blocking and sets up connections faster. HTTP/2 is still everywhere, simpler to operate, and fine on clean wired networks. In practice you enable both: serve HTTP/2 as the baseline and advertise HTTP/3 (via Alt-Svc) so capable clients upgrade.

HTTP/2

Multiplexed HTTP over a single TCP connection.

Since: 2015
By: IETF (RFC 9113, orig. 7540)
License: Open standard

www.rfc-editor.org/rfc/rfc9113 ↗

HTTP/3

HTTP over QUIC, which runs on UDP.

Since: 2022
By: IETF (RFC 9114)
License: Open standard

www.rfc-editor.org/rfc/rfc9114 ↗

Both deliver the same thing — multiplexed HTTP requests — but over different transports. HTTP/2 multiplexes streams over one TCP connection, so a single lost packet stalls every stream behind it. HTTP/3 moves to QUIC over UDP, where each stream is independent, packet loss is per-stream, and the handshake folds TLS in for faster (often 0-RTT) setup.

Quick takes

If you're…

Your users are on mobile or lossy networks HTTP/3 QUIC’s per-stream independence avoids the TCP head-of-line stall that hurts lossy links most.
You want the simplest possible server/proxy setup HTTP/2 HTTP/2 over TCP is universally supported and needs no UDP firewall changes.
Connection setup latency matters (lots of short sessions) HTTP/3 QUIC combines transport + TLS in one handshake, with 0-RTT resumption for repeat visits.
Clients roam between networks (Wi-Fi to cellular) HTTP/3 QUIC connection migration survives IP changes without a full reconnect.
UDP is blocked or throttled in your environment HTTP/2 HTTP/3 needs UDP/443 open; where it is filtered, clients fall back to HTTP/2 anyway.
You are debugging the wire with standard tooling HTTP/2 TCP/HTTP2 is easier to inspect; QUIC is encrypted end-to-end and harder to trace.

Decision wizard

A few questions, a verdict.

What networks do your users sit on?

How much do you value operational simplicity?

Can you open UDP/443 end to end?

At a glance

The scorecard.

Dimension

HTTP/2

HTTP/3

Edge

Transport core

TCP + TLS

QUIC over UDP

depends

Head-of-line blocking core

TCP-level HoL persists

No transport HoL

HTTP/3

Connection setup features

TCP + TLS round-trips

1-RTT, 0-RTT resume

HTTP/3

Connection migration features

Reconnect on IP change

Survives network change

HTTP/3

Header compression features

HPACK

QPACK

tie

Operability & support ops

Universal, inspectable

Broad but newer ops

HTTP/2

CPU cost ops

Cheap, kernel/offload

Higher CPU (improving)

HTTP/2

In depth

Dimension by dimension.

core

Transport

depends

HTTP/2

Runs over TCP; relies on the kernel’s TCP stack and TLS on top.

HTTP/3

Runs over QUIC, which runs over UDP and integrates TLS 1.3 into the transport.

core

Head-of-line blocking

edge: HTTP/3

HTTP/2

Application-layer HoL is solved, but TCP-level HoL remains: one lost packet stalls all streams.

HTTP/3

Eliminated: QUIC streams are independent, so loss on one stream does not block others.

features

Connection setup

edge: HTTP/3

HTTP/2

TCP handshake then a separate TLS handshake — multiple round-trips on first connect.

HTTP/3

One combined QUIC+TLS handshake; 0-RTT resumption for returning clients.

features

Connection migration

edge: HTTP/3

HTTP/2

A network change (new IP) breaks the TCP connection and forces a reconnect.

HTTP/3

Connection IDs let a session survive IP changes — seamless Wi-Fi↔cellular handoff.

features

Header compression

tie

HTTP/2

HPACK header compression.

HTTP/3

QPACK — HPACK adapted so head-of-line blocking does not reintroduce stalls.

ops

Operability & support

edge: HTTP/2

HTTP/2

Supported by essentially every server, proxy, and client; easy to inspect.

HTTP/3

Widely supported by browsers and CDNs, but UDP handling, load balancing, and tracing are newer.

ops

CPU cost

edge: HTTP/2

HTTP/2

TCP offload and mature stacks make it cheap per byte.

HTTP/3

QUIC runs largely in user space; historically higher CPU per byte, improving with offloads.

When to pick neither

A different shape of problem.

HTTP/1.1

Maximum compatibility or simple internal services where multiplexing does not matter
gRPC (over HTTP/2)

Internal RPC; gRPC standardised on HTTP/2 framing
WebTransport (over HTTP/3)

You want QUIC’s datagrams/streams for realtime in the browser

Situational picks

For specific cases.

A public website or API behind a CDN

Either

Enable both: HTTP/2 as the floor and HTTP/3 via Alt-Svc so capable clients get QUIC’s benefits automatically.

A global, mobile-heavy product

HTTP/3

HTTP/3’s loss handling and connection migration directly improve real-world tail latency.

Internal datacenter traffic on clean links

HTTP/2

On low-loss wired networks HTTP/2’s benefits are realised and it is simpler to run and debug.

An environment that filters UDP

HTTP/2

HTTP/3 needs UDP/443; where it is blocked, HTTP/2 is the reliable baseline.

Sources

Primary material.

Found this useful?