The Stack Below Your Stack: The Network Stack That Powers the Entire Internet
Introduction
Every time you open a browser, stream a video, or send a message — your code is just the tip of the iceberg. Underneath it, four layers of protocols have been silently doing the heavy lifting. This is a breakdown of that stack: what each layer does, which protocols live where, and how it all plays out in systems you use every day.
The Network Protocol Stack
The OSI/TCP-IP model is the actual contract the internet runs on. Not a concept — a working agreement between every device on the planet.
Layer 5–7 is where you live as a developer. HTTP, HTTPS, SSH, DNS, SMTP, MySQL — protocols that understand what the data means. Everything above this line is your problem. Everything below it is infrastructure you're renting.
Layer 4 is the enforcer. This is where the TCP vs UDP decision lives, and it's one of the most consequential choices in any system you'll build. TCP is a contract — handshake, ordered delivery, retransmission on loss. You pay for all of that in latency. UDP is a calculated gamble — no handshake, no guarantee, just packets sent with the assumption that fast and mostly correct beats slow and perfect. Every protocol choice you make at the application layer flows from this one decision.
Layer 3 stops caring about meaning and starts caring about address. IPv4, IPv6, ICMP — this is the routing layer. Packets get stamped with source and destination IPs and handed off to a chain of routers that move them across the planet. No router in that chain knows what HTTP is. It only knows addresses.
Layer 2 narrows scope to a single network segment. MAC addresses, Ethernet frames, Wi-Fi — node-to-node, not end-to-end. ARP lives at this boundary, bridging the gap between IP addresses above and MAC addresses below.
Layer 1 is just physics. Copper, fiber, radio waves. 0s and 1s as electrical signals or light pulses. No abstraction. Just the medium.
The architectural genius of this whole model is enforced ignorance — each layer is completely blind to the implementation details of its neighbors. HTTP doesn't know what a MAC address is. Ethernet doesn't know what a webpage is. That separation of concerns is why a protocol invented in the 70s still runs under your web app.
Transport - Application Mappings
Every protocol maps to a port, and every port reflects a decision: can this application tolerate data loss, or can it tolerate delay?
TCP owns everything where data loss is unacceptable. HTTP/80, HTTPS/443, SSH/22, SMTP/25 and 587, IMAP/143, MySQL/3306, PostgreSQL/5432 — if dropping a single byte breaks the application, it runs on TCP. A missing line of SQL, a corrupted SSH session, half an email — none of these are recoverable at the app layer, so TCP handles recovery at the transport layer.
UDP owns everything where latency is unacceptable. DNS/53 resolves a hostname in a single round-trip — a TCP handshake before every DNS query would be absurd overhead. DHCP/67-68 uses UDP because a device requesting an IP address doesn't have one yet, making a TCP handshake literally impossible. RTP/5004-5005 carries real-time audio and video — a retransmitted packet that arrives 200ms late is worse than no packet at all. HTTP/3 on 443 is the modern plot twist: it runs over QUIC, which is UDP-based, because TCP's head-of-line blocking was too expensive for modern web performance.
Then there's the hybrid zone, where nuance lives. DNS uses UDP for small queries and falls back to TCP for large responses. SIP uses UDP for low-latency call signaling but switches to TCP when reliability matters. LDAP prefers TCP for queries but UDP for broadcast discovery. These protocols didn't pick a side — and understanding why is more useful than memorizing which they chose.
Real World Full-stack Examples
This is where it all clicks. The same stack, the same tradeoffs — just with real systems you recognize.
The Bigger Picture
The deeper you go into this stack, the more you realize the internet isn't one system — it's a series of independent contracts, each one solving exactly one problem and trusting everything else to handle its own. No single layer knows the full picture, and that's not a bug. That's the design. When something breaks in production and you're staring at a timeout you can't explain, this is the map you reach for. Start at Layer 7 and work your way down until the layer that broke reveals itself. It always does.
P.S. The diagrams were made with AI. The understanding had to come first.