Module 9 · Protocols, Security, ObservabilityDay 08125 min

HTTP/1.1 → HTTP/2 → HTTP/3

How the web's transport got faster — and what it means for your design.

← Previous Next →

Day 081

HTTP/1.1 → HTTP/2 → HTTP/3

25m

focus

HTTP/1.1

note

HTTP/2

note

HTTP/3

note

Memory hook

HTTP/1.1 → HTTP/2 → HTTP/3: how the web's transport got faster

Mental model

design for the day something breaks

Design lens

HTTP/2 server-side cost: more concurrent state per conn.

Recall anchors

1.123

Why it matters

HTTP/1.1 keeps connections alive but serializes requests. HTTP/2 multiplexes many requests on one TCP. HTTP/3 moves to QUIC over UDP for better behavior on lossy networks.

1Compare HTTP/1.1, /2, /3 wire-level differences.
2Recognize the head-of-line problem and how it's solved.
3Apply protocol choice to backend strategy.

Deep dive

HTTP/1.1: persistent connections + pipelining (rare). Domain sharding was a workaround.

HTTP/2: stream multiplexing, header compression (HPACK), server push (deprecated). One TCP, many streams — but TCP head-of-line.

HTTP/3 (QUIC/UDP): per-stream loss recovery, faster handshake, connection migration.

Demo / scenario

API page makes 30 small requests.

HTTP/1.1: 6 connections + serial — slow on RTT.
HTTP/2: one connection, parallel streams.
HTTP/3: same plus mobile-network resilience.
Real-world: gains depend on distance and loss rate.

Tradeoffs

HTTP/2 server-side cost: more concurrent state per conn.
HTTP/3 needs UDP open in firewalls.
Many libraries still default to HTTP/1.1 for simplicity.

Diagram

HTTP version evolution.

Mind map

Check yourself

Loading quiz…

Sources & further reading

RFC 9114 (HTTP/3)

← Previous Next →