Follow a Web Request Through Every Layer

Here is the full ladder before we walk it. Notice how it is symmetric: the client side *adds* layers going down, the network *rewrites* only the outer ones, and the server side *removes* layers going up. The application data at the bottom of the client stack is bit-for-bit the data at the top of the server stack. Everything between is packaging.

Keep three facts in mind while reading. The IP header’s source and destination addresses do not change end to end — unless a NAT rewrites them, which is exactly why NAT is a special case worth its own lesson. The Ethernet header is rewritten at every router — it only ever names the next machine on the current link. And TCP state lives only at the two ends: no router in the middle knows or cares that a connection exists.

The browser has already resolved engineer-atlas.dev to, say, 203.0.113.10 and chosen a family. It asks for a socket: socket(AF_INET, SOCK_STREAM, 0) returns a file descriptor — an integer, say fd 37, indexing a per-process table whose entry points at a kernel socket object with two buffers behind it. connect(fd, 203.0.113.10:443) is the moment the kernel allocates an ephemeral source port (e.g. 54001 from Linux’s 32768–60999), creates a TCP control block in state SYN_SENT, and emits a SYN. connect() blocks (or, in non-blocking mode, returns EINPROGRESS) until the SYN-ACK arrives and the state becomes ESTABLISHED.

After TLS, the browser calls write(fd, buf, n) with the encrypted request. The system call copies the bytes into the socket’s send buffer (default ~16 kB growing to megabytes under autotuning on Linux) and returns. The application is done; nothing has left the machine yet. TCP now owns those bytes: it cuts them into segments no larger than the MSS (1460 bytes on a 1500-byte-MTU IPv4 path), stamps each with the next sequence number, the current acknowledgment number, a window, flags, and both ports, and keeps a copy until the peer acknowledges it. Sending is gated by the smaller of the receiver’s advertised window (rwnd) and the local congestion window (cwnd).

This is where the connection *is*. The kernel’s TCP control block — ESTABLISHED, the 4-tuple, snd.nxt, snd.una, rcv.nxt, the two windows, the RTT estimate and the retransmission timer — is the entire state of the conversation on this side. Routers hold none of it.

Each segment is handed to IP, which prepends a 20-byte IPv4 header (40 bytes for IPv6): source 10.0.0.4, destination 203.0.113.10, protocol 6 (TCP), TTL 64, total length, a header checksum. Then IP consults the routing table. 203.0.113.10 is not within 10.0.0.0/24, so the route is default via 10.0.0.1 dev wlan0 — the packet must go to the gateway, out of the Wi-Fi interface. The destination IP in the header stays 203.0.113.10; the *next hop* is a separate decision.

To reach 10.0.0.1 on the local link, the link layer needs its MAC address. The ARP cache (IPv4) or neighbor cache (IPv6) either has it or a broadcast who-has 10.0.0.1? fetches it. A 14-byte Ethernet (or the longer 802.11) header is prepended: source MAC = this laptop’s interface, destination MAC = the gateway’s MAC, EtherType 0x0800 (IPv4) or 0x86DD (IPv6). The frame is placed in a transmit ring in memory; the NIC reads it by DMA, appends a 4-byte frame check sequence, and serialises it as bits — or, on Wi-Fi, contends for airtime, encrypts with the network key, and transmits, retrying itself on a lost acknowledgment.

A switch receives the frame, reads only the destination MAC, looks it up in its MAC learning table, and copies the frame out of the one port where the gateway lives (or floods it to all ports if it has never seen that MAC). It decrements nothing, rewrites nothing, and has no concept of IP. To a switch the packet is opaque cargo with a label.

The home router receives the frame addressed to *its* MAC, strips the Ethernet header, and looks at the IP header for the first time. It decrements TTL 64 → 63 (if it hit 0 it would drop the packet and send back ICMP *Time Exceeded* — the mechanism traceroute exploits), recomputes the IP header checksum, and looks up 203.0.113.10 in its own table: default via <ISP gateway> dev ppp0. Before forwarding it does one thing no ordinary router does: NAT. It rewrites the source 10.0.0.4:54001 to its public 198.51.100.7:62014, records the mapping in its translation table, and fixes up the IP and TCP checksums. Then it builds a *new* link header for the ISP-facing interface and sends.

Every subsequent router repeats the same three moves and none of the special ones: strip link header, TTL−1, longest-prefix lookup, new link header for the next hop. The destination IP is read at every hop and written at none. The TCP header is not even looked at — a core router forwards on the 20-byte IP header alone, in hardware, at hundreds of millions of packets per second. Somewhere the packet crosses from your ISP’s autonomous system into a transit provider’s and then into the hosting provider’s, along a path those networks agreed to via BGP. Nobody chose the path in advance; each AS chose its own exit.

Two things are worth tracing in your head: the TTL is a countdown that started at 64 and will read, say, 51 on arrival — the server can infer ~13 hops. And the MAC addresses in the frame that arrives at the server have nothing to do with your laptop; they belong to the last router and the server’s NIC.

At the hosting provider’s edge the packet is very likely steered by a load balancer. An L4 balancer forwards it (possibly rewriting the destination to a backend’s private IP — a second NAT); an L7 balancer *terminates* the TCP connection and TLS entirely and opens a fresh connection to a backend — in which case the "server" your client shook hands with is the balancer, and the backend sees a request from the balancer’s IP with your address tucked into an X-Forwarded-For header.

On the final host the NIC writes the frame into a receive ring by DMA and raises an interrupt (or is polled under load). The kernel checks the destination MAC is its own, strips the link header, validates the IP header, sees protocol 6, and hands the segment to TCP, which demultiplexes on the 4-tuple (198.51.100.7, 62014, 203.0.113.10, 443): a lookup in a hash table of established sockets. If it is a SYN with no match it goes to the *listening* socket on port 443 instead and enters the accept queue. Data in sequence is appended to the socket’s receive buffer; an ACK is scheduled; out-of-order data is held aside.

The server process was asleep in epoll_wait() (or accept(), or recv()). The kernel marks the descriptor readable and wakes the thread. read(fd, buf, n) copies the bytes out of the receive buffer into the process’s memory — the *second* copy of the journey, mirroring write() on the client. The TLS library decrypts; the HTTP parser sees GET / HTTP/2; your handler runs. Every step of the ladder now runs in reverse for the response, with the server’s kernel as the sender and your laptop’s as the receiver — and the NAT translating the destination back to 10.0.0.4:54001 from the mapping it recorded on the way out.

Summarise the journey by field. This table is the answer to the interview question "what changes in a packet as it crosses the internet?", and it is also the map for debugging: a field that should not change but did means something in the middle is not a plain router.