The Life of a Request

A URL looks like a location. It is closer to a set of instructions addressed to different actors, most of which never see the whole string. Take the URL this course traces from end to end: https://app.cellarbook.com:443/cellar?sort=vintage#reds — the address of the cellar page in Cellarbook, the wine-collection product whose API is designed in Guide Nº 07.

Pressing Enter starts a fixed sequence. Resolve: turn app.cellarbook.com into an IP address. Connect: open a TCP (or QUIC) connection to that address. Secure: run the TLS handshake so the bytes are confidential and the server is who it claims. Request: send the method line and headers. Respond: the server — or a cache in front of it — produces a status line, headers, and a body. Render: the browser parses, discovers subresources, and starts the whole sequence again for each of them. The seventh stage is the one nobody counts: reuse — every subsequent request on that connection skips stages one through three entirely, which is why the second page load feels like a different product.

The request you write is not the thing that travels. Each layer takes the layer above as an opaque payload, wraps it in its own header, and hands it down — encapsulation. The value of knowing this is not trivia; it is triage. Each layer makes exactly one promise, so when a promise breaks you know which layer to interrogate first.

Read the diagram as a diagnostic instrument. "The page loaded but the data was wrong" is above HTTP — application logic. "The connection dropped halfway through the download" is TCP or something along the path terminating it. "The browser says the certificate is not trusted" is TLS, and specifically its identity promise. "The name doesn't resolve at all" is beneath everything here: no address means IP never got a destination.

Here is the trace this entire course returns to. From an office network in San Francisco, cold — no DNS cache, no open connection, no HTTP cache — the request curl -v https://app.cellarbook.com/cellar takes about 221 ms to first rendered byte. Cellarbook is served by a CDN edge 18 ms away; the origin sits in us-east-1, 53 ms behind the edge (106 ms round trip; the client is 9 ms from the edge each way).

Notice what is not on this chart: bandwidth. Fourteen kilobytes of compressed HTML takes 11 ms; on a connection twice as fast it would take 6 ms, buying you a 2% improvement. The costs that matter are round-trip time multiples — DNS needed a walk, TCP needed a round trip, TLS needed another — and TTFB, which is where somebody else's work hides. This is the single most useful reframing in the course: web latency is a count of round trips, plus how long the far end thought about it.

Every later module owns a span of Figure 1.3. Module 2 dissects the 28 ms of DNS and the caches that usually make it zero. Module 3 owns the 41 ms of handshaking and the question of what the padlock actually proved. Module 4 opens the request and response that were sent across the connection. Module 5 explains why the second request still knows who you are. Module 6 attacks the 141 ms directly — that span exists only because a cache said no. Module 7 asks what changes when the same semantics ride HTTP/1.1, HTTP/2, or HTTP/3. Module 8 names the machines between you and the origin, which the timeline politely hides. Module 9 hands you the instruments and returns to this exact trace, now readable line by line.

One discipline runs through all of them, and it is worth stating before you need it. When application logs and the wire disagree, the wire wins. Logs record what your code believed happened — they are written by the same process whose assumptions may be wrong, and they are silent about everything that failed before reaching it. A request rejected by a load balancer, blocked by a CORS preflight, withheld by a cookie policy, or answered from a CDN cache leaves no trace in your origin logs at all. Absence of a log line is not evidence that nothing happened; it is evidence that nothing reached you.

DNS is a delegation hierarchy, not a database. The root servers do not know where app.cellarbook.com lives; they know who is responsible for .com. The .com servers do not know either; they know which nameservers are responsible for cellarbook.com. Only those authoritative nameservers hold the actual records. Every lookup is a walk down that chain of referrals, and every referral is itself a record.

Four record types cover almost all web practice. An A record maps a name to an IPv4 address, an AAAA record to IPv6 — these are the answers everything else exists to produce. A CNAME is an alias: it says "this name is really that name, start over there," which is how a product hostname points at a CDN's hostname without hard-coding the CDN's addresses. An NS record delegates a zone to a set of nameservers, forming the edges of the tree. (MX for mail and TXT for verification records round out the working set; neither affects a page load.)

The 28 ms in Figure 1.3 is the worst case: nothing cached anywhere. In practice a lookup is a cascade of cache checks that usually stops early. The browser keeps its own short-lived DNS cache; the operating system keeps another; the recursive resolver — your ISP's, your corporate network's, or a public one like 1.1.1.1 — keeps the big one, shared by everyone using it. Only when all three miss does anyone talk to the root.

