HTTP/2 vs HTTP/3 - Protocol Evolution

HTTP/2 and HTTP/3 are modern versions of HTTP protocol solving HTTP/1.1 performance problems. Understanding their differences is critical for optimizing web application loading.

HTTP/1.1 → HTTP/2 → HTTP/3

HTTP/1.1 Problems

Head-of-Line Blocking

Client → Server
Request 1: style.css  (50KB, loading slowly)
Request 2: app.js     (10KB, fast, but WAITING!)
Request 3: image.png  (30KB, also waiting...)

Connection Limit

Browser opens maximum 6 connections per domain:

Connection 1: style.css
Connection 2: app.js
Connection 3: image1.jpg
Connection 4: image2.jpg
Connection 5: image3.jpg
Connection 6: font.woff
Request 7-100: WAITING!

Header Overhead

GET /api/users HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0...
Accept: application/json
Cookie: session=abc123...
...
(~500-800 bytes of headers every time!)

HTTP/2 - Solving Problems

Multiplexing

One TCP connection for all requests:

TCP Connection (ONE)
├── Stream 1: style.css  (frames: 1,2,3...)
├── Stream 2: app.js     (frames: 1,2,3...)
└── Stream 3: image.png  (frames: 1,2,3...)

Header Compression (HPACK)

Request 1:
:method: GET
:path: /api/users
:authority: example.com
cookie: session=abc123

Request 2:
:method: GET
:path: /api/posts
:authority: example.com
cookie: session=abc123
        ↑
    (compressed! already sent)

Savings: ~80-90% of header size!

Server Push

<!-- Client requests index.html -->
GET /index.html

<!-- Server pushes style.css BEFORE request! -->
PUSH_PROMISE: /style.css
PUSH_PROMISE: /app.js

Stream Prioritization

Stream Priority:
style.css    (weight: 256, critical)
app.js       (weight: 256, critical)
image1.jpg   (weight: 16, low priority)
image2.jpg   (weight: 16, low priority)

HTTP/2 Problem: TCP Head-of-Line Blocking

HTTP/2 multiplexes streams, but TCP is still linear:

TCP Packet Loss:
Packet 1: Stream 1, 2, 3
Packet 2: LOST!  (blocks!)
Packet 3: WAITING (available but cannot be processed)
Packet 4: WAITING

// All streams wait for Packet 2!

TCP guarantees order → if packet is lost, all streams are blocked.

HTTP/3 - QUIC Solves the Problem

QUIC = Quick UDP Internet Connections

Key Difference: HTTP/3 uses UDP instead of TCP!

QUIC Advantages

Independent Streams

QUIC (UDP):
Packet 1: Stream 1, 2, 3
Packet 2: LOST! (only Stream 2 is blocked)
Packet 3: Stream 1, 3 continue!
Packet 4: Stream 1, 3 work!

// Only Stream 2 waits, others continue!

0-RTT Connection Establishment

TCP + TLS 1.3:

Client → Server: SYN
Server → Client: SYN-ACK
Client → Server: ACK + ClientHello
Server → Client: ServerHello + Certificate
Client → Server: Finished
// 2-3 RTT before first data!

QUIC:

Client → Server: Initial Packet + TLS ClientHello + HTTP Request
Server → Client: Response!
// 1 RTT! (0-RTT on reconnection)

Connection Migration

// User switched from WiFi to 4G
// HTTP/2 (TCP): new connection
// HTTP/3 (QUIC): continues same connection!

// QUIC uses Connection ID instead of IP+Port
Connection ID: abc123
WiFi:  192.168.1.5:443  → Connection: abc123
4G:    10.0.0.15:443    → Connection: abc123 (same!)

Built-in Encryption

QUIC: TLS 1.3 built into protocol → always encrypted!

Comparison Table

Characteristic	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP	QUIC/UDP
Connections per domain	6	1	1
Multiplexing	No	Yes	Yes
HOL Blocking	Full	TCP level	No
Header Compression	No	HPACK	QPACK
Server Push	No	Yes	Yes
0-RTT	No	No	Yes
Connection Migration	No	No	Yes
Encryption	Optional	Optional	Required

Real-World Performance

Ideal Conditions (low packet loss)

HTTP/1.1: 5.0s
HTTP/2:   2.5s (2x faster)
HTTP/3:   2.3s (slightly faster than HTTP/2)

1% Packet Loss

HTTP/1.1: 6.0s
HTTP/2:   4.5s (TCP HOL blocking!)
HTTP/3:   2.8s (no HOL blocking!)

3% Packet Loss (poor mobile network)

HTTP/1.1: 10.0s
HTTP/2:   8.5s
HTTP/3:   3.5s (2.4x faster than HTTP/2!)

Adoption

Browsers:

Chrome/Edge: 100%
Firefox: 100%
Safari: 100%
Opera: 100%

CDN:

Cloudflare: 100%
Fastly: 100%
Google Cloud CDN: 100%
AWS CloudFront: 100%

Check:

# Chrome DevTools → Network → Protocol
# Look for "h3" or "http/3"

Best Practices for Developers

Use HTTP/3-compatible CDN

Cloudflare, Fastly, AWS CloudFront automatically use HTTP/3.

Don't use domain sharding

HTTP/2/3 don't need multiple domains. One domain is more efficient.

Optimize for mobile networks

HTTP/3 is especially effective with high packet loss (3G/4G).

Server Push with caution

Can lead to over-pushing. Use 103 Early Hints instead of Push.

Summary:

HTTP/3 + QUIC solve the fundamental TCP Head-of-Line Blocking problem, providing better performance especially on unstable networks. 0-RTT and Connection Migration make HTTP/3 ideal for mobile applications.

Back

Forward