How CDNs work: distance is latency you can't optimise away
A CDN is not a faster server. It's a copy of your response nearer the person asking — and everything that surprises you about it follows from what HTTP lets a shared cache keep.
The engineering questions you get asked, and the bugs you actually hit. Drawn, one mechanism at a time, in the order the videos ship.
A CDN is not a faster server. It's a copy of your response nearer the person asking — and everything that surprises you about it follows from what HTTP lets a shared cache keep.
The padlock proves the line is private and the name is real, and has never had an opinion about whether the site is honest — which is why a phishing page gets exactly the same one.
Three messages before a byte moves, an ACK that isn't a receipt, and the half a ninety-second video has to cut: how fast to send, how much to hold, and where QUIC takes the whole job away.
Four servers, three of which have never heard of the name you asked for, and a cache so you never do it twice — the referral chain in real dig output, plus the CNAME rule that breaks your apex.
Five negotiations run between Enter and the first pixel, and the one nearly every answer skips is that an address and a connection are different things.
A bearer token can't be recalled, so the only way to bound the damage is to bound the time. Everything else — the split, the 401, the rotation — falls out of that one sentence.
Three parties, one redirect, and a code traded for a token. The whole protocol is visible in your address bar, and nobody ever tells you to look.
Three attributes decide whether your cookie is sent at all. Here's what each one does, and why yours is missing.
One is a pointer, the other is a copy. Almost every argument about them comes from missing that one line.
Not the definition. The four things you actually send, what each one is for, and how to find the one that's wrong.