Two consequences follow immediately. First, the recursive resolver is a shared cache, which means your cold lookup is often warm because a stranger on the same network asked first — and conversely, one resolver holding a stale record affects everyone behind it. Second, the record with the shortest TTL in the chain governs how quickly the answer can change. Here the CNAME is cached for 300 s but the address behind it for only 60 s, which is deliberate: the CDN wants the freedom to move traffic between edges within a minute.

Nothing propagates. When you change a record, the authoritative server begins answering differently immediately; every other machine keeps its cached copy until the copy's countdown reaches zero and then asks again. There is no push, no gossip, no wave sweeping the internet. "DNS is still propagating" always translates to "caches populated before my change are still serving their old answer for up to the old TTL."

That sentence contains the whole method: the wait is governed by the TTL that was in effect when the old answer was cached, not the new one. Lowering the TTL at the moment of the change accomplishes nothing for clients that already cached the old value at 86400. This is why a competent cutover is planned backwards: lower the TTL at least one old-TTL period in advance, wait, then change the record, and now your exposure is the new, short TTL.

The Cellarbook edge answers from 151.101.65.140 for every client on earth, and yet the client in San Francisco reaches a machine 18 ms away rather than one in Frankfurt. That is anycast: the same address is announced to the internet's routing system from dozens of locations, and each network simply delivers packets to whichever announcement is closest by its own routing metrics. The steering happens at the routing layer, invisibly, after DNS has finished.

The commonly stated version — "DNS returns the nearest server" — describes a different mechanism, GeoDNS, in which the authoritative nameserver inspects the resolver's location and returns different addresses to different askers. Both exist and are often combined, but they fail differently and are debugged differently.

That last row is the practical trap in GeoDNS: the authoritative server sees the resolver's address, not the user's. A user in Denver on a public resolver whose nearest node is in Dallas gets a Dallas-optimized answer. Extensions exist to pass a truncated client subnet along, but support is uneven — which is one reason large CDNs prefer anycast, where being wrong about the user's location is impossible by construction.

TCP's job is to turn IP's best-effort packet delivery into a reliable, ordered byte stream. Before it can do that, both endpoints must agree that they can hear each other and settle on the sequence numbers they will use to detect loss and reordering. That agreement is the three-way handshake: the client sends SYN with its initial sequence number, the server replies SYN-ACK acknowledging it and offering its own, the client sends ACK. Three packets, one and a half round trips — but only the first full round trip blocks the application, because the client can attach data to that final ACK's flight.

So a connection to the Cellarbook edge, 18 ms away, costs about one RTT: the observed 19 ms is that RTT plus scheduling jitter. Nothing about this scales with bandwidth. A gigabit link and a DSL line 18 ms away pay the same 19 ms, which is the first concrete instance of the module 1 rule that latency is a count of round trips.

With a byte stream established, TLS negotiates the keys. TLS 1.3 — the version you should assume in 2026 — is dramatically simpler than 1.2, and the simplification is structural rather than cosmetic. In 1.2, the client offered ciphers, the server chose one and sent its certificate, and only then did the two exchange key material: two full round trips. In 1.3 the client guesses the group the server will pick and sends its key share in the first message. The server replies with its own share, its certificate, and a Finished message — and from that point on the handshake itself is encrypted. One round trip, and the observed 22 ms is that RTT plus the elliptic-curve arithmetic on both ends.

Two other things happen in the same flight, and both matter to this course. The client sends SNI — the hostname it wants — in the clear, because the server needs to know which certificate to present before any keys exist. And the two sides negotiate the application protocol through ALPN, which is how the Cellarbook trace ends up on h2: the browser offered h2 and http/1.1, the edge picked h2, and that choice is made here, inside TLS, before HTTP speaks at all.

TLS 1.3 also offers 0-RTT resumption: on a repeat visit, the client can send application data alongside its very first packet, using keys derived from the previous session. It is genuinely free latency and it has a sharp edge. Those early-data bytes carry no proof of freshness, so an attacker who captured them can send them again and the server will accept them. That is harmless for GET /cellar and dangerous for anything that changes state — which is why the rule is simply: 0-RTT for idempotent requests only, enforced at the server, never left to client good behavior.

