The Layered Network Model — Study Notes

08 Apr, 2026

Based on Beej's Guide to Network Concepts, Chapter 4

The Internet Layer Model

Key Concepts & Insights

Encapsulation — Headers All the Way Down

As data travels down the layers before being sent, each layer wraps the data with its own header:

Application:  [ HTTP data ]
Transport:    [ TCP header | HTTP data ]
Internet:     [ IP header  | TCP header | HTTP data ]
Link:         [ ETH header | IP header  | TCP header | HTTP data ]

On the receiving end, each layer strips its header and hands the rest up.

Why IP Wraps TCP (Not the Other Way Around)

You need to reach the right machine before you can care about the right application. Routers only look at the IP header — they never peek inside TCP. If TCP wrapped IP, every router would need to unwrap TCP just to find where to forward the packet. Layering order follows the order of operations.

How a Router Decides Where to Forward

Routers use a routing table — a list of destination network prefixes mapped to next hops. The router matches the destination IP using longest prefix matching and forwards accordingly. If nothing matches, it falls back to the default route (0.0.0.0/0) — essentially "send it upstream."

TCP vs UDP — The Reliability Tradeoff

UDP is useful when stale data is worse than missing data — e.g. in a video call, you'd rather skip a frame than freeze waiting for a retransmit.

IPv4 vs IPv6 Address Space

• IPv4 = 4 bytes = 2^32 ≈ 4.3 billion addresses → nearly exhausted
• IPv6 = 16 bytes = 2^128 ≈ 340 undecillion addresses → effectively infinite

Randomly guessing a specific IPv6 address is ~2^128 to 1 odds — orders of magnitude harder than winning the lottery (~2^28 to 1). This is why IPv6 devices can self-assign addresses (SLAAC) without a central coordinator — collisions are practically impossible.

OSI Model (for interviews/certs)

The Internet model maps to the more granular OSI model:

Reflection Q&A

Q: When a router sees an IP packet, how does it know where to forward it? It consults its routing table, matching the destination IP using longest prefix matching. The most specific match wins. If nothing matches, it uses the default route to forward the packet upstream.

Q: If IPv4 is 4 bytes, how many addresses can it represent? 4 bytes = 32 bits → 2^32 ≈ 4.3 billion addresses. Sounds like a lot, but between phones, servers, and IoT devices, we've essentially exhausted them — hence IPv6.

Q: Same for IPv6's 16-byte addresses? 16 bytes = 128 bits → 2^128 ≈ 340 undecillion. Enough to assign addresses to every atom on Earth's surface many times over.

Q: What are the odds of randomly guessing a pre-selected 128-bit number? 2^128 to 1 — astronomically harder than winning the lottery (≈ 2^28 to 1). You'd need to win the lottery roughly 4-5 times in a row to match the same level of difficulty.

Q: Why does IP wrap TCP and not the other way around? Routing to the right machine (IP's job) must happen before worrying about ports and reliability (TCP's job). Routers only inspect the IP header — they don't care about TCP at all. The layering order reflects the real order of operations: get it to the machine first, then to the right application.

Q: If UDP is unreliable, why would anyone use it? When you need speed and latency matters more than perfect delivery. Streaming video, VoIP, and online gaming all prefer a dropped packet over a delayed one. DNS uses UDP too — it's a tiny single request/response where a full TCP handshake would be wasteful.

Further Questions

Q: What happens to an active connection when you switch to a VPN mid-session? Your source IP changes, so the old 4-tuple is now invalid. The server doesn't recognize incoming packets from the new IP — the connection dies. The browser silently reconnects through the VPN, forming a new 4-tuple. The ghost socket on the server gets cleaned up via RST, application timeout, or eventually TCP keepalive.

Q: How does a dead TCP connection get cleaned up? In order of speed:

• TCP FIN handshake — clean close, both sides free the socket immediately
• RST packet — server receives a packet with an unrecognized 4-tuple and resets the connection
• Application timeout — server closes idle sockets after X seconds (most practical)
• TCP keepalive — OS probes after inactivity; declares dead if no response (default ~2 hours, very slow)

Until cleanup, the ghost socket sits in the OS socket table consuming memory — SYN flood attacks exploit this by creating masses of half-open connections.

Q: Why do ports below 1024 require root privileges? They're well-known ports reserved for standard services (80=HTTP, 443=HTTPS, 22=SSH). The OS requires root to bind to them as a trust boundary — so a rogue process can't squat on port 80 and impersonate a web server. In production, the typical workaround is a reverse proxy (nginx on port 80 → your app on port 8080) rather than running everything as root.

Q: Does the new socket from accept() get assigned a new port? No. It reuses the same server port (e.g. 443). The OS distinguishes all clients using the full 4-tuple — so thousands of clients can connect to the same port simultaneously, each uniquely identified by their source IP and ephemeral port.

Extra Resources

• Beej's Guide to Network Concepts, Ch. 4 — Original chapter
• Beej's Guide to Network Programming — Deeper C-level sockets dive

Study session notes — Beej's Guide to Network Concepts, Chapter 4