Side by side
| Dimension | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP | QUIC over UDP |
| Multiplexing | Multiple HTTP streams in one TCP connection | Multiple independently delivered QUIC streams |
| Packet loss | Missing TCP bytes block delivery across streams | Loss generally blocks only affected streams |
| Encryption | TLS in browser deployments | TLS 1.3 integrated into QUIC |
| Fresh connection setup | Typically 2 RTTs with TCP and TLS 1.3 | Typically 1 RTT with QUIC |
| Header compression | HPACK | QPACK, designed for independent streams |
| Network changes | Usually require a new connection | Can preserve connections through supported migration |
| Deployment constraints | Broad TCP and proxy compatibility | Requires UDP reachability and QUIC-aware infrastructure |
| Operations | Established TCP tooling and tuning | Requires QUIC-aware metrics, tracing, and tuning |
The differences that matter
HTTP/2 removes HTTP/1.1 request-level head-of-line blocking through multiplexing, but TCP still delivers one ordered byte stream. If a TCP segment is lost, later bytes wait even when they belong to unrelated HTTP requests. QUIC provides ordering within each stream instead. HTTP/3 streams still share connection-level congestion control, so packet loss can reduce throughput for all of them.
Connection setup matters most for new or frequently interrupted connections. Excluding DNS, a fresh HTTP/2 connection over TCP and TLS 1.3 typically needs two round trips before sending an application request; QUIC typically needs one. Resumed QUIC connections can send eligible requests with 0-RTT data, but acceptance is not guaranteed and replay risk makes it unsuitable for unprotected state-changing operations.
QUIC connection IDs can let a connection survive a client address change, such as switching from Wi-Fi to cellular, subject to path validation and implementation support. TCP connections usually need to be reestablished. This can reduce transport reconnect work, but it does not replace application-level resume tokens, durable cursors, or retry handling.
HTTP/3 changes the edge deployment more than the application data model. UDP must reach the QUIC endpoint, and load balancers must route packets consistently, including during supported migration. Keep an HTTP/2 fallback for blocked UDP paths, and measure fallback delays as well as successful HTTP/3 requests. The CDN can terminate HTTP/3 while using HTTP/2 to the origin.
Header compression also changes: HTTP/2 uses HPACK, while HTTP/3 uses QPACK to work with independently delivered streams. QPACK reduces compression-related cross-stream blocking but does not eliminate all dependencies. Neither protocol fixes slow database queries, oversized responses, application dependency chains, or overloaded servers.
Choose HTTP/2 when
- Clients or enterprise networks have uncertain UDP support, and dependable connectivity is more important than potential transport improvements.
- Internal service calls use stable, low-loss networks and long-lived connections, making connection setup a small part of request latency.
- Your proxies, inspection requirements, and troubleshooting tools support HTTP/2 well but do not yet support QUIC adequately.
- Measurements show application processing dominates latency, so protocol migration would not address the main bottleneck.
Choose HTTP/3 when
- Mobile clients make concurrent requests over lossy networks, where TCP-level cross-stream blocking affects user-visible latency.
- Clients frequently establish new connections, and reducing connection setup time matters to the latency budget.
- Clients switch networks during active sessions, and your client and edge implementations support QUIC migration.
- Your CDN or edge supports HTTP/3, you can retain HTTP/2 fallback, and client-segment measurements justify enabling it.
A worked example
A mobile photo feed with concurrent image requests
Suppose a mobile feed loads metadata and 24 thumbnails over one client-to-CDN connection, with an assumed 80 ms network RTT. With HTTP/2, a lost TCP segment can delay delivery of bytes for several thumbnail streams until the missing bytes arrive. With HTTP/3, streams whose data arrived can continue, although shared congestion control can still slow the connection. Enable HTTP/3 at the CDN, retain HTTP/2 fallback, and leave CDN-to-origin traffic on HTTP/2 unless measurements justify another change. Compare time to first visible images and tail completion time across cellular and Wi-Fi clients. The 80 ms RTT is a scenario assumption, not a predicted speedup.
In the interview
- Name the connection hop: browser to CDN, CDN to origin, or service to service. Choosing HTTP/3 for the first hop does not require changing every backend connection.
- Explain the precise failure mechanism: TCP loss blocks delivery across HTTP/2 streams; QUIC isolates stream delivery but still shares congestion control and bandwidth.
- Separate fresh connections from reused connections. Interviewers may ask whether handshake savings matter when connections are pooled or kept alive.
- Propose a rollout with HTTP/2 fallback and compare tail latency, connection failures, fallback delay, CPU cost, and performance by network type rather than claiming HTTP/3 is universally faster.
- Be ready to explain QUIC-aware load balancing and 0-RTT replay safety. Connection IDs affect packet routing, while transport security does not make a replayed payment request safe.
Common mistakes
- Saying HTTP/2 has no head-of-line blocking because it supports multiplexing, without distinguishing HTTP streams from TCP byte delivery.
- Treating HTTP/3 as unreliable because it uses UDP. QUIC implements reliable, ordered delivery within streams above UDP.
- Promising a fixed latency or throughput improvement without considering RTT, packet loss, connection reuse, server cost, and fallback behavior.
- Assuming HTTP/3 replaces caching, application retries, idempotency, or durable reconnect and replay mechanisms.
Where it comes up
Interview questions where choosing between HTTP/2 and HTTP/3 comes up.
- Design InstagramConcurrent image delivery through a CDN makes stream isolation, client network conditions, and edge protocol termination relevant.
- Design TikTokPlayback startup and mobile network changes motivate evaluating HTTP/3 at the media edge while preserving fallback.
- Design a video streaming service like YouTubeThe client-to-CDN transport choice affects connection setup and segment delivery without changing the transcoding or storage architecture.
Questions people ask
Is HTTP/3 always faster than HTTP/2?
No. HTTP/3 can improve connection setup and reduce cross-stream blocking on lossy paths, but results depend on connection reuse, network conditions, implementation, and server resources. On stable networks with reused connections, the difference may be small.
Why does HTTP/3 use UDP instead of TCP?
UDP lets QUIC implement its own stream delivery, loss recovery, congestion control, and connection management without TCP's single ordered byte stream. HTTP/3 still provides reliable HTTP delivery through QUIC; it does not simply send unreliable HTTP messages.
Can HTTP/2 and HTTP/3 run on the same website?
Yes. An edge can offer HTTP/3 over UDP and HTTP/2 over TCP, often using port 443 for both transports. Clients can discover HTTP/3 support through mechanisms such as Alt-Svc or HTTPS DNS records and use HTTP/2 when HTTP/3 is unavailable.