The handshake proves the server holds the private key matching the certificate it presented. That is a statement about keys, not about identity — the identity part comes from the signature chain. The leaf certificate for app.cellarbook.com is signed by an intermediate CA, which is signed by a root CA whose certificate already sits in your device's trust store because your operating system or browser vendor put it there. Chain of trust is exactly that recursion, anchored in a decision someone else made about which roots deserve trust.

Two operational notes fall out of the diagram. The server must send the intermediate certificate along with its leaf, because clients only hold roots; an incomplete chain is the classic "works in my browser, fails in curl and on Android" defect, since desktop browsers often cache intermediates from previous sites and mask the misconfiguration. And validity windows are now short — ninety days is typical — which makes renewal automation an availability concern rather than a calendar entry.

TLS gives you three things for one hop: confidentiality (an observer cannot read the bytes), integrity (an observer cannot alter them undetected), and server authentication (the far end holds the key for the name you asked for). Every word of that is load-bearing, and the phrase doing the most work is for one hop.

What still leaks even on the protected hop: the destination IP address, the SNI hostname sent in the clear, the DNS query that preceded it, and the size and timing of everything you send. An observer on the office network cannot read your Cellarbook password, but knows precisely that you visited app.cellarbook.com, when, and roughly how much you did there. What does not leak: the path, the headers, the cookies, and the bodies.

Two mechanisms patch known holes. HSTS — strict-transport-security: max-age=31536000; includeSubDomains, present in the Cellarbook response — instructs the browser to refuse plaintext HTTP for this host for a year, closing the window where a user typing the bare hostname makes one downgradeable request. Mixed content rules close the other direction: a page loaded over HTTPS that pulls a script over HTTP would let an attacker rewrite the script and own the page, so browsers simply block it.

Everything above treats TCP and TLS as separate layers that each need a handshake — which is exactly the assumption QUIC discards. QUIC implements reliability, ordering, congestion control, and encryption as one protocol, in userspace, on top of UDP. UDP here is not a claim about reliability; it is a delivery substrate chosen because it is the only thing middleboxes will pass without interference. Reliability is reimplemented above it, per stream.

Three consequences matter. One round trip to first byte, because there is no separate transport handshake to complete before the crypto one starts — the third panel of Figure 3.1. Independent streams: TCP delivers one ordered byte stream, so a lost segment stalls everything behind it; QUIC's streams have separate delivery guarantees, so loss stalls only the stream that lost a packet. That distinction is the whole subject of module 7. Connection IDs: a QUIC connection is identified by an ID rather than by the four-tuple of addresses and ports, so when a phone moves from Wi-Fi to cellular and its IP address changes, the connection survives instead of being torn down and rebuilt.

Because QUIC is implemented in userspace and its transport headers are encrypted, it also escapes a structural problem TCP has: middleboxes cannot inspect or "optimize" what they cannot parse, so QUIC can evolve without waiting for every firewall vendor on earth. That is a deployment argument rather than a performance one, and it is arguably the more important of the two.

Here is the Cellarbook cold request and its response, as they appear on the wire. The format is the same in both directions: a first line that differs, then headers as name: value pairs, then one blank line, then the body if there is one. That blank line is doing real work — it is how a parser knows the headers ended and the body began.

Two details in that transcript are easy to skim past. Header names are case-insensitive, and HTTP/2 requires them lowercase on the wire — so the lowercase rendering above is literal, not a stylistic choice. And host is what makes virtual hosting possible: thousands of sites share one IP address at a CDN edge, and the only thing telling the edge which site you want is that header (plus SNI, which had to say the same thing one layer down).

A method is a promise about consequences, and infrastructure you do not own acts on that promise. A safe method — GET, HEAD, OPTIONS — asserts no meaningful side effects, which is why a browser prefetcher, a link scanner, a crawler, or an antivirus proxy will happily issue one without asking anybody. An idempotent method — the safe ones plus PUT and DELETE — asserts that repeating it leaves the same state as doing it once, which is what makes automatic retries legal.

The consequences of getting this wrong are unusually severe because they are invisible in development. A team that implements "delete this row" behind GET has built something that a link prefetcher can trigger, that a browser may repeat on back-navigation, and that any cache may serve or replay. The classic version of this story is an admin panel whose delete links were plain GETs, emptied one weekend by a well-behaved crawler doing exactly what GET's contract permits.

