Networking

Every distributed system, web app, and API rests on networking — the protocols and infrastructure that move data between machines across the internet. Most developers work several layers above the wire, thinking in HTTP requests rather than packets, and that abstraction usually holds. But the moment something breaks — a mysterious latency spike, a DNS outage, a connection that won't establish, a load balancer routing wrong — the underlying networking knowledge becomes essential. Understanding the stack turns baffling errors into diagnosable ones.

This hub covers the foundations from the wire up: the TCP/IP stack that routes and delivers data, DNS that resolves names, HTTP that the web speaks, and the load balancing infrastructure that makes services scalable and reliable.

TL;DR

The Networking Stack

A single web request touches the whole stack:

Each layer builds on the one below — and a failure at any layer surfaces as "the site is down."

Featured Topics

Network Protocols

HTTP & Web APIs

Real-Time Communication

Infrastructure & Load Balancing

Common Questions

What actually happens when I load a web page?

A cascade through the networking stack. Your browser first resolves the domain to an IP via DNS (checking caches, then recursive/authoritative servers). It then opens a TCP connection to that IP and port (443 for HTTPS), negotiates TLS encryption, and sends an HTTP request. A load balancer may pick which backend server answers. The server returns an HTTP response (status code + headers + body), the browser renders it, and fetches further resources the same way. Each step is a layer building on the one below — which is why a failure anywhere (DNS, TCP, TLS, HTTP) presents as "the page won't load."

When should I use TCP vs UDP?

Use TCP for anything that must arrive complete and in order — web traffic, APIs, email, file transfer — which is the vast majority of applications; it handles reliability and ordering for you at the cost of some latency. Use UDP when low latency matters more than perfect delivery and you can tolerate occasional loss: live video and voice, online gaming, and small stateless queries like DNS. A useful sign you've chosen wrong: if you pick UDP and then start adding retransmission and ordering by hand, you're reimplementing TCP — either use TCP, or use QUIC (which adds reliability over UDP and powers HTTP/3). See TCP/IP.

Why are DNS and load balancers such common causes of outages?

Because both sit on the critical path of every request and are easy to under-attend. DNS failures — an expired domain, a bad record, a too-aggressive TTL change, or a single-provider outage — make services unreachable even when servers are healthy, since names can't resolve. Load balancer misconfigurations (no health checks, bad routing, a single non-redundant balancer) can send traffic to dead servers or become a single point of failure themselves. Both are invisible when working and dramatic when they fail. Mitigate with redundancy (multi-provider DNS, balancers across availability zones), health checks, and monitoring of these critical dependencies.

How do I scale a web service to handle more traffic?

Horizontally, behind a load balancer: run multiple stateless application servers and let the balancer distribute requests across them, adding servers as load grows rather than buying one bigger machine. Keep the servers stateless (session/state in a shared store like Redis) so any server can handle any request, which also enables failover and zero-downtime deploys. Spread servers across availability zones for resilience, health-check them so failures route around automatically, and add caching and database scaling for the tiers behind them. This load-balanced, stateless, horizontally-scaled pattern is the backbone of scalable web architecture. See Scalability Patterns.

Related Hubs