One impossible job, or five doable ones?
By now you have met a lot of moving parts. A packet is a postcard with an address. The core forwards those postcards hop by hop. Links have a bandwidth, and signals fight a fixed propagation delay set by geography. And every cooperating device must obey a shared protocol — a format, an order, and a set of actions. Now step back and ask the scary question: how could anyone possibly design the whole thing at once? Getting a click in your browser to fetch a page from a server on the other side of the planet involves Wi-Fi radios, fiber, dozens of routers, congestion, lost packets, name lookups, and encryption. That is far too much for one program, one team, or one protocol to get right.
The way out is the single most powerful idea in networking — and in a lot of engineering: layering. Instead of one giant program, you build a stack of layers, where each layer does just one job well, offers a tidy service to the layer above it, and quietly uses the service of the layer below. The web browser does not know or care how Wi-Fi works; Wi-Fi does not know or care that it is carrying a web page rather than an email. Each layer trusts the one below to deliver and serves the one above.
A service contract, not a friendship
The magic ingredient is the interface between two layers — think of it as a small, fixed contract. A layer promises a service ("give me your data and a destination, and I will try to deliver it") without promising anything about how it keeps that promise. As long as the contract stays the same, you can rip out the inside of a layer and swap in a completely different mechanism, and nobody above or below even notices. This is why the protocol stack is so robust: the layers are decoupled.
A concrete example you can feel: your laptop's top layer speaks HTTP to fetch a page. Below it sits a reliable byte-pipe layer. This morning your packets rode that pipe over Wi-Fi; this afternoon you plugged in an Ethernet cable; on the train it was 5G. The browser code did not change one line. Each access link is a different bottom layer fulfilling the same contract — "carry these bits across one hop" — so everything stacked on top just keeps working. That swappability is the entire payoff of layering.
Nested envelopes: how encapsulation works
If each layer is independent, how does your data physically get all the way down the stack and back up at the far end? The mechanism is encapsulation, and the picture is nested envelopes. As your message heads down the sending stack, each layer wraps what it received from above in its own header — a small band of control bytes meant for its counterpart layer on the other machine. The layer below treats that whole bundle (header plus everything inside) as opaque cargo, and wraps it again. The data is never rewritten; it is just wrapped, and wrapped, and wrapped.
Each header carries exactly the information that layer needs and nothing more. The transport header carries port numbers and a sequence number so the data lands in the right program in the right order. The network header carries source and destination IP addresses so routers can forward it. The link header carries MAC addresses for the next single hop. At the receiving host the whole thing runs in reverse — decapsulation: each layer peels off and reads its own header, acts on it, and hands the inside up to the next layer, until the bare message pops out at the top exactly as it went in.
DOWN the sending stack (each layer adds its own header):
app data .................................. [ HTTP request ]
+ transport header .............. [ TCP | HTTP request ]
+ network header ........ [ IP | TCP | HTTP request ]
+ link header ... [ ETH | IP | TCP | HTTP request | ETH-trailer ]
\___ this is what actually goes on the wire ___/
UP the receiving stack: peel ETH, then IP, then TCP -> HTTP request again.Who reads which envelope, and where
Here is the subtle, beautiful part. A device in the middle does not open every envelope — it only opens as deep as its job requires, then stops. This is exactly why the core can stay simple. A switch is a layer-2 box: it reads the link header (MAC addresses) and forwards, never even glancing at the IP inside. A router is a layer-3 box: it peels the link header, reads the IP header to decide the next hop, then wraps a fresh link header for the new hop and sends it on. Only the two end systems — the sender and the final receiver — ever climb all the way up to the transport and application layers and read the message itself.
- Your laptop's browser builds an HTTP request and hands it to the transport layer.
- Transport wraps it with a TCP header (ports, sequence number) and hands it to the network layer.
- Network wraps it with an IP header (source and destination IP) and hands it to the link layer.
- The link layer wraps it with an Ethernet (or Wi-Fi) header and sends the bits onto the wire.
- Each router on the path peels the link header, reads the IP header, re-wraps a new link header for the next hop — the TCP and HTTP envelopes inside stay sealed.
- At the server, the layers peel off in reverse until the bare HTTP request reaches the web program, which replies the same way back.
Notice the honest cost of all this wrapping: every header is overhead — extra bytes that are not your data, sent on every single packet. On a tiny packet the headers can be a big fraction of what crosses the wire. That is the price of modularity, and the designers judged it well worth paying. It is also why words like packet, frame, datagram, and segment all mean "a chunk with a header" but at different layers — they are simply the same data seen at different depths of the nesting.
Two famous maps: OSI vs TCP/IP
Because layering matters so much, two reference models became famous for naming the layers. The OSI model is the classic seven-layer textbook map (physical, data link, network, transport, session, presentation, application), published by the ISO standards body around 1984. It is a wonderful teaching tool and gives everyone shared vocabulary — when an engineer says "that is a layer-3 problem," they mean the network layer in OSI's numbering.
But here is the honest truth you must carry forward: the real Internet does not run OSI. It runs the TCP/IP model, a leaner four- or five-layer stack (link, network with IP, transport with TCP/UDP, and application) that was already working in the field before OSI was finished. OSI's top three layers (session, presentation, application) are simply folded into one "application layer" in practice. So treat OSI as the map you learn from and the shared ruler everyone measures with, and treat TCP/IP as the machine that actually carries this very page to you.