You do not need to memorize status codes. You need the first digit, which assigns fault and therefore the next action, plus roughly fifteen specific codes that carry extra instructions.

The most expensive misreadings in practice are these. Retrying 4xx: a 4xx says the request as formulated is wrong, so sending it again unchanged can only produce the same answer — usually seen as a batch job hammering a 422 for hours. Not retrying 5xx: a single 503 on an idempotent PUT is exactly what a bounded backoff exists for, and giving up immediately converts a transient blip into an incident. Confusing 401 and 403: 401 means "I do not know who you are — authenticate and try again," so a client may sensibly refresh a token and retry; 403 means "I know exactly who you are and you may not," where retrying is pointless and the correct response is a permissions message, not a login prompt.

There are hundreds of headers and about a dozen you will use constantly. Three groups do most of the work.

Representation and negotiation. The client says what it can handle — accept: text/html,application/xhtml+xml, accept-encoding: gzip, br, accept-language: en-US — and the server states what it actually chose: content-type: text/html; charset=utf-8, content-encoding: br. This is content negotiation, and the discipline is that representation is agreed, never assumed. The Cellarbook HTML is 14 KB on the wire because brotli compressed roughly 62 KB of markup; the server chose brotli only because the client advertised it. Note the layering: content-type describes what the bytes are, content-encoding describes how they were packed, and a client that ignores the second will faithfully render compressed garbage.

Framing. The receiver must know where the body ends. Either the sender knows the length up front and sends content-length: 14204, or it does not and uses chunked transfer — each chunk prefixed by its size in hex, terminated by a zero-length chunk. Chunked is what makes streaming a response possible before you know its total size. (HTTP/2 and HTTP/3 replace this framing with their own length-delimited frames, so transfer-encoding: chunked does not appear there at all — a small example of how the message model outlives its serialization.)

Identity and control. host selects the site; authorization carries credentials; cookie and set-cookie carry state (module 5); location names the target of a redirect or the URL of a created resource; retry-after converts a 429 or 503 from a guess into an instruction; user-agent is a client's self-description, useful for diagnostics and unreliable for decisions.

HTTP's rule is that each request must carry everything the server needs to process it. No conversational context, no session on the connection, no memory of the last request. That sounds like a limitation and is actually the property everything else stands on: if any request can be answered by any server, then load balancers can distribute freely, instances can be replaced mid-deploy, and horizontal scaling requires no coordination at all.

The anti-pattern that gives this away is sticky sessions — configuring the load balancer to pin each user to the instance that first served them, so that instance's in-memory session data remains reachable. It works, right up until it does not: a deploy that replaces instances logs those users out, an autoscaler scaling in logs them out, an instance failure logs them out, and traffic distribution skews toward whichever instances happen to hold long-lived users. Every one of those symptoms is the same root cause — state that belongs in a shared store was left in one process's memory, and the load balancer was asked to compensate.

A cookie is a key-value pair the server writes into the browser's store, which the browser then attaches to future requests that match the cookie's scope. The write is a set-cookie response header; the read is a cookie request header the browser assembles automatically. That automatic attachment is both the mechanism's convenience and the source of its entire attack surface — the browser sends the cookie because the destination matches, not because your code decided to.

Here is the real Cellarbook session cookie, issued by POST https://api.cellarbook.com/v1/sessions:

set-cookie: cb_session=9f31c2ae...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1209600

Read it as a control list. Secure — never send this over plaintext HTTP, which removes network capture of the session identifier. HttpOnly — hide it from document.cookie, so a cross-site scripting flaw that can run JavaScript still cannot read and exfiltrate the session. SameSite=Lax — withhold this cookie from cross-site subrequests, which is the structural defense against cross-site request forgery. Path=/ and the absent Domain attribute — scope it to this host only, so it is not shared with sibling subdomains that may be less carefully operated. Max-Age=1209600 — fourteen days, after which the browser deletes it; without it the cookie is a session cookie that dies with the browser process, and with an over-long value you have created a credential that outlives most employment.

