A 36-minute working session on what really happens when you click a link — the layers, IP and TCP vs UDP, DNS, TLS, the HTTP versions, the boxes in the middle (load balancers, proxies, CDNs), and the tools to debug it all when it breaks.
Nobody designed the internet as one giant program. It is a stack of layers, each solving one job and handing the rest down. Your app says "send this text"; it never worries about voltage on a cable. Understanding the stack is the single best map for debugging: when something breaks, you can ask which layer.
You may also hear of the OSI 7-layer model— an older teaching diagram. People still say "a Layer 4 load balancer" (transport) or "Layer 7" (application); those numbers come from OSI.
To send, your data travels down the stack; on the other machine it travels back up.
Encapsulation: each layer wraps the one above in its own header — like putting a letter in an envelope, in a mailbag, on a truck.
Like mailing a parcel: you write the note, the courier adds a shipping label, the depot adds a route — each layer trusts the one below to deliver.
An IP address is like a building's street address; a port is the apartment number inside it. Together they pinpoint one running program. On top of that, you pick a transport: TCP when every byte must arrive in order, UDP when speed beats perfection.
93.184.216.34 (about 4.3 billion possible — now scarce, so we share them with NAT). IPv6 looks like 2606:2800:220:1::1 and has effectively unlimited room. A port is a number from 0 to 65535 that says which program on the machine should get the data.HTTP — plain web traffic.
HTTPS — encrypted web traffic.
DNS — name lookups.
SSH — remote shell.
Before any data flows, TCP does a three-way handshake to agree to talk. Then it numbers every chunk, waits for acknowledgements, re-sends anything lost, and slows down when the network is congested — so your bytes arrive complete and in order.
Three messages set up the connection — one full round trip before the first byte of real data.
Rule of thumb: choose TCP when missing data corrupts the result (a web page, a bank transfer). Choose UDP when stale data is worthless anyway and you would rather move on than wait (a live voice packet from two seconds ago helps no one).
You remember example.com; machines route by numbers like 93.184.216.34. DNS is the lookup service that translates one into the other — and because that lookup happens before every new connection, it is aggressively cached so it does not become the slowest step.
example.com) into the IP address a packet needs. Think of saving a contact by name in your phone: you tap "Mum", the phone dials the number. DNS does the same lookup for every domain you visit.The resolver walks the hierarchy: root → .com→ the domain's own server, then hands you the address.
1.1.1.1 / 8.8.8.8).A maps a name to an IPv4 address; AAAA to IPv6. The core lookup.
Points one name at another (www → example.com). One canonical target, many aliases.
Says which servers receive email for the domain. TXT holds free-form text (SPF, domain verification).
Time To Live, in seconds — how long a record may be cached before it must be looked up fresh.
The S in HTTPS is TLS doing three jobs at once: it encrypts the traffic so eavesdroppers see gibberish, checks integrity so nothing was tampered with in transit, and proves you are really talking to the right server and not an impostor.
TLS 1.3 sets up the secure channel in a single round trip, then every byte after is encrypted.
ECDHE) and switch to fast symmetric encryption.On open Wi-Fi, anyone can capture packets. With TLS they capture only ciphertext — useless without the key.
Each message carries a tag so any change in flight (an injected ad, a flipped bit) is detected and rejected.
The certificate proves the server owns the domain — so you are not handing your password to an impostor.
Good to know: the handshake uses slow asymmetric crypto only long enough to agree on a shared key, then switches to fast symmetric crypto for the bulk data — the best of both. Free, automated certificates (e.g. Let's Encrypt) are why HTTPS is now the default across the web.
HTTP is the language of the web — the same verbs (GET, POST) the whole way through. What changed across versions is how the bytes are carried, and each step removed a source of waiting.
One request finishes before the next starts. Browsers opened ~6 connections to fake parallelism.
Many streams share one connection (multiplexing) — but a TCP loss still stalls them all.
Streams are independent, so one loss can't block the others — and setup is a single combined handshake.
Human-readable text requests over a TCP connection that stays open (keep-alive). But a connection handles one request at a time, so a slow response blocks the queue. The workaround was opening several connections in parallel — wasteful, but it worked for two decades.
Switches to a compact binary format and multiplexes many requests as interleaved streams over a single connection, plus header compression (HPACK). The catch: everything still rides on one TCP connection, so a single lost packet stalls all streams — TCP-level head-of-line blocking.
Drops TCP for QUIC, a transport built on UDP that keeps streams independent — a lost packet only stalls its own stream. TLS 1.3 is baked in, so the transport and encryption handshakes combine into one (often a single round trip), and a connection can survive a network change (Wi-Fi → cellular) without reconnecting.
Real systems rarely have one client talking to one server. In between sit a few standard middlemen — a load balancer to spread traffic, proxies to stand in front or behind, and a CDN to serve content from near the user. Same building blocks, different jobs.
Cached static content is served at the CDN edge; everything else flows to a load balancer that spreads it across servers.
Pro — huge network, generous free tier, integrated DDoS/WAF and edge compute (Workers).
Con — opinionated platform; deep config and edge runtime have a learning curve.
Pro — programmable edge (VCL/Compute) and near-instant cache purges; loved for fine control.
Con — pricier and more hands-on; smaller free footprint, steeper for beginners.
Pro — tight integration with S3, ALB and the rest of AWS; one bill, one IAM.
Con — config is verbose; best value only if you are already all-in on AWS.
How to choose: already on AWS → CloudFront; want the most out-of-the-box security and a free start → Cloudflare; need surgical caching control and instant purges → Fastly.
The layered model pays off here: each tool inspects a specific layer. Work top-down or bottom-up, but isolate the layer first — that turns "the site is down" into a question you can actually answer.
Start here when a name won't resolve or points somewhere stale. dig shows the record, its TTL, and which server answered. nslookup is the simpler, cross-platform cousin.
The workhorse for the application layer: status codes, headers, redirects, TLS details, even the HTTP version negotiated. If dig is fine but the page is not, curl is your next stop.
Maps the route packets take and where latency or loss appears. mtrcombines traceroute with a running ping so you can spot a flaky hop over time — ideal for "slow only sometimes".
The deepest view: capture raw packets and read them. tcpdump grabs them on the command line; Wiresharkgives a rich GUI to dissect handshakes, retransmits and resets. The tool of last resort when higher-level tools can't explain it.
dig — does the domain resolve to the IP you expect?traceroute/mtr — do packets reach the host, and where do they stall?curl -v — right status, headers, certificate, HTTP version?tcpdump + Wireshark — read the packets themselves.Five quick questions on layers, transport, DNS, TLS, and the HTTP versions — instant feedback, no sign-in.
Navigate with ← → or scroll · back to library