HTTP/2 vs HTTP/3

The request keeps its meaning

HTTP/2 and HTTP/3 carry familiar web requests: methods, paths, fields, status codes, and bodies. An application can keep the same URL and behavior while the transport underneath changes. Protocol selection is therefore a question about delivery, connection management, and deployment compatibility rather than a redesign of every endpoint.

For operators, this distinction is practical. A working page can conceal which protocol was negotiated. Conversely, an application error does not necessarily indicate a transport failure. Record the negotiated protocol separately from the HTTP status and the content received.

When planning a comparison, define a workload. A page with many small resources asks a different question from a single long video transfer or an interactive API with short requests.

HTTP/2 multiplexes above TCP

HTTP/2 represents messages as frames and uses streams to carry concurrent exchanges on one connection. Header compression reduces repeated field data. Stream-level flow control and prioritization-related mechanisms provide structure beyond a collection of independent HTTP/1.1 sockets. The authoritative protocol description is RFC 9113.

Because its typical web deployment runs over TLS and TCP, the byte stream underneath remains ordered as a whole. If missing TCP data prevents later bytes from being delivered, frames belonging to otherwise unrelated HTTP streams can wait. Application multiplexing therefore does not remove every form of transport waiting.

This matters most when loss and concurrency interact. It does not establish a fixed penalty for every HTTP/2 request, nor does it imply that an idle, low-loss connection is inefficient.

HTTP/3 delegates streams to QUIC

HTTP/3 maps HTTP onto QUIC. It retains a framed design but uses QUIC streams for delivery and a different header compression system, QPACK. Some functions formerly provided by the HTTP/2 layer move into the transport. RFC 9114 explains that mapping and the protocol's control streams.

QUIC provides reliable delivery within each stream without requiring all streams to share one ordered application byte sequence. Lost data affecting one stream need not block delivery on another simply because it belongs to the same connection. Shared congestion control, flow-control limits, and application dependencies still exist.

The distinction is specific: HTTP/3 changes where ordering applies. It does not promise unlimited parallelism, eliminate packet loss, or create capacity that the network path lacks.

UDP is the container, not the reliability policy

QUIC packets travel in UDP datagrams, but QUIC itself implements acknowledgments, retransmission-related recovery, connection state, and stream delivery. It would be inaccurate to infer that HTTP/3 abandons reliability because UDP alone does not supply it.

QUIC also uses connection identifiers, which can help keep a connection associated with its state when endpoint addressing changes. Migration is subject to protocol rules and endpoint support; it is not a guarantee that every network transition will be seamless. These mechanisms are specified in RFC 9000.

For a deployment, TCP and UDP reachability are separate checks. Opening TCP port 443 does not automatically establish that UDP on the same numeric port reaches the intended process.

Encryption and early data have boundaries

QUIC integrates TLS 1.3 for authentication and key establishment, with details in RFC 9001. The relationship differs from placing a conventional TLS record stream over TCP.

Resumed connections can support early data, which can reduce waiting in suitable exchanges. Early data carries replay considerations, so its presence is not a reason to send arbitrary state-changing operations before the handshake completes. Application design still determines which requests are safe to accept in that mode.

Think of connection setup as part of a request budget. A cache hit over a reused connection, a new connection, and a resumed connection are different test conditions and should be labeled separately in any comparison.

Inspect protocol negotiation explicitly

This illustrative curl check requests headers and reports the HTTP version. Feature availability depends on how the installed client was built.

curl --version
curl --http2 -I https://example.com/
curl --http3-only -I https://example.com/
curl -o /dev/null -sS -w '%{http_version}\n' https://example.com/

The HTTP/3-only command intentionally avoids silently answering the question with another protocol. A failure can reflect client support, server support, or path reachability. Consult the curl command reference for option behavior before interpreting it.

These commands are examples, not recorded results. Use a server you control for repeatable body-transfer tests, and preserve both the command and the negotiated version alongside timing output.

Compare useful outcomes

A fair experiment changes one variable at a time. Keep the client, server, object size, cache state, and test direction consistent. Alternate protocols across repeated runs so that a changing evening workload does not align every slow sample with one protocol.

Measure outcomes relevant to the application: time to first byte, completion time, sustained delivery, CPU cost, and failed requests. Retain individual samples instead of publishing only the fastest run. If a video needs stable delivery, examine interval data and player buffering rather than relying only on a short page-load result.

The resulting decision can be modest and useful: enable both protocols where supported, retain a compatible fallback, and verify that the chosen transport actually improves the workload on the networks your users use.