Two designs dominate, and the choice between them is not a matter of fashion. A session cookie is a claim check: the cookie carries an opaque identifier, the truth lives in a server-side store, and every request costs a lookup. A bearer token — a signed JWT, typically — is a notarized document: the claims travel inside the token, the server verifies a signature and needs no lookup at all.

State that trade honestly and the decision usually makes itself. If the product must be able to kill a credential today — an employee offboarded, a device lost, a token leaked in a support ticket — the session design gives you that for the price of a lookup you were probably making anyway. If you are authenticating machine-to-machine traffic across services that must not share a datastore, short-lived tokens with a five-minute expiry give you an acceptable revocation window without the denylist.

Here is the bug in full, because it is the most instructive twenty minutes most engineers will ever lose. In production, Cellarbook's frontend at app.cellarbook.com and API at api.cellarbook.com share the registrable domain cellarbook.com, so requests between them are same-site and everything works. A developer runs the React frontend locally at http://localhost:5173 against the production API. Login appears to succeed — the network panel shows 201 with the set-cookie header right there, and the cookie is visible in the Application tab. Every subsequent request returns 401. The same request from curl with -b cb_session=… works perfectly.

The evidence points at exactly one thing: the cookie exists and is not being sent. localhost and cellarbook.com are different sites, so a fetch() from the local page to the API is a cross-site subrequest, and SameSite=Lax withholds cookies from precisely those. The credentials: "include" option does not override this — it is the developer's request to send credentials, not the browser's permission to.

The fixes, ranked. Best: make the local frontend same-site — run it behind a dev proxy at app.localtest.me pointed at a local API, or proxy /v1 through the dev server so the browser sees one origin. Acceptable: point local development at a local or staging API rather than production, which is a better idea for several unrelated reasons. Last resort, with eyes open: SameSite=None; Secure on a development-only cookie, never in production, because it disables the CSRF defense entirely and hands you the obligation to replace it with anti-CSRF tokens.

A cache holding a copy of a response asks two questions in order. First: may I use this without asking anyone? That is freshness, and it is answered locally from cache-control: max-age — if the response is younger than its stated lifetime, the cache serves it and no packet leaves the machine. If the answer is no, the second question: may I keep using it? That is validation, and it costs a network round trip — the cache sends a conditional request carrying the copy's fingerprint, and the server answers 304 Not Modified if the copy is still correct.

The economics differ sharply and that difference drives every policy decision. A fresh hit saves the entire round trip: zero milliseconds, zero bytes. A successful validation saves only the body — you still pay the full latency of asking, which on the Cellarbook trace is at least 18 ms to the edge and up to 141 ms if the question travels to the origin. Freshness versus validation is therefore not two flavors of the same thing: freshness is free, validation is cheap, and only one of them removes the network from the picture.

Cache-Control is the contract, and about eight directives cover practice. They fall into three groups: how long, who may store it, and what to do at the boundary.

The one that causes the most confusion is no-cache, and the confusion is the name's fault. It does not mean "do not cache." It means "cache this, and revalidate it with the origin before every use" — which is exactly what the Cellarbook HTML uses, paired with an etag, so the browser holds a copy and asks a cheap question rather than downloading 14 KB again. The directive that actually means do not keep a copy is no-store, and it is the correct choice for a page containing another person's data.

An ETag is a fingerprint of a specific representation — the Cellarbook HTML carries etag: "8f2c-1a9d". When the browser's copy goes stale, it does not download blindly; it asks a question that includes the fingerprint:

GET /cellar HTTP/2
host: app.cellarbook.com
if-none-match: "8f2c-1a9d"

HTTP/2 304
etag: "8f2c-1a9d"
cache-control: no-cache

A 304 Not Modified has no body. The client already has the bytes; the server is confirming they are still correct and resetting the freshness clock. For the Cellarbook HTML this turns a 14 KB transfer into roughly 200 bytes, and — critically — leaves the render path unblocked at whatever the round-trip cost was rather than the round trip plus download.

One subtlety worth carrying: ETags identify a representation, not a resource. The brotli-compressed and uncompressed versions of the Cellarbook HTML are different representations and must carry different ETags, or a cache will confidently answer 304 to a client asking about a copy it never had. This is the same fact that Vary exists to express, from the other direction.

A cache stores responses under a key. By default the key is the method plus the URL — which is wrong the moment the server's answer depends on anything else about the request. Vary is how the response says so: vary: accept-encoding on the Cellarbook HTML tells every cache that the request's accept-encoding header is part of the identity of this response, so brotli and non-brotli copies are stored separately.

