HTTP · Production Engineering

Reusing one TCP connection for multiple requests instead of opening a new one each time. Default in HTTP/1.1, essential in HTTP/2/3.

<link rel="preconnect"> lets the browser start DNS + TCP + TLS for a critical third-party origin before it's actually needed, hiding that latency behind other work.

The long-standing default — supported everywhere, a large reduction for text (often well over half, depending on content), cheap to decode.

Google's newer algorithm. Brotli can compress text assets more efficiently than gzip, but the difference depends on the content and compression settings. Precompressing static assets avoids paying the compression cost on every request.

The client advertises what it accepts via Accept-Encoding: gzip, br; the server picks one and declares it via Content-Encoding. This is HTTP content negotiation — the same mechanism used for language and format negotiation.

Cache-Control: public, max-age=31536000, immutable on a content-hashed filename (app.a1b2c3.js). Safe because a new deploy is a new URL — the old cached copy never needs to be invalidated.

Cache-Control: no-cache (revalidate every time) on index.html itself — it's the one file that must always reflect the latest deploy's asset references.

Serves a slightly stale cached response immediately while fetching a fresh one in the background — trades perfect freshness for zero perceived latency.

Origin pull: the CDN fetches from your origin on a miss, then reuses that cached copy for later HTTP requests. Origin push: you preload content into the CDN ahead of demand. For typical web apps, origin pull is the common default.

For HTTP deploys, versioned asset URLs are still the cleanest answer: a new filename produces a new cache key everywhere. Purge APIs exist for emergencies and HTML/API corrections, but they are operational tools, not the primary deployment strategy.

The proxy commonly holds the certificate and decrypts HTTPS traffic once, then forwards to application servers over an internal network using plain HTTP or re-encrypted HTTPS, depending on trust boundaries and compliance needs.

For HTTP traffic, this is where host-, path-, and header-based routing happens — for example api.example.com to one service and /admin to another — without every backend having to expose itself directly to the internet.

HTTP-aware proxies can buffer slow uploads, enforce request size limits, add or scrub forwarding headers, and apply coarse rate limits before expensive application work begins.

Round-robin works well when HTTP requests are similar in cost and connection reuse is not creating large imbalance.

Least-connections is often better when some HTTP requests stream for a long time or have widely different durations, though implementation details matter under HTTP/2 and HTTP/3 where one client connection can carry many requests.

Health checks should probe something representative enough to catch broken instances, but cheap enough not to become load themselves. Removing a backend from rotation is what gives HTTP services graceful failure handling during deploys and incidents.

L4 load balancers see TCP/UDP metadata only and balance transport connections without parsing HTTP. L7 load balancers understand HTTP details such as host, path, and headers, which enables smarter routing at the cost of more work per request.

Server creates a session, sends an opaque id via Set-Cookie, browser resends it automatically. Simple, but requires server-side session storage (or a signed token).

The client sends Authorization: Bearer <token> on each request. That token is often a signed JWT the server can verify without consulting a session store, but revocation, rotation, and token size become important trade-offs.

A delegated-authorization protocol — lets a user grant a third-party app limited access to their account on another service (e.g., "Sign in with Google") without sharing their password.

Whitelists where scripts, styles, and other resources may load from — a strong defense-in-depth layer against XSS, alongside output encoding.

Tells the browser to never connect over plain HTTP again for this domain for the max-age period, even if the user types http:// — closes the window for SSL-stripping attacks after the first visit (preloading closes the first-visit gap too).

Stops the browser from guessing ("sniffing") a different content type than the server declared — prevents a crafted upload from being executed as script.

Prevents the page from being embedded in an <iframe> on another site. CSP frame-ancestors is the modern control and X-Frame-Options its older equivalent; together they are the primary defense against clickjacking.

Latency (how long requests take), traffic (requests/sec), errors (4xx/5xx rate), saturation (how close to capacity). Almost every dashboard for an HTTP service should surface these four first.

Every request logged with method, path, status, duration, and a trace id — the raw material for debugging any single incident after the fact.

A single user request often fans out across a load balancer, several services, and a database. Trace ids propagated via headers (e.g., traceparent) let you reconstruct the full path of one request across every hop.

The app server or database driver runs out of available connections under load, and every new request queues or fails — often masquerading as generic timeouts.

A popular cache key expires and hundreds of simultaneous requests all miss at once, hammering the origin. Fixed with jittered TTLs or a request-coalescing lock ("only one request refetches, others wait").

Clients retrying failed requests without backoff can turn a brief blip into a sustained outage — the retries themselves become the overload. Exponential backoff with jitter is strongly recommended for any automated retry logic.

Shows the full request and response headers, TLS handshake details, and timing — the fastest way to see exactly what's on the wire without a browser in the way.

Browser devtools split every request into DNS, connect, TLS, TTFB (time to first byte), and download — each phase points to a different class of problem (DNS → resolver issues, TTFB → slow backend).

When a request fails, the single most useful thing a server can return is a request/trace id in the error response — lets you find the exact server-side log line without guessing by timestamp.