Cookies, Sessions, Keep-Alive, Compression & Caching

In one line

HTTP itself remembers nothing between requests. Cookies and sessions add memory, keep-alive reuses connections, compression shrinks bodies, and caching headers decide who may store a response and for how long.

0/5 · 0%

Think of it like this

HTTP is a receptionist with no memory. A COOKIE is the visitor badge you're handed on the first visit and show every time after; the SESSION is the file behind the desk that the badge number points to.

Key ideas

01
COOKIES: the server sends Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600, and the browser returns Cookie: session=abc123 on later requests to that site. HttpOnly hides it from JavaScript, Secure sends it only over HTTPS, and SameSite limits cross-site sending.
02
SESSIONS: either SERVER-SIDE (the cookie holds a random ID; data lives in Redis or a database, so any app replica can serve the user, see Stateful Systems course, Unit 3.1) or CLIENT-SIDE TOKENS (a signed token such as a JWT carries the data; no shared store, but harder to revoke). Storing sessions in one pod's memory forces STICKY SESSIONS on the load balancer (Topic 5.1) and loses them on restart. Avoid it.
03
KEEP-ALIVE: HTTP/1.1 reuses a TCP connection for many requests (Connection: keep-alive is the default), avoiding a new TCP and TLS handshake each time (Phase 2). Mismatched idle timeouts between a load balancer and the app (the app closes first) cause sporadic 502s. Keep the app's keep-alive timeout LONGER than the load balancer's.
04
COMPRESSION: the client says Accept-Encoding: gzip, br; the server replies Content-Encoding: br. Text (JSON, HTML, JS) shrinks 70–90%; images and video are already compressed. Usually done by Nginx or the CDN (Topic 5.3).
05
CACHING: Cache-Control: max-age=300 lets browsers and CDNs reuse a response for 5 minutes; public/private says whether shared caches (CDN) may store it; no-store forbids storing (use for personal data); no-cache means 'revalidate first'. VALIDATORS (ETag / If-None-Match, Last-Modified / If-Modified-Since) let a client ask 'has it changed?' and get a tiny 304 Not Modified. Static assets with content hashes in their names (app.3f2a1c.js) can be cached for a year (immutable).

Code & diagrams

revalidation with ETagbash

$ curl -sI https://shop.example.com/api/catalog | grep -iE 'etag|cache-control'
etag: "5d8c72a5"
cache-control: public, max-age=60

$ curl -sI -H 'If-None-Match: "5d8c72a5"' https://shop.example.com/api/catalog | head -1
HTTP/2 304

where each piece livesdiagram

Rendering diagram…

Explain it without notes

Why are sessions stored in Redis rather than in the app's memory in a Kubernetes deployment?

What's the difference between no-cache and no-store?

Practice

After enabling a CDN, some users see other users' account pages. What went wrong and how do you fix it?

Trade-offs

↔
Server-side sessions: easy revocation and small cookies, but a shared store to run. Token sessions (JWT): stateless and scalable, but revocation and size are harder. Longer cache lifetimes cut load and latency but delay updates; use content-hashed filenames to get both.

Done when you can

Session cookies are HttpOnly, Secure, and SameSite
Sessions live in a shared store, not pod memory
Static assets use hashed names and long cache lifetimes; personal data is no-store