Express course · No. 14
Every time a page loads, machines are having a fast, precise conversation: finding each other's address, opening a line, asking a question, and sealing the answer in an envelope no one else can read. None of it is magic — it's a handful of clear ideas with intimidating names. Learn the names and the whole web becomes legible.
Essence only · One picture per idea · Learn the words
Strip away the jargon and a network is one simple thing: machines sending each other messages. Everything else is detail about how those messages find their way and stay reliable.
Computers talk by passing notes
A vast postal system: any building can send a note to any other building, as long as it writes the right address on the envelope.
A network is just computers connected so they can send each other data. The data travels in small packets — like notes broken into postcards, each labelled with where it's from and where it's going. The internet is this taken to a planetary scale: billions of machines, any of which can pass a packet to any other. That's the whole foundation; the rest is how we make it reliable and meaningful.
Every machine has an address — its IP
Every building on Earth with a unique postal address. Without one, the mail carrier has nowhere to deliver and nowhere to send a reply.
For a packet to arrive, the destination needs an address. That's an IP address — a number identifying a machine on the network, like 142.250.74.78. Every device online has one. When your laptop sends a request, it stamps its own IP as the return address so the answer knows where to come back. No address, no conversation.
Client asks, server answers
A diner and a kitchen. One side places orders; the other side prepares and sends back. The roles are fixed for the meal.
Most of the web runs on a client–server model. The client (your browser, your app) makes a request; the server (a machine running a website or service) sends back a response. Your phone is the client asking "give me this page"; a server somewhere answers with the page. Keep this pairing in mind — every idea below is about making that request-and-response work.
A network is machines passing addressed messages. The client asks, the server answers — everything else is making that reliable.
You type a name like example.com, but the network only routes to numbers. Something has to translate the name you remember into the address the machine needs. That something is DNS.
Names are for humans; numbers are for machines
You remember your friend by name, but the phone system only dials numbers — so you keep a contacts list that turns one into the other.
People remember wikipedia.org; the network needs an IP address like 198.35.26.96. A domain name is the human-friendly label; the IP is the machine-friendly address. The two have to be linked, because no one wants to memorise numbers and no router can route a name. Bridging that gap is a whole system, run constantly, invisibly, on every click.
DNS is the internet's phonebook
A giant, always-open directory: you give it a name, it hands you back the number to dial. You never see it work — you just get the number.
DNS — the Domain Name System — is the service that translates a domain name into its IP address. Before your browser can fetch example.com, it asks DNS "what's the address for this name?" and gets back a number. This lookup (or resolution) happens first, every time, in milliseconds. It's the unglamorous step that makes human-readable web addresses possible.
The answer gets cached so it's fast next time
You look up a friend's number once and jot it on a sticky note — next time you just read the note instead of opening the whole directory.
Looking up every name from scratch would be slow, so DNS answers are cached — remembered for a while by your browser, your operating system, and your network. The address comes with a TTL (time to live) saying how long it's safe to reuse before checking again. This is why a site you've visited loads its address instantly, and why a DNS change can take time to spread.
DNS is the phonebook: it turns the name you remember into the IP address the network needs, then caches it so next time is instant.
Knowing the address isn't the same as having a conversation. Before messages flow reliably, the two machines open a connection — and agree which "door" of the server to knock on.
TCP is a reliable, ordered line
A phone call with confirmations: you say a sentence, the other person says "got it," and nothing moves on until each part is acknowledged and in order.
TCP (Transmission Control Protocol) is the most common way to send data reliably. It opens a connection with a quick handshake (both sides agree to talk), then guarantees that every packet arrives, in order, with lost ones re-sent. You trade a little speed for the assurance that nothing is dropped or scrambled. The web, email, and most apps ride on TCP precisely for that reliability.
UDP trades reliability for speed
Shouting updates across a noisy room — some words get lost, but you don't stop to confirm each one, because keeping up matters more than catching every word.
UDP is the fast, no-guarantees alternative: it fires packets off without a handshake and without resending lost ones. You lose reliability but gain speed and low overhead, which is the right trade for live video, voice calls, and games — where a dropped frame is fine but waiting is not. Knowing both exist tells you the network always has this speed-versus-reliability dial.
Ports are the numbered doors on a machine
One building, many doors, each numbered for a purpose — deliveries to door 80, the office to another. Same address, different entrances.
A single machine runs many services, so an IP address alone isn't enough — you also need a port, a number picking which service to reach. Web traffic uses port 80 (HTTP) or 443 (HTTPS) by convention; a database might listen on another. The address gets you to the building; the port gets you to the right door. Together, IP plus port names an exact destination.
TCP is a reliable, ordered line; UDP is fast and lossy. The IP finds the building, the port picks the door.
Once a line is open, the two sides need a shared language for asking and answering. On the web, that language is HTTP — a simple, strict format for every request and reply.
HTTP is request and response
A formal letter exchange: a clearly structured request goes out, and a clearly structured reply comes back, each following the same agreed layout.
HTTP (HyperText Transfer Protocol) is the language of the web. The client sends a request — what it wants — and the server sends back a response — the result. Every page, image, and API call is one of these exchanges. It's text-based and structured, which is why so many tools can speak it. Master the shape of one request and response, and you understand how the whole web moves.
The method says what you want to do
At a library counter: you can borrow a book, return one, or ask to add a new one. Same counter, different intent — and the staff treat each differently.
Every request has a method — the verb. GET fetches data (load a page). POST sends new data (submit a form). PUT updates something; DELETE removes it. The method tells the server your intent at a glance, and well-behaved systems treat them differently — a GET should never change anything, while a POST is expected to. These verbs are the backbone of how APIs are designed.
Headers carry the details; the body carries the cargo
An envelope has notes on the outside — who it's for, what's inside, how to handle it — and the actual letter within.
Each request and response has headers — labelled lines of metadata like the content type, the language, who's asking, and authentication tokens — and an optional body, the actual payload (the form data going up, the page or JSON coming back). Headers are how the two sides negotiate details without touching the cargo. Most of the "how" of an exchange lives in the headers.
Status codes tell you how it went
A traffic light for replies: green means go, a redirect points elsewhere, and a red light tells you what went wrong — and whose fault it was.
Every response carries a status code. 2xx means success (200 OK). 3xx is a redirect (go look over there). 4xx means the client erred — 404 Not Found, 403 Forbidden — you asked wrong. 5xx means the server erred — 500 — it broke. Reading the first digit tells you instantly whether it worked, who's at fault, and where to look. This is the single most useful debugging skill on the web.
HTTP forgets you between requests
A counter clerk with no memory of your last visit — each time you walk up, you must re-introduce yourself and show your ticket again.
HTTP is stateless: each request stands alone, and the server remembers nothing from the last one by default. So to stay logged in, every request must carry proof of who you are — a cookie or a token in the headers. Statelessness is what lets the web scale to billions of requests, and understanding it explains why your identity rides along on every single call.
HTTP is request and response: a method for intent, headers for details, a body for cargo, and a status code that tells you exactly how it went.
Plain HTTP is a postcard — anyone handling it can read it. HTTPS is the same conversation sealed in an envelope only the right server can open, and signed so you know who you're talking to.
Encryption seals the message
Swapping a readable postcard for a locked box that only the recipient holds the key to — couriers carry it, but none of them can read what's inside.
HTTPS is HTTP wrapped in encryption using TLS. It scrambles the contents so that anyone between you and the server — your café's Wi-Fi, an internet provider, an attacker — sees only gibberish, not your password or message. The lock icon in the address bar means this seal is in place. On the modern web it's the default, because an unsealed conversation is a conversation anyone can read.
Certificates prove who you're talking to
A passport checked by a trusted authority — it proves the person is who they claim, not an impostor wearing their name.
Encryption alone isn't enough; you also need to know the server is really yourbank.com and not a fake. A certificate is a digital ID, signed by a trusted certificate authority, that proves a server owns the name it claims. Your browser checks it automatically and warns you when it's missing or wrong. This is what stops an attacker from impersonating a site even on an encrypted connection.
Why the padlock matters
The difference between mailing a sealed, verified letter and shouting your bank details across a crowded room.
Without HTTPS, anyone on the network path can read and even alter your traffic — a man-in-the-middle quietly sitting between you and the server. With it, the message is sealed and the sender verified. That's why login pages, payments, and now essentially everything use HTTPS, and why browsers flag plain HTTP as "not secure." The padlock is a small icon standing for a large guarantee.
HTTPS seals the message with encryption and proves the server's identity with a certificate — privacy and trust, in one padlock.
The web feels instant, but distance and physics are always charging a toll. Two words — latency and bandwidth — explain most of why things feel fast or slow.
Latency is the wait; bandwidth is the width
A water pipe: how long before the first drop arrives is one thing; how much can flow per second is another. A wide pipe still has a delay before water reaches the far end.
Latency is the delay before a response starts — the round-trip time for a message to go and come back. Bandwidth is how much data you can move per second. They're independent: a connection can be high-bandwidth yet high-latency. Big downloads care about bandwidth; a snappy, responsive site cares about latency. Confusing the two is why "I have fast internet but the site feels slow" puzzles people.
Every round trip costs, and distance is real
Asking a question of someone on another continent: even at the speed of light, the back-and-forth has a floor you can't beat.
A request to a faraway server makes a physical round trip, and not even light is instant across the planet — a trip across the world has a hard floor of tens of milliseconds. Worse, loading a page often needs many round trips. This is why chatty designs feel sluggish over distance, and why reducing the number of round trips is one of the oldest performance tricks there is.
Put the answer closer with a CDN
A popular book stocked in local libraries everywhere, instead of one central archive you must mail away to — the copy near you arrives far faster.
A CDN (content delivery network) is a fleet of servers spread around the world that keep copies of your content close to users. When someone in Tokyo loads your site, they're served from a nearby city, not your origin server an ocean away — cutting latency dramatically. CDNs are caching applied to geography, and they're how global sites feel local everywhere.
A load balancer spreads the work
A queue manager at a bank directing customers to whichever teller is free, so no single window is swamped while others sit idle.
When one server can't handle all the traffic, a load balancer sits in front of several and spreads requests across them. It's how big sites handle millions of users — add more servers behind the balancer — and how they survive one server failing, since the balancer just routes around it. The word describes exactly what it does: it balances the load.
Latency is the wait; bandwidth is the width. Distance always charges a toll — a CDN moves the answer closer, a load balancer spreads the work.
Now put every word together by following one click from the address bar to the rendered page. If you can narrate this, you understand how the web talks.
What happens when you load a URL
One letter's complete journey: looking up the address, opening a line, sealing the envelope, asking the question, getting the reply — all in well under a second.
You type example.com. DNS turns the name into an IP address. Your browser opens a TCP connection to that IP on port 443, and they perform a TLS handshake so the line is encrypted and the server's certificate is checked. Over that sealed line your browser sends an HTTP GET request; the server replies with a status code and a body. The page may come from a nearby CDN to cut latency. Your browser reads the response and draws the page. Every term in this course just named one step of that single, ordinary second.
- DNS resolves the domain name to an IP address. - A TCP connection opens to that IP on a port (443 for HTTPS). - A TLS handshake encrypts the line and checks the server's certificate. - The client sends an HTTP request — a method, headers, maybe a body. - The server returns a status code, headers, and a body. - A CDN may serve it from nearby; a load balancer may pick the server.
- IP address / packet — the machine's address, and the chunks data travels in. - DNS / TTL — name-to-number lookup, and how long the answer is cached. - TCP / UDP / port — reliable line, fast line, and which door on the machine. - HTTP / method / headers / body / status code — the request-response language. - HTTPS / TLS / certificate — the sealed, verified envelope.
- latency / bandwidth / CDN / load balancer — the wait, the width, and how scale fights both.
- A 404 versus a 500 tells you instantly whether you or the server is at fault. - "Fast internet but a slow site" reads as a latency, not bandwidth, problem. - The padlock means encrypted and identity-verified — you know what it guarantees. - You can explain why staying logged in needs a cookie on every stateless request. - You could narrate the whole URL journey above without looking.
Loading a page is one fast conversation: find the address, open a line, seal it, ask, answer. Every scary word is just one step of that second.