Networking Fundamentals — The Guide for Developers
KU
Kiril Urbonas
20 hours ago • 3 min read•0 views
You don't need a CCNA to ship reliable services, but you do need the core ideas. This is the map: DNS, TCP, TLS, proxies, and CDNs, minus the jargon.
Most bugs that look mysterious are networking bugs wearing a costume: a slow first request is DNS, a hung connection is TCP, a "your connection is not private" is TLS, and a 502 is usually a proxy. You do not need a networking certification to ship reliable services, but you do need the core mental models. This guide is the map: what each piece does, how it fits the request path, and where to go deep, minus the jargon.
Follow a single request and you touch every layer. Type a URL, and your machine resolves the name (DNS), opens a connection (TCP), secures it (TLS), and the bytes travel through proxies, load balancers, and maybe a CDN before an app ever sees them. Understanding that path is 80% of debugging production.
Before anything connects, the human-friendly name has to become an IP address. That lookup, its caching, and why a stale record ruins your day is in how DNS works. It is the first thing to suspect when something is "slow to start" or "works on my machine."
Once you have an address, you need a connection. The two transport protocols make opposite trade-offs: TCP is reliable and ordered (the default for web, APIs, databases); UDP is fast and lossy (DNS, video, games, QUIC). Which to use and why is in TCP vs UDP.
That padlock is a negotiation. Before encrypted bytes flow, client and server agree on keys and verify a certificate, and when that negotiation fails you get the scary browser warning. The step-by-step is in how the TLS handshake works, which pairs with the response-side controls in HTTP security headers.
Real traffic rarely hits your app directly. A reverse proxy sits in front to terminate TLS, route, and buffer, set up in how to set up an Nginx reverse proxy. When you have many backends, a load balancer spreads traffic across them using an algorithm, compared in load balancing algorithms explained. The difference between a proxy, a reverse proxy, and a load balancer is untangled in proxy vs reverse proxy vs load balancer.
For static assets and cacheable responses, a CDN serves copies from locations near the user, cutting latency and origin load. What it is and how it works is in what is a CDN; the operational side of keeping caches fresh is in CDN cache invalidation strategies.
The request path is a pipeline: resolve (DNS) → connect (TCP) → secure (TLS) → route (proxy/LB) → serve (origin or CDN). When something breaks, walk the pipeline in order and the layer reveals itself: name won't resolve (DNS), connection hangs (TCP/firewall), cert error (TLS), 502/504 (proxy/backend), stale content (CDN cache). Each stage has a tool: dig for DNS, curl -v and ss for connections, openssl s_client for TLS.
Learn the request path once and networking stops being magic. You do not need every RFC; you need to know which layer owns which symptom and which command inspects it. Start with DNS and TLS (the two that cause the most "it's slow / it's broken" reports), then proxies and CDNs as your traffic grows. Each linked guide goes deep on one layer; read them in request-path order and the whole stack clicks into place.
Get the latest tutorials, guides, and insights on AI, DevOps, Cloud, and Infrastructure delivered directly to your inbox.
Explore more articles in this category
A developer-focused walkthrough of the TLS 1.3 handshake, certificate trust, forward secrecy, and how to debug the errors you actually hit.
A practical, step-by-step guide to putting Nginx in front of your app for TLS, routing, and load balancing.
A practical tour of the core load balancing algorithms, how each distributes traffic, and when to reach for one over another.
Evergreen posts worth revisiting.
