Networking basics

Between hitting Enter on a URL and a webpage appearing, six different protocols negotiate in under a second: DNS, TCP, TLS, HTTP, and a couple of friends. Once you have a model of those layers, every infra conversation — load balancers, firewalls, CDNs — becomes mappable to specific layers.

The big idea

Networking is layered, and each layer adds one capability the one below didn't have. The trick to learning it is not memorising OSI's seven layers — it's understanding the four you actually touch.

A request, layer by layer

When you type https://example.com in a browser:

1. 1

   DNS resolution

   Your machine asks a recursive resolver for the A/AAAA records of example.com. Cached almost everywhere — DNS is mostly a cache hierarchy with a tiny authoritative base at the bottom.

2. 2

   TCP handshake

   Your client sends SYN, the server replies SYN-ACK, you send ACK. One round trip before you can send any data.

3. 3

   TLS handshake

   The server presents a certificate; your client verifies it chains to a trusted CA. Asymmetric crypto establishes a shared session key, then everything switches to fast symmetric encryption.

4. 4

   HTTP request

   Finally the real conversation happens — over an encrypted TCP stream.

TCP vs UDP

The reliability/cost trade-off:

Ports, sockets, processes

A port is just a 16-bit number used by the OS to route a packet to the right process. A socket is the OS-level handle for one connection: (local_ip, local_port, peer_ip, peer_port). A web server listens on (0.0.0.0, 443); for each incoming connection, the OS creates a new socket with a unique peer side.

TLS in 30 seconds

Every TLS connection achieves three things at once:

Confidentiality

Nobody between you and the server can read the traffic.

Integrity

Nobody between you can modify it without detection.

Authentication

The server proves it's the legitimate owner of the domain via a certificate signed by a CA.

Modern TLS (1.3) cuts the handshake to one round trip, drops weak ciphers, and is what you should be running. Anything older is a known bug.

Useful tools

# DNS — which IPs is example.com on?
dig +short example.com
host -t AAAA example.com
 
# What's actually listening on this box?
ss -tlnp                  # Linux
lsof -nP -iTCP -sTCP:LISTEN -p 0
 
# Reach the server at all?
nc -zv example.com 443
curl -v https://example.com    # full TLS + HTTP trace
 
# What route do packets take?
traceroute -T -p 443 example.com

In practice

A surprising number of "the API is down" tickets are really DNS (resolver cache, expired record), TLS (expired cert, wrong SNI), or firewalls (port closed in a new VPC). Walk the layers top-down: HTTP → TLS → TCP → DNS. The first one that fails is your bug.