# HTTP/2 vs HTTP/3 > HTTP/2 multiplexes requests over TCP; HTTP/3 uses QUIC over UDP so packet loss on one stream does not impose TCP-level blocking on every stream. Choose HTTP/3 for public-facing traffic where lossy networks, connection setup, or network changes matter, and HTTP/2 where compatibility and operational simplicity matter more. A common design is HTTP/3 at the CDN or edge with HTTP/2 to backend services. Source: https://sysround.com/compare/http2-vs-http3 Updated: 2026-11-05 ## Side by side | | 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. ## 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. ## Interview questions where it comes up - [Design Instagram](https://sysround.com/questions/design-instagram): Concurrent image delivery through a CDN makes stream isolation, client network conditions, and edge protocol termination relevant. - [Design TikTok](https://sysround.com/questions/design-tiktok): Playback startup and mobile network changes motivate evaluating HTTP/3 at the media edge while preserving fallback. - [Design a video streaming service like YouTube](https://sysround.com/questions/design-youtube): The client-to-CDN transport choice affects connection setup and segment delivery without changing the transcoding or storage architecture. ## FAQ ### 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. ## Related concepts - [Content delivery networks (CDN)](https://sysround.com/concepts/cdn) - [TLS and HTTPS](https://sysround.com/concepts/tls) - [Load balancing](https://sysround.com/concepts/load-balancing) - [Reverse proxy](https://sysround.com/concepts/reverse-proxy) - [Connection pooling](https://sysround.com/concepts/connection-pooling) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.