HTTP — Versions, TLS & Connection Lifecycle
HTTP is a versioned application protocol on TCP or QUIC, almost always under TLS. This hub maps HTTP/1.1, HTTP/2, and HTTP/3, plus where TLS ends and how pools, timeouts, and retries fail.
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
Question ladder
L1
Which transport does each HTTP version use?
Answer
HTTP/1.1 and HTTP/2 use TCP. HTTP/3 uses QUIC over UDP.
L2
Where does head-of-line blocking sit in each version?
Answer
HTTP/1.1 blocks on the connection. HTTP/2 multiplexes streams but a lost TCP packet stalls them all. QUIC recovers one stream.
L3
What does ALPN choose?
Answer
On TCP TLS, ALPN picks h2 or http/1.1 during the handshake. HTTP/3 is discovered with Alt-Svc or an HTTPS DNS record, then QUIC uses ALPN h3.
L4
Why did browsers cap HTTP/1.1 at about six connections per origin?
Answer
Fairness and server load. Domain sharding raised the cap and added DNS and TLS. HTTP/2 multiplexing made sharding a cost.
L5
Where should TLS end?
Answer
At the edge for public clients. Re-encrypt or use mTLS when the next hop is untrusted. Workload identity and L4 versus L7 design live on their own pages.
L6
What is unsafe about QUIC or TLS 0-RTT?
Answer
Early data can be replayed. Use it for idempotent reads, not for a POST that charges a card.
L7
How do connection pools fail after a deploy?
Answer
Idle timeouts disagree, GOAWAY is ignored, DNS pins a dead address, and retries without jitter stampede the new tasks.
Failure modes
HTTP/2 on a lossy last mile
Multiplexing hides the problem until one TCP loss stalls every stream. Measure HTTP/3 before you bet mobile tail latency on HTTP/2.
Cleartext after the edge
Terminating TLS at the edge and then sending HTTP across an untrusted network is not a private-network design.
Retry of a charging POST
A timeout does not prove the server skipped the write. Retry only idempotent methods, or writes that carry an idempotency key.
mTLS treated as user auth
A client certificate names a workload. User sessions and fine-grained authorization stay in the application.
Misconceptions
HTTP/2 removed head-of-line blocking.
It removed application HOL. TCP HOL remains. QUIC is the stream-level fix.
Server push is still the way to warm a browser cache.
Browsers dropped it. Use preload hints and the CDN cache hierarchy.
One connection pool setting fits every version.
HTTP/1.1 pools sockets. HTTP/2 and HTTP/3 pool sessions and streams.
Interviewer traps
Redesigning ALB, NLB, or Ingress when the question was the HTTP version.
Point at the L4 versus L7 page and the private-networking page, then stay on HOL, ALPN, and pools.
Re-teaching gRPC streaming or WebSocket frames.
Name the mapping in one sentence and send the listener to those clusters.
Design scenario
Same prompt for every reader.
Requirements
Mobile tail latency improves under loss. The internal RPC stays on HTTP/2. A UDP failure must not take the API down. Writes are not replayed.
Traffic / scale
Tens of thousands of short GETs per minute, plus a smaller set of charging POSTs.
Latency
A repeat GET should avoid a full handshake. A lost packet must not stall unrelated streams on the mobile path.
Consistency
A replayed early packet must not create a second charge.
Availability
If UDP/443 is blocked, clients fall back to HTTP/2 on TCP.
Failure assumptions
- One percent packet loss on the mobile path.
- A hotel network drops UDP.
- A deploy sends GOAWAY while clients still hold idle sessions.
Constraints
- Do not require HTTP/3 for correctness.
- Do not retry the charging POST without an idempotency key.
Prompt
A mobile app and an internal gRPC service both call the same origin. The mobile path is lossy. Corporate networks sometimes block UDP.
API
Which methods may use 0-RTT, and which must wait for the handshake?
Data
What do you record so a replayed POST is detected?
Architecture
Where does HTTP/3 terminate, and what speaks HTTP/2 behind it?
Where the bytes should ride
Prefer
HTTP/2 in the datacenter, HTTP/3 at a lossy edge
Stable TLS paths and gRPC stay on HTTP/2. Mobile and CDN edges prefer HTTP/3 when UDP works, with HTTP/2 still healthy as the fallback.
- One session carries many streams, so short calls stop paying a handshake each time.
- QUIC isolates loss to one stream and can migrate when the client IP changes.
- The origin still speaks a version you can curl and debug.
Alternative
HTTP/1.1 everywhere, or HTTP/3 with no fallback
Text HTTP/1.1 is the right debug path and the long tail of proxies. It is a poor default for a chatty browser. HTTP/3 with no TCP fallback fails closed on networks that drop UDP.
- About six sockets per origin and in-order responses bring back application HOL.
- Domain sharding spends DNS and TLS to fake concurrency HTTP/2 already has.
- A UDP-only launch looks fast in the lab and broken in a hotel.
Decide the version before you tune the pool
Client and path first, TLS placement second, retries last. Sibling pages hold the mechanics.
- 1
Name the path
A browser or CDN edge on a lossy network is the HTTP/3 case, if UDP/443 is open. A stable internal RPC is HTTP/2. A middlebox that only speaks text is HTTP/1.1. - 2
Keep a fallback
Advertise HTTP/3 with Alt-Svc or an HTTPS DNS record. Leave HTTP/2 on TCP healthy. Do not make correctness depend on UDP. - 3
Place TLS on purpose
Edge offload, re-encrypt, or mTLS. Write down the trust boundary. Do not invent a new load-balancer design on this page. - 4
Pool with budgets
HTTP/1.1 caps sockets. HTTP/2 and HTTP/3 cap streams. Align idle timeouts with the proxy so the client does not write into a reset. - 5
Retry only safe work
Idempotent reads can back off with jitter. A charging POST needs an idempotency key. 0-RTT is a read optimization, not a write path.
Overview
Interviewers want the bytes, not the framework middleware. A slow page is often six HTTP/1.1 sockets, a lost TCP packet under HTTP/2, a certificate chain that a phone will not build, or a pool that retries a POST.
Prefer HTTP/2 on stable TLS paths and for gRPC. The frame and HPACK detail is the HTTP/2 lesson. The RPC comparison already exists on gRPC versus REST. Do not rebuild it.
Prefer HTTP/3 at the edge for lossy mobile networks when UDP is allowed. Migration, 0-RTT, and QPACK are the QUIC lesson.
Keep HTTP/1.1 for curl, old proxies, and the text you can read on a socket. Keep-alive and pipelining are the HTTP/1.1 lesson.
Terminate TLS deliberately. Handshake cost, certificate fields, and mTLS placement are the TLS lesson. Anycast edge practice stays on TLS termination at the edge.
Why versions show up in the product
Browsers and backends still speak HTTP/1.1 on many hops. CDNs and modern clients negotiate HTTP/2 or HTTP/3. Choosing poorly looks like:
- A chatty UI stuck behind a handful of HTTP/1.1 connections.
- A mobile tail that stays bad on HTTP/2 because TCP HOL survived multiplexing.
- A retry that charges a card twice.
- TLS setup that dominates a short RPC because nothing is pooled or resumed.
- mTLS bolted onto the wrong hop, while user auth is still missing.
HTTP/1.1 versus HTTP/2 versus HTTP/3
| Dimension | HTTP/1.1 | HTTP/2 | HTTP/3 (QUIC) |
|---|---|---|---|
| Transport | TCP, TLS optional | TCP plus TLS, ALPN h2 | UDP plus QUIC, TLS 1.3 inside |
| Multiplexing | One response at a time; pipelining is rare | Many streams on one connection | Many streams on one connection |
| HOL | Application and TCP | TCP, under packet loss | Per stream |
| Header compression | None | HPACK | QPACK |
| Server push | Not in this version | Specified, unused in browsers | Specified, unused in browsers |
| Migration | New IP means a new connection | Same as TCP | Connection IDs |
| 0-RTT | TLS tickets, limited | Same TLS resumption | QUIC 0-RTT, replay risk |
| Best fit | Debug, legacy proxies | Datacenter, gRPC, calm networks | Lossy edge, modern browsers |
| Avoid when | High concurrency per origin | Lossy last mile and no HTTP/3 | UDP blocked, or you need every hop to inspect TCP |
Rule of thumb: HTTP/2 for the stable TLS path, HTTP/3 at the edge, HTTP/1.1 for the long tail. Always name where TLS ends.
Decisions
- 1
Need HTTP?
- Browser or CDNLossy mobile?
- Service or eventsTyped RPC?
- ?
Lossy mobile?
- YesUDP 443 open?
- NoHTTP/2 via ALPN
- ?
Typed RPC?
- YesgRPC on HTTP/2
- NoWebSocket or MQTT
- 4
gRPC on HTTP/2
- 5
WebSocket or MQTT
- ?
UDP 443 open?
- YesHTTP/3 at the edge
- NoHTTP/2 via ALPN
- 7
HTTP/2 via ALPN
- nextTLS 1.3 and certs
- 8
HTTP/3 at the edge
- nextTLS 1.3 and certs
- 9
TLS 1.3 and certs
- nextWorkload identity?
- ?
Workload identity?
- YesmTLS on the hop
- NoTerminate then AuthN
- 11
mTLS on the hop
- nextPool timeout retry
- 12
Terminate then AuthN
- nextPool timeout retry
- 13
Pool timeout retry
Lesson map
HTTP — Versions, TLS & Connection Lifecycle
HTTP is a versioned application protocol on TCP or QUIC, almost always under TLS. This hub maps HTTP/1.1, HTTP/2, and HTTP/3, plus where TLS ends and how pools, timeouts, and retries fail.
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["Need HTTP?"] b["Lossy mobile?"] c["Typed RPC?"] d["gRPC on HTTP/2"] a -->|Browser or CDN| b a -->|Service or| c c -->|Yes| d
Single column. Each decision has two exits. gRPC framing stays on the gRPC page. WebSocket frames stay on the WebSocket page.
Connection lifecycle
Flow
- 1
1 Resolve DNS
- next2 TCP or QUIC
- 2
2 TCP or QUIC
- next3 TLS and ALPN
- 3
3 TLS and ALPN
- next4 HTTP frames
- 4
4 HTTP frames
- next5 Reuse the pool
- 5
5 Reuse the pool
- next6 Drain or close
- 6
6 Drain or close
- Resolve. DNS, and Happy Eyeballs racing A and AAAA. A pool that ignores TTL pins a dead address after scale-in.
- Transport. TCP is one RTT before TLS. QUIC folds transport and crypto. A repeat visit may attempt 0-RTT.
- Secure. Certificate chain, name, expiry. TCP ALPN agrees
h2orhttp/1.1. HTTP/3 uses ALPNh3on QUIC after Alt-Svc or an HTTPS record. - Application. Method, headers, body. Streams exist only on HTTP/2 and HTTP/3.
- Reuse. Idle sockets or idle streams, capped by the peer. Watch
GOAWAYand max concurrent streams. - Teardown. Idle timeout, RST, or a graceful drain. The next page of the ring owns the pool failure modes.
| Step | What a good repeat call skips | What still hurts |
|---|---|---|
| DNS | A warm cache | A pool stuck on an old address |
| TCP | An idle socket or a QUIC session | A fresh IP after migration fails |
| TLS 1.3 | Resumption, sometimes 0-RTT | A full handshake on every call |
| Request | Nothing, this is the work | HOL, a tiny pool, a retry storm |
Quote the RTTs you remove. HTTP/1.1 to HTTP/2 removes extra handshakes. HTTP/2 to HTTP/3 changes loss recovery. "Faster" is not an answer.
TLS placement, hub level only
| Place | What you gain | What you still owe |
|---|---|---|
| CDN or edge | Global certs, offload | A trusted path to the origin, or a second TLS hop |
| L7 proxy | One policy point | Re-encrypt if the next hop is untrusted |
| Mesh sidecar | Workload identity per hop | The mesh operating cost |
| App process | End-to-end control | Certs and CPU on every instance |
Deep handshake and certificate rules are the TLS lesson. Edge anycast is TLS termination at the edge. Proxy layer choice is L4 versus L7. Sidecar capture is the mesh page. SPIFFE-style identity is service-to-service mTLS. This hub only forces the placement decision.
When not to stay on request/response HTTP
- Bidirectional product events. Start with the WebSocket and MQTT hub. The upgrade and ping frames live on the handshake page.
- Internal typed streaming RPCs. gRPC versus REST is the decision. This series only notes that gRPC rides HTTP/2 streams.
- Cacheable public bytes. Version choice does not replace cache keys. The hierarchy is CDN cache hierarchy.
- North-south network topology. Subnets, NAT, and ingress paths are private networking.
- Mesh versus a library versus a gateway. That comparison already exists. Link the tradeoff page and move on.
Sandbox: pick a version without opening a socket
The browser sandbox cannot complete a TLS handshake. The functions below are the interview decision. On a real machine, curl --http2 -v and curl --http3 -I show the negotiated version.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Production checklist
A fresh client fetches three small JSON documents from one origin. How many TCP and TLS handshakes does a single HTTP/1.1 connection pay, versus three connections, versus one HTTP/2 session? What changes if the second request is a large download and the third is a tiny API call?
Pitfalls
Interview Q&A
What is head-of-line blocking in HTTP/1.1 versus HTTP/2 versus HTTP/3?
Answer
HTTP/1.1 serves one response at a time on a connection, so an early large response blocks a later small one. Pipelining does not fix that, because responses stay in order. HTTP/2 interleaves streams, but a lost TCP segment stalls every stream until retransmission. HTTP/3 runs those streams on QUIC, so one stream can recover while the others continue.
Why about six connections per origin on HTTP/1.1?
Answer
Browsers capped parallel sockets so one page could not open dozens of connections and starve the server. Sites then sharded assets across hostnames to multiply the cap. Each shard paid DNS and TLS. HTTP/2 multiplexing removed the reason to shard, and sharding on HTTP/2 or HTTP/3 usually hurts.
What does ALPN do, and how is HTTP/3 discovered?
Answer
During a TCP TLS handshake the peers agree an application id, commonly h2 or http/1.1, with no extra round trip after the handshake. HTTP/3 is not chosen by that TCP handshake. The server advertises it with an Alt-Svc header or an HTTPS DNS record. The client then opens QUIC and negotiates ALPN h3.
Where should TLS terminate?
Answer
At the edge for public clients, then re-encrypt or use mTLS if the path inward is untrusted. Mesh sidecars fit when the identity you need is the workload. User sessions still belong to the app. Topology and anycast live on the private-networking and edge-termination pages.
Is HTTP/2 server push still recommended?
Answer
No for browsers. Push wasted bytes when the cache already held the resource, and Chrome removed it. Prefer preload hints and ordinary HTTP caching. The cache hierarchy itself is the CDN lesson.
What is dangerous about 0-RTT?
Answer
The client can send application data before the handshake finishes, using keys from a previous session. An attacker who captured that flight can replay it. Idempotent GETs can be designed for that. A POST that charges a card cannot.
How do connection pools fail in production?
Answer
The client idle timer and the load balancer idle timer disagree, so the next write gets a reset. Max streams is hit and the peer answers REFUSED_STREAM. NAT or a deploy leaves a dead socket in the pool. Retries line up without jitter. DNS changes and the pool keeps the old address. The last lesson in this series is that catalog.
When is a WebSocket a better fit than HTTP polling?
Answer
When the product needs bidirectional low-latency events. The session often still begins as HTTP. Protocol choice and frame details stay on the WebSocket pages. This hub only tells you not to fake that channel with a tight poll.