Why HTTP/2 and QUIC Are Revolutionizing Web Performance

Since the birth of the World Wide Web in 1989, HTTP (HyperText Transfer Protocol) has undergone many version upgrades and gave rise to WebSocket. HTTP/0.9 appeared in 1991, HTTP/1.0 in 1996, HTTP/2 was officially released in 2015, and HTTP/3 (based on QUIC) is expected to be widely used in 2020.

1. HTTP 1.1 and HTTP 2

1.1 Defects of HTTP 1.1

High latency – Head‑Of‑Line Blocking Stateless nature – hampers interaction (no cookies, leading to login loss)

Plaintext transmission – insecure, vulnerable to tampering

No server push support

Head‑Of‑Line Blocking

When a request in a sequential request stream is blocked, all subsequent requests are also blocked, causing the client to wait indefinitely for data.

Mitigation strategies:

1. Distribute resources of the same page across different domains to increase connection limits.
2. Reduce the number of requests.
3. Inline some resources: CSS, base64 images, etc.
4. Merge small files to reduce resource count.

Stateless Nature

Stateless means the protocol has no memory of connection state. Pure HTTP lacks mechanisms such as cookies, so each connection is new; after a successful login, the next request does not carry the authentication information, resulting in a lost login session.

Insecurity

Data is transmitted without encryption and can be altered or hijacked in transit.

1.2 SPDY Protocol

SPDY is Google's improved version of HTTP/1.1 (before HTTP/2 existed).

Features

Multiplexing – solves head‑of‑line blocking

Header compression – reduces large HTTP headers

Request priority – fetches important data first

Server push – fills missing resources proactively

Improved security – supports HTTPS encryption

Multiplexing

SPDY allows unlimited concurrent streams on a single connection, making TCP usage more efficient because only one request is processed at a time on a given stream.

Header Compression

Using the HPACK algorithm, only the differences in headers are sent for each request/response, achieving 50%‑90% compression.

Request Priority

When bandwidth is limited, high‑priority requests are processed before low‑priority ones, preventing the channel from being blocked by non‑critical resources.

Server Push

Server Push lets the server proactively send resource files to the client, which the client may accept or reject.

Improved Security

Supports encrypted transmission via HTTPS.

1.3 HTTP/2

HTTP/2 is based on SPDY and focuses on performance, aiming to use a single connection between client and website.

New Features

Binary framing – core of HTTP/2 performance enhancement

Multiplexing – solves serial file transfer and excessive connections

Binary Framing

HTTP/2 retains HTTP/1 semantics but transmits data using binary frames at the application layer, introducing new units: frames, messages, and streams.

Framing increases the number of requests a server can handle per unit time, providing the foundation for multiplexing.

Multiplexing

One domain corresponds to one connection; a stream represents a complete request‑response cycle. Frames are the smallest data unit, each belonging to a specific stream, allowing multiple streams over a single TCP connection.

Demo: https://http2.akamai.com/demo

1.4 Defects of HTTP/2

Connection establishment latency – TCP (and TCP+TLS) handshake requires 1.5 RTT before data transfer.

TCP head‑of‑line blocking is not fully resolved.

Multiplexing increases server pressure, causing QPS spikes.

Multiplexing can lead to timeouts when many streams compete for limited bandwidth.

Connection Latency

TCP requires a three‑way handshake, consuming 1.5 RTT before data can be sent.

TLS Handshake

TLS 1.2 and TLS 1.3 have different handshake times, typically needing 1‑2 RTT.

Head‑Of‑Line Blocking Not Fully Solved

When a packet is lost, the entire TCP connection must wait for retransmission, blocking all streams.

Server Pressure

Multiplexing allows many concurrent streams, leading to sudden QPS bursts.

Timeouts

Multiple parallel streams share limited bandwidth and server resources; each stream may time out under high load.

2. QUIC

2.1 Introduction

Google, while promoting SPDY, realized its limitations and created QUIC, a UDP‑based protocol that underlies HTTP/3 and fully solves head‑of‑line blocking.

2.2 Main Features

Improved congestion control and reliable transmission

Fast handshake (0‑RTT / 1‑RTT)

Integrated TLS 1.3 encryption

Multiplexing

Connection migration

2.2.1 Improved Congestion Control & Reliable Transmission

QUIC re‑implements TCP functionality on top of UDP, offering pluggable congestion control at the application layer, monotonic packet numbers, and no reneging.

Pluggable Congestion Control

Different connections can use different congestion algorithms without restarting the server.

Monotonic Packet Number

Each packet receives a strictly increasing packet number, simplifying loss recovery and RTT calculation.

No Reneging

Once an ACK is received, the packet is considered successfully delivered and cannot be discarded.

Forward Error Correction (FEC)

Early QUIC versions used FEC to mix original data with redundant data for loss recovery, but it was later removed due to bandwidth overhead.

More ACK Blocks & ACK Delay

QUIC can send up to 256 ACK blocks, providing better resilience to packet reordering and loss.

Stream and Connection Level Flow Control

QUIC implements both stream‑level and connection‑level flow control to limit total buffered data and protect service availability.

2.2.2 Fast Handshake

Because QUIC runs over UDP, it can establish connections with 0‑RTT or 1‑RTT, dramatically reducing page‑load latency.

2.2.3 Integrated TLS 1.3 Encryption

TLS 1.3 offers three key‑exchange modes (EC)DHE‑PSK, PSK‑only, and DHE‑PSK. In a full handshake, 1‑RTT is needed; session resumption enables 0‑RTT encrypted data transmission.

However, TLS 1.3 0‑RTT does not guarantee forward secrecy; if the session ticket key is compromised, past traffic can be decrypted. Short‑lived DH parameters mitigate this risk.

2.2.4 Multiplexing

QUIC was designed for multiplexing from the ground up; loss in one stream only affects that stream.

2.2.5 Connection Migration

QUIC uses a 64‑bit Connection ID to identify a connection, allowing seamless migration across network changes without re‑handshaking.

2.3 Challenges of QUIC

2.3.1 NAT Issues

NAT devices map many private IPs to a single public IP and rely on TCP SYN/FIN flags to track connection lifetimes. QUIC over UDP lacks these flags, causing NAT mappings to expire before the session ends or to occupy ports unnecessarily.

Possible solutions include mimicking TCP SYN/FIN in QUIC headers (requiring global NAT firmware updates) or sending periodic QUIC Keep‑Alive messages to refresh NAT state.

2.3.2 NGINX Load‑Balancing Problems

QUIC clients may be routed to different server instances due to network changes, causing repeated 1‑RTT handshakes. A global handshake cache across all QUIC server instances can enable 0‑RTT handshakes regardless of which instance receives the request.

3 Historical HTTP Speed Tests

Conclusion

From the early days of HTTP to modern QUIC, real‑time data transmission (audio, video, gaming) has always faced latency and jitter. QUIC’s UDP‑based design and improved retransmission mechanisms can significantly enhance user experience, and platforms like Bilibili have already adopted QUIC. Developers can experiment with QUIC using libraries such as libquic, Caddy, or node‑quic.

Reference materials are listed at the end of the original article.