HTTP/1.1 → 2 → 3 · Prasanta Kumar Behera

Why HTTP keeps changing: HTTP/1.1 connections and keep-alive, HTTP/2 multiplexing and header compression, the head-of-line blocking that remained, and HTTP/3 over QUIC, with what each means for proxies and load balancers.

Three generations of HTTP

	HTTP/1.1	HTTP/2	HTTP/3
Transport	TCP	TCP (+ TLS, via ALPN `h2`)	QUIC over UDP (TLS 1.3 built in)
Requests per connection	One at a time (keep-alive reuses it)	Many at once (multiplexed streams)	Many at once
Headers	Text, repeated every time	Binary, compressed (HPACK)	Compressed (QPACK)
Head-of-line blocking	Per connection (queued requests)	At the TCP level (one lost packet stalls all streams)	Per stream only
Connection setup	TCP + TLS round trips	Same	Combined; can resume with 0-RTT

HTTP/1.1 is a single-lane road: cars go one after another. HTTP/2 is a multi-lane motorway on one bridge: many cars at once, but if one lane's bridge section breaks (a lost packet), everyone stops. HTTP/3 builds separate little bridges for each lane, so one problem only stops that lane.

HTTP/1.1: keep-alive matters

Without keep-alive, every request pays for a new TCP (and TLS) handshake. With it, the connection is reused, but requests on one connection are sequential. That's why clients open several connections and why connection pooling matters in services.

$ curl -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s\n' -o /dev/null -s https://shop.example.com/
connect=0.012s tls=0.041s first_byte=0.087s

HTTP/2: one connection, many streams

HTTP/2 multiplexes requests as streams over one TLS connection and compresses headers. It's negotiated with ALPN during the TLS handshake (lesson 09). gRPC is built on it.

Things to know in platforms:

Load balancing: an L4 balancer sees one long connection and sends all its requests to one pod. Use an L7 proxy (ingress, gateway, mesh) that balances per request (lesson 11 applies this to gRPC).
h2c (HTTP/2 without TLS) is common inside clusters for gRPC; proxies must be configured for it explicitly.
Proxies may downgrade to HTTP/1.1 to the backend unless configured otherwise. Know what each hop speaks.

HTTP/3 and QUIC

QUIC runs over UDP, merges the transport and TLS 1.3 handshakes, handles loss per stream, and survives client IP changes (connection migration, for example moving from Wi-Fi to mobile). Browsers discover HTTP/3 through an Alt-Svc header on an HTTP/2 or HTTP/1.1 response, or DNS records.

Platform impact:

UDP port 443 must be open through firewalls and load balancers (many L4 balancers and NAT devices treat UDP differently).
It usually terminates at the edge (CDN, cloud LB, or an ingress/gateway with HTTP/3 enabled); traffic inside the cluster typically stays HTTP/1.1 or HTTP/2.
Clients fall back to HTTP/2 automatically when UDP is blocked.

Try it: compare versions

Against a public site that supports all three (many large sites do): curl -sI --http1.1, --http2 and (if your curl supports it, check curl -V) --http3, and compare the status lines.
Print %{http_version} and the timing variables for each version, several times.
Against your ingress on kind, check which version you get with plain curl -v (look for ALPN: server accepted h2).
Look at the Alt-Svc response header of a site that offers HTTP/3.

Going deeper: HTTP in the platform

Configure idle and max connection lifetimes on proxies so long-lived HTTP/2 connections are recycled, spreading load after scale-ups.
Watch for request smuggling risks when proxies and backends disagree on HTTP/1.1 parsing; keep proxies updated and prefer HTTP/2 between hops.
Header size limits, large cookies and long URLs cause 4xx errors at proxies before requests reach apps. Check proxy logs first.

Recap

HTTP/1.1: one request at a time per connection; keep-alive and pooling matter.
HTTP/2: multiplexed streams and compressed headers over one TCP+TLS connection (ALPN h2); balance per request.
HTTP/3: QUIC over UDP, per-stream loss handling, faster setup; usually terminated at the edge.
Know which version each hop speaks.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.