Module 10 · Network models · Lesson 2 of 4
Encapsulation and headers
How a single HTTP request becomes bits on a wire: each layer wraps the one above in its own header. What is in the Ethernet, IP and TCP headers, MTU and fragmentation, and why header overhead and packet size matter for performance.
Why it matters
Every byte your service sends travels inside several envelopes, and the envelopes cost something: bytes on the wire, work at every hop, and hard size limits that cause some of the strangest bugs in networking. "Small requests work, large ones hang" is often a packet-size problem; "this tunnel is slower than expected" is often header overhead. Understanding encapsulation turns those from mysteries into arithmetic.
The idea
When an application sends data, each layer below wraps it in a header carrying the information that layer needs, and passes the result down: encapsulation. The receiver's layers strip the headers off in reverse order: decapsulation. Each layer reads only its own header and treats everything inside as opaque payload.
What each header carries
| Header | Key fields | Used for |
|---|---|---|
| Ethernet (14 bytes + 4 byte checksum) | Destination MAC, source MAC, EtherType, frame check sequence | Delivering the frame to the next device on this link; detecting corruption |
| IPv4 (20 bytes minimum) | Source and destination IP, TTL, protocol, total length, fragmentation flags, checksum | Routing across networks; TTL stops loops; protocol says TCP or UDP follows |
| IPv6 (40 bytes fixed) | Source and destination IP, hop limit, next header, flow label | Same job with bigger addresses and a simpler fixed format |
| TCP (20 bytes minimum) | Source and destination port, sequence and acknowledgement numbers, flags, window size, checksum, options | Delivering to the right process, in order, reliably, at a rate the receiver can take |
| UDP (8 bytes) | Source and destination port, length, checksum | Delivering to the right process, nothing more |
Note what changes hop by hop: the Ethernet header is rewritten at every router (new source and destination MAC for each link), the IP TTL is decremented at each hop, and the TCP header passes through untouched end to end unless a NAT or proxy rewrites ports.
MTU, MSS and fragmentation
Each link has a maximum transmission unit (MTU): the largest payload one frame can carry, 1,500 bytes on standard Ethernet. Subtract the IP and TCP headers (40 bytes) and the largest TCP payload per packet, the maximum segment size (MSS), is 1,460 bytes. TCP splits a large response into MSS-sized segments; a 1 MB response is about 700 packets.
If a packet is larger than the next link's MTU (common with tunnels and VPNs, which add their own headers), IPv4 can fragment it into pieces, at a performance cost and with fragile reassembly. Modern stacks instead set "don't fragment" and rely on path MTU discovery: a router that cannot forward the packet returns an ICMP "too big" message and the sender shrinks. When a firewall blocks that ICMP, large packets vanish silently while small ones work: the classic "connection hangs after the handshake" bug, fixed by allowing the ICMP or clamping the MSS on the tunnel.
Overhead in numbers
| Payload per packet | Header bytes (Ethernet + IP + TCP) | Efficiency |
|---|---|---|
| 1,460 B (full segment) | ~58 B plus inter-frame gap | ~95% |
| 100 B (small RPC) | ~58 B | ~63% |
| 1 B (a keystroke) | ~58 B | ~2% |
| 1,460 B inside a VPN tunnel | plus 50–80 B of tunnel headers | lower, and MTU shrinks |
This is why batching small messages, compressing payloads and avoiding chatty protocols pay off, and why high-throughput links use jumbo frames (9,000-byte MTU) inside data centres.
Trade-offs
Encapsulation buys independence between layers and lets every hop process only what it needs, at the cost of per-packet overhead and a hard size ceiling that every layer must respect. Bigger MTUs reduce overhead and per-packet processing but must be supported end to end; tunnels add flexibility and security but eat into the MTU and invite fragmentation problems.
In an interview
Bring it up in two places. Throughput: "Small messages are dominated by header overhead and per-packet costs, so the client batches events into requests of tens of kilobytes." Debugging: "If small requests succeed and large ones hang over the VPN, suspect MTU: the large packets exceed the tunnel MTU and the ICMP that would tell the sender is being dropped; clamp MSS or allow ICMP type 3 code 4."
Check yourself
After a site-to-site VPN is added, API calls with small responses work but those returning large JSON bodies hang after the TCP handshake. What is the most likely cause?