Protocols: The Rules Everyone Agrees On

Lesson 7 · taught by Pip

The internet works because every machine on it agrees to follow the same set of rules. Those rulebooks are called protocols. A protocol is just a written agreement: "if you send it this way, I'll know how to read it."

Think of two people who have never met but both learned the same handshake. One offers a hand, the other takes it, they shake, they let go. Nobody had to explain it in the moment, because the steps were agreed on in advance. Protocols are handshakes for computers. The machines may be made by different companies, sitting on different continents, but if they both follow the rule, they understand each other.

Why we need them

In the last few lessons we met packets, IP addresses, DNS, and routers. Each of those is really a protocol in disguise. IP is the rule for how to address and stamp a packet. DNS is the rule for turning a name into a number. None of it works unless both ends agree on the format down to the smallest detail, like two clerks who both fill out the same form the same way.

The internet isn't one rulebook, it's a stack of them, each handling one job. The lower rules carry raw signals down the wire. The middle rules move packets between addresses. The higher rules give those packets meaning, like "this is a web page" or "this is an email." Each layer trusts the one below to do its part and doesn't worry about the rest.

Meet TCP

Here's the snag with plain packets: they're postcards. They can arrive out of order, arrive twice, or get lost on the road. That's fine for a quick note, but useless for sending something whole, like a photo or a paragraph that has to read in the right sequence.

So we layer another protocol on top: TCP, the Transmission Control Protocol. TCP's whole job is to make a messy pile of packets behave like one clean, ordered delivery.

It does this with a few simple habits. It numbers every packet, so the far end can lay them back in order even if they show up jumbled. It waits for the receiver to say "got it," and if a packet goes missing, it sends that one again. And it begins with a little hello-back-and-forth, a setup handshake, so both sides confirm they're ready before any real data flows.

Picture mailing a long letter as numbered pages, and asking the reader to text you which pages landed. Anything that never arrives, you mail again. Eventually they hold the full letter, in order, with nothing missing. That's TCP, working quietly under almost everything you do online.

There's a faster, looser cousin called UDP that skips the confirmations, used when speed matters more than perfection, like a live video call where a missed frame isn't worth re-sending. Same idea, different trade-off.

Your turn

Think of the last time a big download crept toward 100% and never skipped backward — it only ever moved forward, even on a shaky connection. That steadiness is TCP at work: quietly numbering pieces, waiting for each "got it," and resending anything that slipped away, so the file lands whole. Picture that patient back-and-forth happening under every download you've ever finished.

We've seen the rules that let machines talk. Next we'll meet the two roles they play when they do, the one who asks and the one who answers. 🔦