Loading...
Loading...
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.
Client → Server
Request 1: style.css (50KB, loading slowly)
Request 2: app.js (10KB, fast, but WAITING!)
Request 3: image.png (30KB, also waiting...)
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!
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!)
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...)
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!
<!-- Client requests index.html -->
GET /index.html
<!-- Server pushes style.css BEFORE request! -->
PUSH_PROMISE: /style.css
PUSH_PROMISE: /app.js
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 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.
Key Difference: HTTP/3 uses UDP instead of TCP!
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!
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)
// 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!)
QUIC: TLS 1.3 built into protocol → always encrypted!
| 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 |
HTTP/1.1: 5.0s
HTTP/2: 2.5s (2x faster)
HTTP/3: 2.3s (slightly faster than HTTP/2)
HTTP/1.1: 6.0s
HTTP/2: 4.5s (TCP HOL blocking!)
HTTP/3: 2.8s (no HOL blocking!)
HTTP/1.1: 10.0s
HTTP/2: 8.5s
HTTP/3: 3.5s (2.4x faster than HTTP/2!)
Browsers:
CDN:
Check:
# Chrome DevTools → Network → Protocol
# Look for "h3" or "http/3"
Cloudflare, Fastly, AWS CloudFront automatically use HTTP/3.
HTTP/2/3 don't need multiple domains. One domain is more efficient.
HTTP/3 is especially effective with high packet loss (3G/4G).
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.