Evolution and Limitations of HTTP/1.1, HTTP/2, and HTTP/3 (QUIC)

01 HTTP/1.1 Evolution and Drawbacks

1.1 Evolution of HTTP/1.1

1.1.1 Persistent Connections

Because establishing a new TCP connection for every request consumes significant resources, HTTP/1.1 introduced persistent connections so that multiple requests can reuse the same TCP link.

Connection: keep-alive

1.1.2 Pipelining

HTTP/1.1 improved the queuing model of HTTP/1.0 by adding a pipelining mechanism: multiple requests can be sent without waiting for previous responses, although responses must be returned in the order the requests were issued.

1.1.3 Chunked Transfer

In HTTP/1.0 the server had to finish a time‑consuming operation before sending any data, causing long waiting periods for the client. HTTP/1.1 introduced chunked transfer so the server can start streaming partial data as soon as it becomes available, reducing perceived latency.

1.2 Drawbacks of HTTP/1.1

1.2.1 TCP Connection Limits

Browsers limit the number of simultaneous TCP connections per domain to about 6‑8. To work around this, resources are spread across multiple hostnames, which introduces additional DNS lookups and can increase overall latency.

1.2.2 Head‑of‑Line Blocking

Each TCP connection can handle only one request‑response pair at a time; if an earlier response is delayed, later requests are blocked. Pipelining attempted to solve this but suffers from ordering constraints, caching overhead, and the need for full client‑proxy‑server support.

1.2.3 Insecure Plaintext Transmission

HTTP/1.1 transmits data in clear text, making it vulnerable to tampering, injection, and hijacking, which has led to numerous security incidents.

02 HTTP/2 Evolution and Drawbacks

2.1 Features of HTTP/2

HTTP/2 reduces the amount of data transferred compared to HTTP/1.1 by using binary framing and HPACK header compression, achieving 50‑90% compression and delivering 20‑60% performance gains with a single connection per origin.

2.1.1 Binary Framing

HTTP/2 retains HTTP/1.1 semantics but transports data as binary frames. New units such as frames, messages, and streams replace the traditional "Header+Body" model.

Frames allow the server to receive more requests per unit time, improving concurrency.

Binary framing underpins multiplexing.

2.1.2 HPACK Header Compression

Instead of sending headers as plain text, HTTP/2 uses HPACK, a Huffman‑based compression scheme that builds a shared dictionary between client and server, reducing header overhead by up to 90%.

2.1.3 Multiplexing

All communication for a given origin occurs over a single TCP connection, which can carry an arbitrary number of bidirectional streams. Each stream consists of frames that can be interleaved and reordered, eliminating the need for sequential transmission.

2.2 Drawbacks of HTTP/2

2.2.1 TCP+TLS Handshake Latency

Modern browsers require encrypted HTTP/2, so a TLS handshake (typically 2 RTT) is mandatory. The total latency for a fresh connection is roughly 4 RTT (DNS + TCP + TLS + HTTP), or 3 RTT with session resumption.

2.2.2 Incomplete Head‑of‑Line Blocking

Because HTTP/2 still relies on TCP, packet loss triggers TCP’s retransmission timer, causing all streams on that connection to stall until the lost packet is recovered.

2.2.3 Single‑Connection Issues

Using a single connection means that any loss or congestion affects all concurrent streams, whereas HTTP/1.1 could fall back to multiple connections to isolate problems.

03 HTTP/3 Evolution

3.1 Advantages of QUIC

HTTP/3 is essentially HTTP/2 over QUIC. QUIC eliminates head‑of‑line blocking by providing independent logical streams within a single physical connection.

3.1.1 Monotonically Increasing Packet Numbers

Each QUIC packet carries a unique, increasing packet number, replacing TCP’s sequence numbers and allowing precise RTT measurement even when packets are retransmitted.

3.1.2 Stream‑Based Multiplexing Without Head‑of‑Line Blocking

QUIC’s streams are independent; loss on one stream does not stall others, solving the head‑of‑line problem that plagued HTTP/2.

3.1.3 Improved Congestion Control

QUIC adopts TCP’s Cubic algorithm but allows pluggable congestion control implementations at the application layer, enabling rapid updates without kernel changes.

3.1.4 Connection Migration

QUIC identifies connections with a 64‑bit Connection ID, so IP or port changes (e.g., Wi‑Fi ↔ 5G) do not require a new handshake.

3.1.5 Forward Error Correction

Each packet includes redundant data from other packets, allowing the receiver to reconstruct small losses without retransmission, at the cost of slightly reduced payload capacity.

3.2 QUIC Handshake

QUIC merges TCP and TLS handshakes, enabling 0‑RTT connections when the client has prior state with the server, thereby eliminating one round‑trip compared to classic TCP + TLS.

3.3 Diffie‑Hellman Key Exchange in QUIC

Alice and Bob both know two primes (g, p)

Alice has private key a; Bob has private key b

Alice computes A = g^a mod p and sends A to Bob;

Bob computes B = g^b mod p and sends B to Alice;

Alice computes K = B^a mod p; Bob computes K = A^b mod p; both obtain the shared secret K.

QUIC uses the initial key for 0‑RTT handshakes and a forward‑secure key for the rest of the session.

References

Interpretation of HTTP/2 and HTTP/3 new features – https://mp.weixin.qq.com/s/t0QTQr0kpjly0Cat2q3TLw

Analysis of HTTP/2 multiplexing – https://segmentfault.com/a/1190000011172823

QUIC connection migration series – https://my.oschina.net/u/4703596/blog/4769057

Detailed QUIC encryption handshake – https://blog.csdn.net/chuanglan/article/details/85106706