Networking Fundamentals — The Guide for Developers

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.

Names: DNS #

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."

Connections: TCP and UDP #

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.

Security: the TLS handshake #

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.

Getting to the app: proxies and load balancing #

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.

Speed at the edge: CDNs #

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 mental model #

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.

The call we'd make #

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.