Encapsulation and the Life of a Packet
Each layer carries the layer above it by wrapping it in its own header. When a browser sends a request, the HTTP bytes become the payload of a TCP segment, which becomes the payload of an IP packet, which becomes the payload of an Ethernet frame. By the time the data hits the wire it is an onion: an HTTP core inside four nested headers, each addressed to a different concern.
Following one packet from a browser to a server, naming what each layer adds and what each hop changes, is the single most clarifying exercise in networking. Almost every later topic — NAT, firewalls, load balancers, MTU — is just a question of which header gets read or rewritten, and where.
Headers, Payloads, and Trailers
A header is metadata the layer needs to do its job, prepended to the data it was handed. The TCP header carries source and destination ports and sequence numbers; the IP header carries source and destination addresses and a time-to-live; the Ethernet header carries source and destination MAC addresses. Ethernet also adds a trailer — the frame check sequence — appended after the payload to detect corruption.
The crucial property is that each layer treats everything handed down from above as opaque payload. IP does not parse the TCP segment inside it; Ethernet does not parse the IP packet inside it. A layer reads only its own header and the rest is just bytes to carry — which is exactly what lets the layers stay independent.
Encapsulation on Send, Decapsulation on Receive
On the sending host the data moves down the stack, gaining a header at each layer — this is encapsulation. The application produces HTTP, the transport wraps it in TCP, the internet layer wraps that in IP, the link layer wraps that in a frame, and the bits go out the NIC. On the receiving host the reverse happens — decapsulation — as each layer strips its own header and hands the payload up.
Each layer on the receiver reads only the header its peer wrote on the sender, then passes the rest up. The receiving Ethernet layer checks the frame and hands the IP packet up; the IP layer checks the address and hands the TCP segment up; TCP reassembles the stream and hands the HTTP bytes to the application. Peer layers on the two hosts talk to each other through the headers, even though no layer ever sees more than its own.
# tcpdump shows the nesting directly — one captured packet, # three layers of header peeled from outside in tcpdump -n -v -i eth0 tcp port 443 # Ethernet aa:bb:cc:11:22:33 > dd:ee:ff:44:55:66 (L2: this hop's MACs) # IP 10.0.1.7 > 93.184.216.34 ttl 63 (L3: end-to-end addrs) # TCP 52344 > 443 seq 1:1449 (L4: ports + sequence)
The Life of a Packet, Hop by Hop
Trace the request from a laptop on 10.0.1.7 to a server at 93.184.216.34. The laptop builds the full onion, but it cannot send a frame straight to a server it has no wire to. It sends the frame to its default gateway — the local router — addressing the Ethernet header to the router's MAC while leaving the IP header addressed to the final server.
The router receives the frame, strips the Ethernet header, reads the IP destination, decides the next hop, and builds a new Ethernet header addressed to the next router's MAC. The IP packet inside is unchanged except that its TTL drops by one. This repeats at every router until the frame arrives on the server's segment, where the last hop's frame is addressed to the server's own MAC and the packet is finally decapsulated all the way up to the application.
What Changes per Hop versus End to End
The pattern is the heart of routing: the layer-2 header is rewritten at every hop, because MAC addresses are only meaningful on the local wire, while the layer-3 addresses stay constant end to end under normal routing. The source and destination IP a server sees are the same ones the laptop wrote — the only meaningful IP-header field that changes per hop is the TTL, decremented to catch loops — and because it changes, an IPv4 router must recompute the header checksum (IPv6 drops the checksum entirely).
The transport header changes least of all: TCP ports and sequence numbers are end-to-end state that no router touches. The exceptions are exactly the devices that break the rule on purpose — a NAT rewrites the layer-3 source address and the layer-4 port, which is why it complicates so much, and a tunnel wraps the whole packet in a fresh outer header. Spot those exceptions and the rest of the path is predictable.
A switch reads only the layer-2 header — the destination MAC — and forwards the frame out the matching port without touching anything above. It never looks at the IP packet inside.
A router strips the layer-2 header, reads the layer-3 destination IP to choose a next hop, decrements the TTL, and builds a brand-new layer-2 header for the next wire. It leaves layer 4 alone.
The server decapsulates every layer in turn — frame, packet, segment — up to the application, the only machine on the path that reads all the way to the HTTP payload.
- Believing the source MAC survives across routers. It does not — each router rewrites the layer-2 header, so the MAC a server sees is its last-hop router's, never the original client's. Only the source IP is preserved.
- Expecting the source or destination IP to change at each hop under normal routing. It does not change; only the TTL decrements. The IP addresses change only where a NAT deliberately rewrites them.
- Ignoring per-packet header overhead. Every layer adds bytes — roughly 14 for Ethernet, 20 for IPv4, 20 for TCP — so tiny payloads waste a large fraction of the frame on headers.
- Assuming a switch can make a routing decision. It reads only layer 2; sending traffic to another subnet requires a layer-3 device, no matter how capable the switch looks.
- Forgetting that tunnels add an entire extra header. A VPN or overlay wraps the original packet in a new outer IP header, and that added overhead is what silently eats into the usable MTU.
- Read a capture from the outside in — Ethernet, then IP, then TCP — so the nesting is obvious and you can tell at a glance which layer a problem lives at.
- When a server logs the "wrong" client address, look for a NAT or proxy in the path, because under plain routing the source IP is preserved and only a deliberate rewrite changes it.
- Account for header overhead when sizing small messages or tunnels: subtract the stacked headers from the link MTU to get the real payload budget before something fragments.
- Use the per-hop-rewrite rule to localize faults — if layer-2 connectivity works but traffic to another subnet fails, suspect the layer-3 device, not the wire.
- Capture at both ends when a packet seems to vanish, since decapsulation only reveals what arrived; comparing the two captures shows which hop dropped or rewrote it.
Knowledge Check
A web server logs the source MAC address of an incoming request. Whose MAC will it see?
- Its last-hop router's MAC, because the layer-2 header is rewritten on every hop
- The original client's MAC, since MAC addresses travel end to end like IP addresses
- A MAC computed from the client's IP address
- No MAC at all, because the field is cleared once the packet leaves the local network
Under normal routing with no NAT, which header field changes as a packet crosses each router?
- The IP time-to-live, which each router decrements, while the source and destination IP stay constant
- The destination IP address, which each router updates toward the next hop each time the packet is forwarded onward
- The TCP source port, which each router reassigns to track the flow
- The application payload, which is re-encoded for the next link
Why can a plain layer-2 switch not deliver a packet to a host on a different subnet?
- It only reads the layer-2 MAC header and forwards within a segment; crossing subnets needs a layer-3 routing decision
- It is too slow to process packets destined for remote networks in time
- It strips the IP header right off the frame, so the destination network address is already lost long before forwarding
- It can only forward broadcast frames, never unicast ones
You got correct