Network layers — study guide
The concept's fragments, read in order.
One big problem, cut into layers
Getting a message from one program on one machine to another program on a different machine is not one problem. It is a stack of them: pushing bits down a wire, finding the right machine across the world, keeping a conversation in order, and agreeing on what the bytes even mean. Solving all of that in one piece of software would be unmanageable, and no one tries.
So networking is cut into layers. Each layer solves exactly one of those problems and hands its result to the next, trusting the layer beneath it to have already done its own job — like a kitchen line where each cook works one station and trusts the next to do theirs, passing the dish along without doing everyone else's job. The layer that routes a message between networks does not care whether the wire underneath is copper, fiber, or radio; it just asks the layer below to move the bits and gets on with routing.
The payoff is that no single piece has to do everything. Each layer can be designed, understood, and repaired on its own, by people who never need to know how the layers around it work inside.
What one layer is responsible for
A layer is defined by two things: the service it offers to the layer above it, and the service it asks of the layer below it. Between them sits a fixed interface — a promise about what goes in and what comes back out — and nothing else about the layer is anyone else's business.
This is the whole trick. The layer above hands its data down and gets a guarantee back — bits moved, a message delivered, a connection kept alive — without learning how that guarantee is met. The layer below could be rewritten from scratch, and as long as it still keeps the same promise at the interface, the layer above never notices the difference.
Because each layer speaks only to its two immediate neighbors, and only through their agreed interfaces, a change stays contained where it happens. That containment is what makes a network of this size buildable at all.
The seven OSI layers
The OSI reference model, published in 1984 as ISO 7498, gives networking its shared vocabulary: seven layers, numbered 1 to 7 from the bottom up. You rarely build all seven by hand, but naming them lets two people point at exactly the same place when something goes wrong.
From the bottom: layer 1, physical, moves raw bits across a medium such as copper, fiber, or radio. Layer 2, data link, groups those bits into frames and delivers them across a single local link. Layer 3, network, adds addressing and routing so a message can cross between networks to a distant machine. Layer 4, transport, delivers end to end between individual programs and decides whether that delivery has to be reliable and ordered.
Above transport sit the three that applications lean on. Layer 5, session, opens and closes the back-and-forth of a dialog. Layer 6, presentation, settles how data is represented — its encoding, and any encryption. Layer 7, application, is where the protocols that programs actually speak live. Bits at the bottom, meaning at the top, and each step up is one more problem already solved for you.
The four layers the internet actually uses
The seven-layer model is a reference, not a blueprint. The internet actually runs on a leaner one: the TCP/IP model, defined in RFC 1122, which has four layers — link, internet, transport, and application.
The four map cleanly onto the seven. The link layer covers what OSI splits into physical and data link — bits on the wire and local delivery, together. The internet layer is OSI's network layer: addressing and routing between networks. The transport layer matches OSI's transport, end-to-end delivery between programs. And the application layer rolls OSI's top three — session, presentation, and application — into one, leaving those finer distinctions to the programs themselves.
You will sometimes see a five-layer version that splits the link layer back into physical and data link. That is a teaching convenience for lining the two models up, not the model RFC 1122 specifies — the internet's real model has four. When people say "the stack," this four-layer one is almost always what they mean.
Wrapping the data on the way down
A layer never rewrites the data handed to it. It wraps it. Going down the stack, each layer takes whatever it received from above, treats the whole thing as opaque cargo, and prepends its own header — the addressing and bookkeeping that layer needs to do its job — like sealing a letter inside one labeled envelope, then sealing that inside a larger labeled envelope, so the outermost label is the first one read and removed.
The wrapping renames the bundle at each step. The application's data becomes a segment at the transport layer, or a datagram when the transport is connectionless, then a packet at the network layer, then a frame at the data link layer, until it is finally just bits on the wire. Each new name marks one more header wrapped around the same original payload.
At the far end the process runs in reverse. The receiver's link layer reads and strips the frame header, hands what is inside up to the network layer, which strips the packet header, and so on up the stack — each layer opening exactly the envelope its counterpart sealed. By the time the data reaches the application on the other side, every header is gone and only the original payload is left.
Why the layering pays off
The point of all this wrapping and naming is not tidiness. It is that a layer can be replaced wholesale, as long as it keeps its promise at the interface. Swap a wired connection for wifi and you have torn out and rebuilt the very bottom of the stack — like switching a package from a truck to a train without repacking the box inside or telling the recipient anything changed — yet nothing above it changes. The addressing, the connections, the application all keep working, because none of them ever knew how the bits were moving in the first place.
This is why the same web browser works over ethernet at a desk, wifi in a cafe, and a cellular link on a train. The lower layers differ completely in each case; the interface they present upward does not. A new physical technology can arrive, and the layers above inherit it for free.
Abstraction is not free — every header is overhead, and a fault can hide behind an interface that hides its insides a little too well — but the trade buys something enormous: the freedom to change any one layer without renegotiating with all the others.
Where the neat picture leaks
The layered picture is clean, and the real world is not. Every non-trivial abstraction leaks: the layer beneath shows through the interface that was supposed to hide it, usually as performance or failure the neat diagram never predicted.
The classic case lives right in the stack. The transport layer can offer reliable, ordered delivery even though the network layer beneath it makes no such promise and quietly loses packets from time to time. The abstraction holds — the data does arrive, in order — but when the layer below drops something, the layer above has to notice and resend, and that delay leaks upward as latency the application feels but never asked for. Reliability sits on top of unreliability, and the seam shows under load.
So treat the model as a map, not the territory. Layers are the right way to think and the right way to divide the work, but a real problem can begin in one layer and surface as a symptom two layers away. The boundaries are conventions that hardware and software mostly honor, not walls.
Knowing which layer to blame
Layering is not only a way to describe a network — it is a way to debug one. When something will not connect, the layers hand you an order to check things in, from the bottom up, so you are working a list instead of guessing.
Is the physical link even up: is the cable seated, is the interface reporting a hardware address at all? If so, does the machine have a network address, and can it reach others? If that holds, will a connection actually open to the port the service is supposed to be listening on? And only when all of that checks out do you start suspecting the application itself. Each question belongs to one layer, and asking them in order turns "the internet is broken" into a specific, findable fault.
This is why one machine answers to several names at once: a hardware address down at the link layer, a network address that can change, and a set of listening ports up at the transport layer. They are not redundant — each names the machine at a different layer, and knowing which layer you are asking about tells you which name to read. For a personal site or a homelab, that is the difference between fixing the thing and rebooting it and hoping.