Omit it and the failure is immediate and absurd: the first client to ask advertises brotli, the edge stores the compressed bytes under the plain URL, and the next client — a monitoring agent, an older library, a server-side integration that never sent accept-encoding — receives brotli-compressed bytes it does not know to decompress and reports the page as corrupt.

The dangerous direction is the same mechanism applied to identity. If a response depends on the authorization or cookie header and is stored in a shared cache under a key that ignores them, the cache will serve the first user's response to everybody. The correct handling is almost never vary: cookie — that produces a cache key so wide it never hits — but private or no-store, which keep per-user responses out of shared tiers entirely.

The same directives are obeyed by every tier, and the tiers differ only in who they serve. The browser cache is private to one person. The CDN edge is a shared cache serving everyone in a region. The origin sits behind both. A request walks down until someone can answer it.

Two practical consequences complete the picture. Purge does not reach the browser. You can invalidate the edge in seconds; you cannot recall a max-age a browser is already honoring, because a fresh copy is served with no network contact at all. That is why versioned filenames — /assets/app.3f9c1b.js, cached public, max-age=31536000, immutable — are the real invalidation strategy: a deploy changes the hash, which changes the URL, which is a different cache entry, and nothing needs invalidating. The HTML is the pivot. Because the HTML names those hashed assets, it must be current — no-cache with an ETag — so a deploy propagates on the next navigation and self-heals.

HTTP/1.0 opened a connection per request, which meant paying the handshake — 41 ms, in this course's trace — for every image on the page. HTTP/1.1 fixed that with persistent connections: keep the connection open and send the next request on it. But the protocol still requires responses to come back in order, one at a time per connection. If the first response is slow, everything queued behind it waits, no matter how ready those responses are.

That is head-of-line blocking at the HTTP layer, and browsers worked around it the only way available: open more connections — six per hostname, by convention. Six lanes, each still single-file. From that constraint came an entire generation of techniques: domain sharding (spread assets over img1.example.com, img2… to get 6 more connections each), sprite sheets (glue twenty icons into one image to make one request), inlining small files into the HTML, and concatenating all JavaScript into one bundle. Every one of these traded cache granularity and complexity for fewer requests, and every one was rational under HTTP/1.1.

HTTP/2 keeps every semantic from module 4 and replaces the serialization. Messages become frames tagged with a stream identifier, and frames from many streams interleave freely on one connection. Thirty requests can be in flight simultaneously over a single TCP connection, in any order, with responses arriving as they become ready. Headers are compressed with a shared dynamic table (HPACK), which matters more than it sounds: the repetitive kilobyte of cookies and user-agent strings on every request compresses to a handful of bytes.

Crucially, the connection underneath is still TCP, which delivers one ordered byte stream. If a single segment is lost, the kernel holds back every subsequent byte until the retransmission arrives — including bytes belonging to entirely unrelated streams that arrived intact. Head-of-line blocking did not die; it moved down one layer, from HTTP to TCP. On a clean network you never notice. On a lossy mobile connection, one connection carrying thirty multiplexed streams can stall all thirty on one lost packet, which is why HTTP/2's benefit is smallest exactly where you most want it.

HTTP/3 is HTTP/2's model carried by QUIC instead of TCP, and the single change that matters is that QUIC's streams are independent at the transport. A lost packet stalls delivery only on the stream whose bytes it carried; every other stream keeps flowing. That is the fix TCP structurally could not deliver, because TCP's contract is a single ordered stream.

Two further QUIC properties from module 3 pay off here. The handshake is one round trip instead of two, worth 21 ms on this trace. And connections are identified by a connection ID rather than by addresses and ports, so a phone switching from Wi-Fi to cellular keeps its connection instead of rebuilding it — a mid-page-load network change that used to be a visible stall becomes invisible.

Here is the whole practical payload of this module.

On HTTP/1.1: minimize request count. The old playbook is correct here because its assumptions hold — each request may cost a connection, and the connection budget is six per host.

