Protocols and the Layered Model

You now have wires that carry bits, switches that move them across a local network, and routers that move them between networks. But every one of those steps quietly relies on an assumption we haven't talked about yet: the two ends must agree on what the bits actually mean.

A protocol is just an agreement

A protocol is simply an agreed set of rules for communicating. It defines what the bits stand for, who speaks first, what a valid message looks like, and how the other side should respond. These rules must be shared before the conversation even starts. If both sides do not agree in advance, a signal is just noise.

You have already met one protocol without the label. In the first chapter, the two ends of the wire agreed on how long a bit lasts and what voltage counts as a 1. That agreement is a protocol. The format a router reads to decide where a message goes is also a protocol. The internet relies on thousands of these agreements. It is built on many small protocols, each doing a single job and trusting the others to do theirs.

The layered model

Stacking these small protocols in a specific order creates the layered model. This is the single most useful map in networking. Each layer has one job and talks only to the layers directly above and below it.

From the bottom up:

• Physical: Move raw bits across a medium like copper, fibre, or radio. This is the wire from chapter one.
• Link: Move a frame between two devices on the same local network using MAC addresses. This is the switch's world.
• Network: Move a packet across different networks, from any machine to any other, using IP addresses. This is the router's world, and the protocol here is IP.
• Transport: Turn the network's rough, best-effort delivery into something a program can actually use. The most common choice, TCP, provides a reliable, in-order stream of data.
• Application: The conversation your program cares about. For the web, that protocol is HTTP, and it sits at the very top.

The power of this stack is that each layer trusts the one beneath it and ignores the rest. HTTP gets to talk about web pages and requests without ever thinking about voltages. Four layers below have already handled getting bits onto a wire and across the world. You write an HTTP request, and the layers underneath carry it.

The same idea, as a letter

If the stack still feels abstract, posting a letter follows the exact same structure.

You write a letter and care only about its contents. That is the application layer. The letter itself is your HTTP message. You put it in an envelope and write an address on it, which is the network layer doing its job with an IP address. You might choose a tracked, guaranteed delivery so nothing gets lost, which is the transport layer's promise (TCP). The postal service moves it by van and sorting office from one point to the next, just as the link layer hops data between neighbours. All of this rides on the roads, the physical layer underneath everything. You only think about the letter, while the rest is handled below you.

Where the rest of the course lives

Almost everything ahead is a deeper look at one of these layers. You can already place the big names on the map. IP is the network layer, TCP is the transport layer, and HTTP is the application layer at the top.

A few important protocols do not sit neatly on a single rung. DNS turns a name like example.com into an IP address, and TLS encrypts a connection. Both live up near the application layer but exist to serve the layers below them. The layered model is a teaching map rather than a strict law of physics. Real protocols sometimes straddle two layers, and you might see different drawings split the stack into four layers or seven. The boundaries are approximate. However, the core idea of one job per level, with each trusting the level below, is exact enough to navigate by.

This model is also a debugging map, which is where it pays off the most. When something breaks, the layers turn a vague "the internet is down" into a sequence of smaller, answerable questions. You ask them from the bottom up. Is the wire connected (physical)? Is the local network healthy (link)? Is routing reaching the destination (network)? Did the connection establish (transport)? Or is the application itself failing (application)? The first layer that answers "no" is usually where the problem lives.

What's Next

That completes the foundation. You have a wire, the devices that scale it into the internet, and the layers that give the bits meaning. With this map in hand, the next step is to follow one real web request down through these layers and back up again.