iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
HTTP/2 can send multiple requests at once, but it still runs over TCP. When TCP loses a packet, its ordered byte stream can hold back data for several HTTP/2 streams until the missing bytes arrive. HTTP/3 was created to reduce that cross-stream delay: it carries HTTP over QUIC, whose reliable streams can make progress independently. That is a protocol-design advantage, not a guarantee that every website will load faster.
Why was HTTP/3 created?
HTTP/2 added multiplexing: a client and server can exchange data for multiple requests at the same time over one connection. But HTTP/2 uses TCP, which presents data to applications as one ordered byte stream. If a segment is lost, TCP must recover the missing bytes before passing later bytes to the application—even when those later bytes belong to a different HTTP/2 stream.
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
For example, suppose one TCP connection carries a page’s HTML, a stylesheet, and several images. If a segment containing part of the stylesheet is lost, TCP may withhold later data for the images as well. HTTP/2 has separate streams, but TCP’s ordering applies beneath them. This conditional transport-level head-of-line blocking is the limitation HTTP/3 addresses. The HTTP/2 specification notes that TCP head-of-line blocking is not addressed by HTTP/2 (RFC 9113).
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchHow does QUIC change the transport?
HTTP/3 maps HTTP exchanges onto QUIC, a secure, multiplexed transport that runs over UDP. QUIC provides independent streams, flow control, connection security, and path migration. Because reliable delivery is handled per stream, a missing packet affecting one stream does not automatically prevent other streams from delivering data. The HTTP/3 specification describes this independence directly (RFC 9114).
#1 Best Overall
HTTP/3 still uses binary framing, but QUIC supplies functions that HTTP/2 handled in its own framing and connection behavior, including stream identifiers, stream termination, and flow control. HTTP/3 also uses dedicated unidirectional streams for control information and for QPACK’s compression state.
QUIC does not eliminate loss or delay. A stream still waits for its own missing data, and congestion control remains connection-wide. The improvement is narrower: loss on one stream need not block delivery on every other stream.
What is the difference between HTTP/2 and HTTP/3?
| Feature | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP, commonly used with TLS | QUIC over UDP; QUIC integrates TLS 1.3 |
| Multiplexing | HTTP streams share one TCP connection | QUIC streams carry HTTP exchanges |
| Effect of packet loss | TCP’s ordered delivery can delay data across streams while a missing segment is recovered | Reliable delivery is per stream, so loss on one stream need not stop progress on others |
| Flow control | HTTP/2 flow control applies to DATA payloads | QUIC flow control applies to stream data, including HTTP/3 frames |
| Header-field compression | HPACK | QPACK, designed for QUIC’s stream model |
| Connectivity fallback | Uses TCP | Uses UDP; clients should try TCP-based HTTP if QUIC connectivity fails |
Why HTTP/3 uses QPACK instead of HPACK
HTTP/2 uses HPACK to compress header fields. HPACK assumes ordered delivery of a field block, which fits TCP’s ordered stream. QUIC streams can progress independently, so HTTP/3 uses QPACK, which is designed for that model. QPACK lets an encoder balance compression efficiency against the risk that a header block waits for dynamic-table updates on another stream; it does not make every possible compression dependency disappear.
Does HTTP/3 fix head-of-line blocking?
It reduces the transport-level, cross-stream form that can occur with HTTP/2 over TCP. In HTTP/3, a lost packet affecting one QUIC stream does not inherently prevent other streams from progressing. The HTTP/3 specification says that a blocked or loss-affected stream does not prevent progress on other streams (RFC 9114, Section 2).
That is not a fix for every kind of blocking. Data on the affected stream can still wait for recovery, congestion control can limit traffic across the connection, and QPACK dependencies can introduce waiting when the encoder chooses compression settings that rely on dynamic-table updates.
Does HTTP/3 use UDP?
Yes. HTTP/3 runs over QUIC, and QUIC uses UDP. This allows QUIC to implement its own stream, security, and loss-recovery behavior rather than inheriting TCP’s single ordered byte stream. QUIC’s design is specified in RFC 9000.
Rank #4
UDP is not reachable on every network. Firewalls or other path conditions can prevent a QUIC connection from being established. HTTP/3 is normally used for HTTPS; the ordinary http URI authority convention assumes TCP rather than providing the standard path for direct HTTP/3 use.
How does a browser discover HTTP/3, and what happens if it fails?
An origin can advertise an equivalent HTTP/3 endpoint using the Alt-Svc mechanism, with the h3 ALPN token. A client that learns HTTP/3 is available can try QUIC. If QUIC setup fails—for example, because UDP is blocked—the HTTP/3 specification says clients should attempt a TCP-based version of HTTP (RFC 9114, Section 3).
Best Value
This makes HTTP/3 a negotiated capability rather than a transport that works on every connection. The fallback lets a client use HTTP over TCP when QUIC is unavailable.
Is HTTP/3 faster?
It can perform better when TCP-level head-of-line blocking is a meaningful bottleneck, because loss on one QUIC stream need not hold back unrelated streams. But the protocol specifications do not establish a universal page-load improvement percentage. Actual results depend on network conditions, UDP reachability, the workload, and the client and server implementations. HTTP/3’s design explains when it may help; it does not promise a speedup in every setting.
For the broader definition of HTTP behavior and semantics, see RFC 9110.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
