Protocols and the layered model
Why network software is built like a set of nested envelopes, and how the OSI and TCP/IP models describe it.
A gift inside a box inside a box
Imagine you're mailing a birthday gift. You put the gift in a small box, that box goes inside a padded envelope, and the envelope goes inside a shipping box with a courier's shipping label stuck on the outside. Four layers of wrapping, each added by a different "worker," and each worker only cares about their own layer:
- The courier only reads the outer shipping label to decide which truck it goes on.
- The delivery person only cares about the padded envelope once the shipping box is opened.
- Only your friend, at the very end, opens the innermost box and sees the gift.
This is exactly how data travels across a network. Every layer wraps the previous layer's output in its own "envelope" (called a header), and each layer only understands its own envelope, not what's inside.
Why bother with layers at all?
You could, in theory, build one giant piece of software that handles "sending data" as a single blob of logic. Nobody does this, for the same reason nobody builds a car as one solid, un-openable block of metal: if one part breaks or needs upgrading, you want to replace that part without rebuilding everything else. Wi-Fi replaced Ethernet cables at the bottom layer of the stack without anyone having to rewrite how web browsers work at the top. That's the entire point of layering: each layer can change independently, as long as it keeps its promise to the layer above and below it.
The two models you'll see everywhere
There are two standard ways people describe these layers. You mostly need to recognize both and know they describe the same reality at different levels of detail.
The OSI model (7 layers, mostly used as a teaching/reference tool):
| # | Layer | What it's responsible for | Real-world analogy |
|---|---|---|---|
| 7 | Application | The actual program's data (a web page, an email) | The gift itself |
| 6 | Presentation | Formatting, encryption, compression | Wrapping paper, translating language |
| 5 | Session | Keeping a conversation open between two ends | An ongoing phone call |
| 4 | Transport | Reliable delivery, ordering, splitting into segments | Numbered postcards, tracking |
| 3 | Network | Addressing and routing across networks | Postal address, sorting by city |
| 2 | Data Link | Delivery between two directly connected devices | Sorting mail inside one building |
| 1 | Physical | The actual electrical signal, light, or radio wave | The delivery truck's wheels on the road |
The TCP/IP model (4–5 layers, what the real Internet is actually built on): Application, Transport, Internet, Link (Physical is sometimes folded into Link). It squashes OSI's top three layers into one "Application" layer, because in practice, most software doesn't cleanly separate presentation and session logic from the application itself.
This course mostly follows the TCP/IP grouping since it matches how real protocols are built, while borrowing OSI's layer names because they're what everyone says out loud in interviews and job postings.
Encapsulation: watching the envelopes get added
Say your browser wants to send the text"hi" (2 bytes) to a server. Here's what happens as it travels down the stack on your machine, with made-up but realistic header sizes:
Application data: "hi" (2 bytes)
+ Transport header (TCP, 20 bytes): [TCP][ "hi" ] (22 bytes)
+ Network header (IP, 20 bytes): [IP][TCP][ "hi" ] (42 bytes)
+ Link header (Ethernet, 14 bytes):[Eth][IP][TCP][ "hi" ] (56 bytes)
By the time your 2 bytes of actual text hit the wire, they're travelling inside 54 bytes of headers. This process — wrapping data in a new header at every layer going down — is called encapsulation. When the message arrives at the destination, the exact reverse happens: each layer strips off its own header and hands the remaining contents up to the layer above. That's decapsulation.
The math of overhead, generalized
If you send separate small messages of bytes each, and your combined header overhead per message is bytes, your total bytes sent is:
For our "hi" example sent once: bytes — overhead is 96% of everything sent. This is exactly why chat apps and games batch small updates together rather than sending a brand-new packet for every keystroke: fixed per-packet overhead dominates when the payload is tiny.
Common mistakes
- Treating OSI as something that's literally "implemented." No software has a distinct, separate module for each of the 7 OSI layers. It's a mental model for talking about responsibilities, not a blueprint.
- Thinking a higher layer needs to know what a lower layer is doing. The Application layer doesn't know or care if you're on Wi-Fi or a cable — that's the whole benefit of layering.
- Forgetting decapsulation is the exact reverse order. Headers are stripped Link → Network → Transport → Application, the mirror image of how they were added.
Summary
Layering lets each part of the networking stack evolve independently, the same way a courier doesn't need to know what's inside your gift box. OSI gives you a detailed 7-layer vocabulary; TCP/IP is the simpler, practical model the real Internet runs on. Every layer going down adds its own header (encapsulation); every layer going up strips its own header back off (decapsulation) — and that added overhead is a real, calculable cost that matters most when your actual payload is small.