Networking & protocols

Networking sounds academic until an app "can't connect" and you're the one who has to find out why. The OSI model is the shared vocabulary; in practice you care about a few layers.

Every machine has an IP address. Subnets and CIDR notation (10.0.1.0/24) define ranges of addresses that can talk to each other directly — this is the backbone of every cloud network (VPCs). The /24 means the first 24 bits are the network, leaving 256 addresses.

On top of IP sit two transport protocols:

• TCP — reliable, ordered, connection-based. Used by HTTP, SSH, databases. It does a "three-way handshake" (SYN, SYN-ACK, ACK) before sending data.
• UDP — fire-and-forget, no guarantees, low latency. Used by DNS, video, gaming.

Ports let one machine run many services: HTTP is 80, HTTPS 443, SSH 22, PostgreSQL 5432. An address like 10.0.1.5:443 means "port 443 on that host."

DNS turns names into IP addresses. The records you'll touch constantly:

• A / AAAA — name → IPv4 / IPv6 address.
• CNAME — name → another name (an alias).
• MX — mail servers; TXT — arbitrary text, used for domain verification and SPF/DKIM.

Changes take time to propagate because records are cached for their TTL. Debug with dig example.com or nslookup.

HTTP is the language of the web — a simple request/response text protocol. A request has a method (GET, POST, PUT, DELETE), a path, headers, and an optional body. A response has a status code you must know by heart:

• 2xx success · 3xx redirect · 4xx you (the client) messed up (404 not found, 401 unauthorised) · 5xx the server messed up (500, 502 bad gateway, 503 unavailable).

HTTPS is just HTTP inside TLS encryption. TLS uses certificates to prove identity and to set up an encrypted channel, so nobody between the user and server can read the traffic. Expired certificates are a classic outage — automate their renewal (Let's Encrypt).

One server is a single point of failure and a scaling ceiling. Load balancers solve both by spreading incoming requests across many identical servers and quietly removing any that fail a health check.

There are two flavours you'll hear about:

• Layer 4 (transport): balances by IP/port, fast and protocol-agnostic.
• Layer 7 (application): understands HTTP, so it can route by URL path or hostname (/api → API servers, everything else → the web app). This is what tools like NGINX, HAProxy, and cloud ALBs do.

A reverse proxy sits in front of your app and can also terminate TLS, cache responses, compress output, and rate-limit abusers. NGINX is the classic example and worth configuring once by hand.

Firewalls (and their cloud cousin, security groups) decide which traffic is allowed in and out. The rule of thumb is default-deny: block everything, then open only the specific ports you need (443 to the world, 22 only from your office/VPN).

Between your user and your server sit several layers whose job is speed and control. Knowing which is which matters when things break.

A forward proxy sits in front of clients (an outbound gateway for a corporate network). A reverse proxy sits in front of servers — this is the one you'll operate. It receives every request and decides what to do: route it, terminate TLS, compress, cache, rate-limit, or block it. NGINX, HAProxy, Envoy, and Traefik all do this.

A CDN (Cloudflare, CloudFront, Fastly) is a reverse proxy replicated to hundreds of locations worldwide. It serves cached content from a PoP physically near the user, which slashes latency and absorbs traffic spikes and DDoS attacks before they reach you.

The key concept is caching, governed by HTTP headers: Cache-Control: max-age=3600 says "reusable for an hour." Static assets (images, JS, CSS) should be cached hard and given hashed filenames so a new deploy busts the cache automatically. Dynamic, user-specific responses must not be cached — leaking one user's page to another is a classic, embarrassing outage.

Knowing networking theory is useless if you can't diagnose. This is the toolkit, and — more importantly — the order you use it in. Work up the stack:

1. Is DNS resolving? dig example.com +short — do you get the IP you expect?
2. Is the host reachable? ping 10.0.1.5 (note: many hosts block ICMP, so a failed ping isn't proof of death).
3. Is the port open? nc -vz 10.0.1.5 443 or nmap -p 443 host. This distinguishes "server down" from "firewall blocking."
4. Is the app answering correctly? curl -v https://host/health — shows DNS, TLS, headers, and the response in one shot.
5. Is the service even listening? On the box itself: ss -tulpn lists listening sockets and which process owns them.
6. What's actually on the wire? tcpdump -i any port 443 when you truly need to see packets.

Also learn traceroute (where does the path die?) and mtr (continuous traceroute — brilliant for intermittent loss).

The discipline is refusing to guess. Each command eliminates one layer, so you converge on the truth in minutes rather than restarting things and hoping.