The server forgets you. Your token remembers.
Each request stands alone, so the load balancer can send your next one to any server. State rides along in a cookie or a signed token.
POST /payments timed out. Retry?
Bad: Retry it blindly
It may have charged. POST isn’t idempotent, so a retry can charge twice.
Good: Send an idempotency key
The retry gets the first answer back, not a second charge.
500 ms
waiting for 60 files over HTTP/1.1
At 50 ms RTT, six connections take 10 round trips each. HTTP/2 sends all 60 at once on one connection, in about 50 ms.
Why HTTP/2 can lose on shaky mobile networks
Its streams share one TCP connection that hands over bytes in order, so one lost packet stalls them all. HTTP/3’s QUIC stalls only the affected stream.
HTTPS encrypts every byte. Surely encryption is the slow part?
The real cost
Round trips. Gmail’s TLS used under 1% of CPU, but a new connection waits up to three round trips before your request leaves.
Shake hands next door, not across the ocean
A new connection from Mumbai to Virginia needs three ocean round trips, 600 ms. End TLS at a Mumbai edge that reuses a warm link, about 230 ms.
Every shortcut has a catch
- 0-RTT data can be replayed, so send only GETs
- Keep app keep-alive above the balancer’s, or get 502s
- Long-lived HTTP/2 connections pin clients, so cap their age
Remember
HTTP is stateless: state rides in a token. GETs are cacheable; POSTs carry an idempotency key. End TLS 1.3 at an edge near users, serve HTTP/2 and HTTP/3, reuse connections, and use mTLS inside.