On HTTP/2: undo the workarounds. Domain sharding now actively hurts: each extra hostname forces a separate connection with its own handshake, its own congestion-control state, and its own prioritization scope — you have manually recreated the problem multiplexing solved. Sprite sheets and mega-bundles hurt for a different reason: they destroy cache granularity, so a one-line change to one component invalidates a megabyte for every user. Split bundles along change-frequency lines instead. What you keep, without exception: compression, caching, and reducing payload size, because HTTP/2 does nothing about bytes or server think time.

On HTTP/3: for most teams this is a CDN toggle. Your origin can keep speaking HTTP/1.1 to the edge while the edge speaks h3 to browsers. The one thing worth understanding is discovery: a browser cannot know an origin speaks h3 before connecting, so it connects over h2 and receives alt-svc: h3=":443", which it remembers and uses on the next connection. That is why your own first test always shows h2, and why concluding "h3 is not enabled" from one page load is wrong.

Three shapes cover almost everything. A forward proxy acts on behalf of clients — a corporate egress gateway, a filtering proxy — and the servers it contacts see the proxy, not the user. A reverse proxy acts on behalf of servers: it terminates the client's connection and forwards inward, which is the pattern behind CDNs, TLS terminators, API gateways, and nginx in front of an application. A load balancer distributes work across instances, at layer 4 (routing whole connections by address and port, blind to their contents) or layer 7 (parsing each HTTP request and routing on path, host, or header).

The distinction that matters is not the label but this: any box that terminates TLS is a party to the conversation, not a pipe. It sees the plaintext, it may modify headers, it decides what to forward, and its own failures appear to your users as your failures. A 502 is that machine telling you it could not get an answer from something behind it — which is why, as module 1 argued, the absence of a matching origin log entry is expected rather than mysterious.

Once a request has been through a terminating hop, your application's notion of "the client address" is the hop's address. The convention that repairs this is X-Forwarded-For: each proxy appends the address it received the request from, building a left-to-right chain of the path so far. (The standardized Forwarded header does the same job with better syntax and less adoption.)

The chain is append-only and completely unauthenticated, which produces the trap. A client can simply send its own x-forwarded-for header, and every proxy in the path will dutifully append to it. Everything to the left of the entry your own edge wrote arrived attacker-controlled.

The failure is quiet, and its consequences are the security controls people care about most. A rate limiter keyed on the leftmost entry can be defeated by rotating a fake value on every request — the attacker is never limited, while a legitimate user unlucky enough to share a spoofed value is. An IP allowlist keyed the same way is bypassable by anyone who reads its documentation. And audit logs recording the leftmost entry contain attacker-chosen strings presented as fact.

HTTP's model is that the client asks and the server answers. Some products need the reverse — the server knows something and wants the client to have it now. Four patterns solve this, and they form a ladder of increasing capability and decreasing friendliness to the infrastructure above.

Polling is a loop of ordinary requests. It is trivially compatible with every cache, proxy, and load balancer you own, and it is wasteful in exact proportion to how rarely anything happens. Long polling sends a request the server holds open until it has news, then answers and the client immediately asks again — correct and timely, at the cost of a parked connection per client. SSE holds one HTTP response open forever and writes data: lines into it as events occur; it is still HTTP — ordinary status codes, headers, cookies, and authentication apply — and the browser's EventSource reconnects automatically, including resuming from the last event ID. WebSocket starts as an HTTP Upgrade request and then abandons HTTP: a raw bidirectional frame channel where you build your own message semantics, your own reconnection, and your own authentication story after the handshake.

Three questions settle it: which direction does data flow, how often, and what infrastructure must it survive.

That hazard deserves its own paragraph because it produces one of the most confusing bug reports in this course. A load balancer with a 60-second idle timeout closes any connection that has been silent for a minute — and an SSE stream that has no events to send is, from the load balancer's view, an idle connection. The symptom is exact: connections die at almost exactly 60 seconds, with no error on either side, and reconnect cleanly if the client is well-behaved. Anything that dies at a suspiciously round number of seconds is an idle timeout somewhere in the path until proven otherwise. The fix is a heartbeat — SSE has a comment line (: keepalive) meant for exactly this — plus raising the timeout deliberately rather than discovering it.

The verbose transcript has three prefixes and they are the whole convention: * lines are curl narrating what it did, > lines are the exact bytes it sent, < lines are the exact bytes that came back. Here is the Cellarbook cold trace, abridged only where the certificate details repeat.

$ curl -v https://app.cellarbook.com/cellar -o /dev/null

