Imagine you phone a friend in another country. Before a single useful word gets across, you both have to agree on a pile of invisible rules: which language you'll speak, that you'll say "hello" first, that you take turns rather than talk over each other, and that you say "bye" before hanging up. Break any one of those and the call falls apart — even though the phones themselves work perfectly.
Computers on a
This matters because the internet is built out of a wild mixture of hardware. Protocols are the "common languages" that let all of it cooperate. Without them, your laptop and a web server would be two people shouting past each other in different tongues.
There isn't just one protocol — there are many, and each has a specific job. You've almost certainly used all of these today without noticing:
Notice how narrow each one is. HTTP knows nothing about email; IP knows nothing about web pages. Each protocol does one job well and leaves the rest to others — which is the big idea we meet next.
Getting a web page from a server to your screen is a huge task: find the right computer, carry the data reliably, squeeze it through whatever cable or radio link you happen to be using, and finally make sense of it as a page. Doing all of that in one tangled lump would be a nightmare to build and impossible to change.
The TCP/IP model tames it by splitting the work into layers, stacked on top of one another. Each layer has one responsibility and only talks to the layers directly above and below it. There are four:
When you send something, your data travels down the stack — the application layer hands it to transport, which hands it to internet, which hands it to link — and each layer wraps its own information around it. At the other end it travels back up the stack, and each layer peels its bit off again. Neither computer has to think about the whole journey at once; each layer just does its one job and passes the parcel on.
The whole point of layering is that each layer does one job and doesn't care how the others do theirs. The link layer just moves bits from here to the next box — it has no idea whether those bits are a web page or an email, and it doesn't need to. That's what lets you swap Wi‑Fi for an Ethernet cable halfway through loading a page: you change only the link layer, and the web page, TCP and IP above it carry on completely unchanged. Layers can be improved or replaced independently, which is why the internet has kept working while the hardware underneath it changed beyond recognition.
The other classic trap: TCP and IP are two different protocols doing two different jobs — we just say "TCP/IP" together so often that people treat them as one thing. IP handles addressing and routing (finding the right computer). TCP handles reliable delivery (making sure nothing arrives missing or out of order). IP will happily deliver packets to the wrong-looking places or lose them; TCP is the layer above that notices and fixes it. Addressing and reliability are separate problems, solved by separate protocols in separate layers.
No — and that difference is the heart of layering. A protocol is a set of rules, not a piece of hardware. The rules of chess don't change if you play on a wooden board or a phone app; likewise HTTP's rules are the same whether the request travels over fibre, copper or radio. The hardware lives down in the link layer; the rules live in the layers above and stay the same no matter what carries them.
Because HTTP is fussy: a web page arriving with a chunk missing or its bytes shuffled would be gibberish. But HTTP doesn't want to solve that itself — that would mean every application re-inventing the same delivery machinery. Instead it sits on top of TCP and lets the transport layer guarantee the bytes arrive complete and in order. Email (SMTP) and file transfer (FTP) lean on the very same TCP for the very same reason. Build the reliable-delivery job once, then everyone above can borrow it.