Encapsulation & Decapsulation — Segments → Packets → Frames → Bits

Concrete Example

Take a browser issuing GET / HTTP/1.1 over TCP to a web server. Follow those bytes down the sending host's stack and watch each layer wrap what it was given:

L7 App        │ GET / HTTP/1.1 ...                              │   ← "Data"
L4 Transport  │[TCP hdr]│ GET / ... │                           │   ← "Segment"
L3 Network    │[IP hdr]│[TCP hdr]│ GET / ... │                  │   ← "Packet"
L2 Data Link  │[Eth hdr]│[IP hdr]│[TCP hdr]│ GET / ... │[Eth FCS]│   ← "Frame"
L1 Physical   │ 010101101000101110100101110001010110...         │   ← "Bits"

Three details in that picture do most of the work. First, each layer's payload is the entire PDU from the layer above — header and all. IP does not carry "the HTTP request"; it carries "the TCP segment", which happens to contain the HTTP request. Dolls inside dolls. Second, headers are prepended, so the original application bytes never move; they simply end up further from the front. Third, L2 alone adds a trailer as well as a header.

The vocabulary is not decoration — each PDU name identifies a layer and what that layer contributed:

The load-bearing header fields

Roughly 58 bytes of header get added to that request, and almost every field is one of the addressing ideas from the layer model turned into concrete bytes:

L4  TCP header      (~20 B)  src/dst PORT    which application process
                             seq / ack #     ordering and confirmation
                             flags           SYN / ACK / FIN / RST
                             window          flow control
                             checksum

L3  IP header       (~20 B)  src/dst IP      end-to-end; never changes en route
                             TTL             hop counter, −1 per router, 0 = drop
                             Protocol        what L4 is inside (6=TCP 17=UDP 1=ICMP)
                             checksum

L2  Ethernet    (14 B + 4 B) dst/src MAC     one hop only; rewritten every hop
                             EtherType       what L3 is inside (0x0800=IPv4,
                                             0x0806=ARP, 0x86DD=IPv6)
                             FCS (trailer)   error detection

Read the three address fields together and the hierarchy is literal, stacked in bytes: TCP carries ports (which application), IP carries end-to-end addresses (fixed for the whole journey), Ethernet carries MACs (valid for exactly one hop).

Demultiplexing: how the receiver knows how to unwrap

Bits arriving off a wire are just bits. The receiving machine never guesses what is inside them, because every header contains a "what's nested in me" pointer:

Ethernet ──EtherType 0x0800──►  payload is IPv4
   IP    ──Protocol 6────────►  payload is TCP
   TCP   ──Dest Port 443──────►  hand to the HTTPS server process

Decapsulation is then just that chain walked in order. Each layer validates its own header, strips it, and uses the pointer to choose who gets the rest:

Bits → L2  (is this my MAC? is the FCS ok?)   strip → EtherType says IPv4, up
     → L3  (is this my IP? TTL/checksum ok?)  strip → Protocol says TCP, up
     → L4  (which port / which connection?)   strip → port 443, hand to app
     → L7  application reads "GET / HTTP/1.1"

What routers and switches actually unwrap

Devices in the middle decapsulate only as far as their job requires — never further. A switch unwraps to L2, reads the destination MAC, forwards the frame out a port, and never looks at the IP or TCP inside. A router unwraps to L3, reads the destination IP, decides the next hop, and then does something that surprises people the first time they see it: it discards the entire Ethernet frame and builds a brand-new one for the next link.

Router: strip L2 → read/keep IP packet → decide next hop → TTL−1 → wrap in NEW L2 frame → send

The IP packet inside is handed on essentially untouched (only TTL and the header checksum change); the TCP and HTTP inside it are never opened at all. This is exactly why IP is end-to-end while MAC is rewritten every hop: the IP packet is the durable inner doll that travels the whole way, and the Ethernet frame is a disposable outer doll torn off and rebuilt at every router.

What the headers cost

TCP (20) + IP (20) + Ethernet header+trailer (18) ≈ 58 bytes of overhead per frame

That cost is fixed regardless of how much data rides inside it. A 1-byte payload still puts about 59 bytes on the wire — roughly 98% overhead. A full 1500-byte MTU-sized frame amortizes the same 58 bytes down to under 4%. That single ratio is why small, chatty packets hurt throughput and why MTU sizing matters at all.

Visual Model

Think of posting a letter through an office. You write the letter (the data). Your assistant seals it in an envelope marked with a room number (the TCP port). That envelope goes into a bigger one addressed to a building across the country (the IP addresses). That one goes into a courier bag addressed only to the van waiting outside (the MAC addresses) — a bag that gets thrown away and replaced at every depot along the route, while the country-wide envelope inside is never opened once. Nobody along the way reads the letter. They don't need to; each wrapper tells them exactly what they need, and each wrapper also carries a note saying what kind of thing is inside it, so whoever opens it knows who to pass it to next.

Step through it below. The first five steps wrap the request going down the sending stack — watch the PDU name on the right change as each header lands. The last five unwrap it on the receiving host, following the pointer chain at the bottom: EtherType names IP, IP's Protocol field names TCP, TCP's port names the application.