* Host app.cellarbook.com:443 was resolved.
* IPv4: 151.101.65.140
*   Trying 151.101.65.140:443...
* Connected to app.cellarbook.com (151.101.65.140) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=app.cellarbook.com
*  SSL certificate verify ok.
* using HTTP/2
> GET /cellar HTTP/2
> Host: app.cellarbook.com
> user-agent: curl/8.7.1
> accept: */*
>
< HTTP/2 200
< content-type: text/html; charset=utf-8
< cache-control: no-cache
< etag: "8f2c-1a9d"
< vary: accept-encoding
< x-cache: MISS
< strict-transport-security: max-age=31536000; includeSubDomains
<

Every module in this course is visible in those twenty lines. The resolution result is module 2. TLSv1.3, the cipher, and verify ok are module 3. The ALPN negotiation landing on h2 is module 7 — and note that it happened inside the TLS handshake, before HTTP existed. The request and response headers are module 4. cache-control, etag, vary, and x-cache: MISS are module 6, and that last one explains the 141 ms. Note also what is missing: no content-encoding, because bare curl advertises no accept-encoding — add --compressed and the response changes, which is module 4's negotiation demonstrated rather than described.

The working kit is small. -i shows response headers with the body; -I sends HEAD for headers alone; -L follows redirects; -H adds a header; -b sends cookies; --compressed requests compression; --resolve app.cellarbook.com:443:203.0.113.99 pins a hostname to an address so you can test a new origin before DNS moves; and -w prints timing variables that decompose latency exactly along this course's module boundaries.

$ curl -s -o /dev/null -w "dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" https://app.cellarbook.com/cellar

dns 0.028  tcp 0.047  tls 0.069  ttfb 0.210  total 0.221

Those five numbers are Figure 1.3, measured. They are cumulative, so each span is a subtraction: DNS 28 ms, connect 19, TLS 22, waiting 141, download 11.

The browser's Network panel is the same information with two additions curl cannot give you: everything the page requested, and how those requests contended with each other. Each row's timing bar decomposes into spans that map one-to-one onto this course.

Three habits make the panel trustworthy. Preserve log, so a redirect or a page navigation does not erase the evidence you were about to read — without it, the most interesting request in a login flow vanishes at the moment it matters. Disable cache, so you are measuring cold behavior deliberately rather than accidentally; then turn it off again to measure the warm path, since both numbers are real and describe different users. And Copy as cURL, which is the bridge: right-click any request and you have a shell command reproducing it exactly, headers and cookies included, outside the browser.

Triage is a lookup table plus one command per row. The point is not the table's contents but its shape: each symptom belongs to one layer, and that layer has one instrument.

Run that bottom branch on the module 5 bug and watch the method work. The browser sends the request and gets a 401; curl with -b cb_session=… gets a 200. Copy as cURL from the browser, and the copied command also succeeds — which is the decisive observation, because the copied command includes every header the browser sent. If the reproduction with the browser's own headers works and the browser does not, the browser withheld something. Diff the two commands: the working one has a cookie header, the copied one does not. The cookie was never sent, which is SameSite=Lax doing exactly its job. Total elapsed: about four minutes, none of it spent in application code.

Three rules turn the instruments into a method.

Reproduce at the lowest layer that still shows the symptom. If it reproduces in curl, stop using the browser — you have removed cookies, CORS, extensions, service workers, and rendering from the problem. If it reproduces with --resolve pinned to a specific origin address, you have removed DNS and load balancing. Each layer you remove is a hypothesis eliminated, and the layer where reproduction finally fails is where the cause lives.

Keep the evidence. Export the HAR before closing the tab; paste the curl transcript into the incident channel rather than describing it. Wire evidence has a property application logs lack: it is complete and it is not shaped by what your code expected. A HAR from the affected user's session settles arguments that three engineers' recollections cannot.

When logs and the wire disagree, the wire wins. This is where module 1's framing pays off. Application logs are testimony — a participant's account, recorded by the same code whose assumptions may be the bug, and silent about everything that never reached it. A HAR export or a curl transcript is documentary evidence of what actually crossed the network. You would not resolve a factual dispute on recollection when the contemporaneous document is available; the same hierarchy applies here, and it is why "there's nothing in the logs" is the beginning of an investigation rather than the end of one.