Encapsulation — headers all the way down

Every time data moves from a higher layer to a lower one, the lower layer wraps it in its own header. Going up, each layer strips its header off again. This is encapsulation, and it's how layered protocols stay independent of each other.

The whole thing in one picture

When your browser fetches https://example.com, the data leaves the application as a TLS-encrypted HTTP request and arrives at the wire as a sequence of bits in an Ethernet frame:

Application (HTTP):    GET / HTTP/2 ... (TLS encrypts this)
Transport  (TCP):      [TCP header][app data]                         = segment
Internet   (IP):       [IP header][TCP header][app data]              = packet
Link       (Ethernet): [Eth header][IP header][TCP header][app data][FCS] = frame
Physical:              101110010011010011001 ...                       = bits

At each layer the PDU (Protocol Data Unit) has a different name:

| Layer | PDU name | |---|---| | Application | message / data | | Transport | segment (TCP) or datagram (UDP) | | Internet | packet | | Link | frame | | Physical | bits / symbols |

Why "encapsulation" not "embedding"

The lower layer never reads inside the upper layer's PDU. The Ethernet driver doesn't know whether your packet is IP or anything else — it just sees a payload with a length and a type. The router doesn't know whether your IP packet is carrying TCP, UDP, or ICMP — it just looks at the IP header to forward.

This is the magic of layering: a router can be upgraded to handle IPv6 without knowing anything about TLS 1.3, because TLS lives way up in the application and IP just sees an opaque payload.

Receiving — decapsulation

The reverse, on the receiving host:

1. NIC receives bits, recognises a frame, hands the payload (everything inside the Ethernet header) to the IP stack.
2. IP stack reads its header, hands the payload (everything inside the IP header) to TCP or UDP.
3. TCP sorts data into the right socket, delivers to the application as a stream.
4. Application reads the bytes and does whatever it does.

Each layer only "sees" what the layer below hands it — its own header plus an opaque payload.

MTU and fragmentation

The largest payload an Ethernet frame can carry is the MTU (Maximum Transmission Unit), usually 1500 bytes on standard Ethernet. If a packet from the IP layer is too big, two things can happen:

• IP fragments it into smaller pieces, each of which fits in a frame. Reassembled at the destination. Hates middleboxes; deprecated in IPv6.
• TCP discovers the limit via PMTUD (Path MTU Discovery) and never sends segments that won't fit. The healthy approach.

A surprising amount of "this works but slowly" production weirdness is broken PMTUD: an ICMP rate-limit somewhere drops the "too big" message, sender keeps blasting full-MTU packets, somewhere along the path silently discards them, throughput collapses.

Jumbo frames

Some networks (especially data center fabrics, server-to-server links, iSCSI/NFS storage) raise the MTU to 9000 bytes ("jumbo frames"). Fewer frames per byte = less per-frame overhead = higher CPU efficiency and throughput. Must be configured end to end — a single hop that doesn't support jumbos breaks everything.

What to remember

• Data goes down the stack getting wrapped, comes up getting unwrapped.
• The PDU name changes per layer (segment, packet, frame).
• Each layer only sees its own header + opaque payload.
• The Ethernet payload is bounded by MTU (1500 default, 9000 for jumbos). Mismatches manifest as "fast for small, broken for large."