Envelopes All the Way Down: How Your Data Actually Travels the Network

Encapsulation: from wire to frame to packet

In the last post I described one web request quietly becoming “a MAC frame carrying an IP packet carrying a TCP segment carrying your HTTP request” — Russian dolls, all the way down. That nesting has a name: encapsulation. It’s one of those ideas that sounds academic until it clicks, and then you see it everywhere. So let’s open the dolls up one by one and watch a single message travel from an app on your screen all the way down to voltage on a copper wire — and back up again at the other end.

The one idea: envelopes inside envelopes

Imagine posting a letter through a very particular office. You write your note — “hi mum” — and hand it over. One clerk slides it into an envelope and writes which desk it’s ultimately for. A second clerk puts that envelope inside a bigger one addressed to the right building across the country. A third wraps the lot in a courier bag for the next van leaving the depot. Nobody rewrites your note; each clerk only adds their own envelope and only reads the one that’s their business.

That’s encapsulation in a sentence: each layer of the network wraps the data from the layer above in its own envelope, adds just the addressing it needs, and passes it down. The message itself never changes — it just gains and sheds layers of wrapping as it travels.

The layers we care about here

There’s a whole seven-layer model you can lose an afternoon to, but the journey from wire to web page really only needs four rungs, and we’re focused on the bottom three. From the top down:

  • The data — your actual message. “Load this page.” The thing everything else exists to carry.
  • The packet (Layer 3, IP) — the envelope with the destination address across the internet. This is what gets your data to the right building, anywhere in the world.
  • The frame (Layer 2, Ethernet) — the envelope for the next hop on the local network. This gets your data to the right device on this street.
  • The bits (Layer 1, physical) — the letter finally stops being paper and becomes signals: voltage on copper, pulses of light on fibre, radio on Wi-Fi.

(There’s a transport layer in between — TCP or UDP — that adds port numbers so the far end knows which application the data is for. We’ll let it ride along quietly; it’s just one more envelope.)

Going down the stack: wrapping up

When you send something, the data travels down through the layers, collecting an envelope at each step. Watch our “hi mum” pick up its wrapping on the way out:

flowchart TD
  A["Your data: hi mum"] --> B["+ TCP header = Segment (which app / port)"]
  B --> C["+ IP header = Packet (destination IP)"]
  C --> D["+ Ethernet header and trailer = Frame (next-hop MAC)"]
  D --> E["Bits on the wire: volts, light or radio"]

Two small bits of vocabulary make the rest painless. Most envelopes add a header — the addressing written on the front, read first. Ethernet is the tidy one that also adds a trailer on the back: a little checksum called the FCS, the postal equivalent of a tamper-proof seal, so the device receiving that hop can tell whether the frame got garbled along the way. If the seal’s broken, the frame is simply binned — no fuss, and crucially no resend at this level. Header on the front, seal on the back, your data safely in the middle.

Note: two different kinds of “did it arrive?”

It’s easy to lump all this “checking” together, so here’s the distinction that trips people up. The frame’s FCS is a per-hop corruption check: each device along the way confirms the frame turned up un-garbled and, if the seal’s broken, quietly bins it — it never asks for a resend. Actually noticing that something went missing, and doing something about it, happens far higher up at the transport layer — and that’s exactly where TCP and UDP part ways. Both can checksum their own contents, but only one acts on the result. TCP is signed-for delivery: the sender keeps a copy, waits for an acknowledgement, and re-sends anything that doesn’t turn up — guaranteed, and in order. UDP is an ordinary postcard: dropped in the box, no tracking, no resend — which sounds careless until you’re carrying live voice or video, where a packet re-sent a moment later would arrive too late to be any use. Same question; answered at two completely different levels.

The elegant part is that every layer treats the entire thing handed to it as opaque cargo. To the Ethernet layer, the IP packet inside is just “the stuff I’m carrying” — it neither knows nor cares that there’s an address written on it. It slaps its own envelope around the outside and moves on. Each clerk, their own envelope.

A closer look at the frame (and a coloured wristband)

Let’s crack open that Ethernet frame, because it’s where two of our characters finally meet. Laid out left to right, a frame is really just: who it’s for, who it’s from, a note about what’s inside, the cargo itself, and that seal on the end.

flowchart LR
  M1["Dest MAC"] --> M2["Src MAC"] --> VT["VLAN tag (optional)"] --> ET["Type"] --> P["Payload: the IP packet"] --> FCS["FCS (the seal)"]

Notice the payload: sitting right there inside the frame is the whole IP packet — address and all — treated as cargo, exactly as promised. This is the “carrying” in “a frame carrying a packet”. And notice that little optional slot after the source address, because that’s where something rather clever hides.

Tidbit: where a VLAN tag lives

A VLAN tag (the 802.1Q standard, if you want to sound fancy at parties) is a tiny four-byte sticker slipped inside the Ethernet frame, right after the source MAC. Think of it as a coloured wristband on the envelope. The wire between two switches is a shared corridor, and the tag lets the switches keep Accounting’s mail and Sales’ mail rigorously separate even though both are walking down that same corridor — same cable, different “virtual” networks. Your data doesn’t notice; only the switches read the wristband. It’s the whole reason one physical switch can pretend to be several isolated ones, and it earns a post all of its own another day.

On the wire: the part everyone forgets

Once the frame is built, it has to physically leave. This is Layer 1, and it’s where the metaphor gets literal: the neat row of bytes we just drew becomes a stream of signals — changing voltages on a copper cable, flickers of laser light down fibre, or radio waves through the air for Wi-Fi. A 1 and a 0 are just “high” and “low”, agreed in advance by both ends. That’s it. That’s the wire. Everything grand about the internet ultimately rides on somebody flipping a signal on and off very, very quickly.

Worth pinning down here: the frame’s MAC address is “which door on this street”, while the IP address wrapped inside is “which building, anywhere in the world”. A frame only ever travels one hop — desk to switch, switch to router. At each hop the outer Ethernet envelope is torn off and a fresh one written for the next leg, while the IP packet inside rides all the way to its destination untouched. New courier bag every van; same letter the whole way.

Going back up: unwrapping

At the far end the whole thing runs in reverse, and this half has a name too: decapsulation. The signals become bits, the bits become a frame, and now each layer peels off its envelope and asks one question — “is this for me?” — before handing the contents up:

  1. Physical: signals reassembled into a frame’s worth of bits.
  2. Ethernet: “Is this MAC mine? Does the FCS seal check out?” If yes, strip the frame, keep the packet inside.
  3. IP: “Is this destination IP mine?” If yes, strip the packet, keep the segment.
  4. TCP: “Port 443 — that’s the web server.” Hand the data to the right application.
  5. Application: a web server finally reads “hi mum” and gets to work.

It’s the exact mirror image of the trip down. Wrapped on the way out, unwrapped on the way in, one envelope per layer, each opened only by the clerk it belongs to.

Why bother? Because it’s quietly genius

All this wrapping might look like bureaucracy, but the payoff is enormous: because the layers are independent, you can swap any one of them without disturbing the others. Move from Wi-Fi to fibre and only Layer 1 changes — your web request neither knows nor cares. Netflix never had to be rewritten because you upgraded your router. IPv6 could slot in underneath applications that were written for IPv4. Each layer trusts the one below to just “get this to the next stop”, and gets on with its own job.

Encapsulation is why the internet can be upgraded piece by piece instead of all at once. No single layer has to know how the others work — only how to hand over.

The one-sentence version

Your data is a letter; each layer wraps it in an envelope addressed for its own leg of the journey, the wire turns the whole bundle into signals, and the far end unwraps it one envelope at a time. Once you can see the envelopes, a packet capture in Wireshark stops being a wall of hex and starts reading like a set of nested address labels — which is exactly what it is.

There’s one enormous assumption humming underneath all of this, though: that our tidy local network — the “street” our frames hop across — isn’t secretly a chaotic tangle of cables looping back on themselves, endlessly forwarding the same frame until everything grinds to a halt. Keeping that street sane is the job of a protocol with a wonderfully literal name. Next time: spanning-tree, and how switches quietly agree not to set the network on fire.