Learn Networking

Basic

Start here. The ideas everything else is built on, from the first command.

• What Happens When You Hit Enter: One URL, four conversations: DNS, TCP, TLS and HTTP, what each one costs, and which one failed when the page does not load. (about 30 minutes)
• The OSI Model: Build a packet from the bottom up, one header per problem, then use the same ladder to find which layer is broken. (about 30 minutes)
• IP, Subnets & CIDR: An address is a network number and a host number. The mask decides which is which, and every host uses it to choose between a neighbour and a router. (about 30 minutes)
• DNS Resolution: One question from your laptop, a walk from the root down by the resolver, and caches at every level that decide what you see. (about 34 minutes)

Intermediate

What you need to run it for real: the moving parts and the ways they fail.

• Routing & NAT: Routers pass a packet along one decision at a time, and NAT lets a whole private network borrow one public address. (about 35 minutes)
• TCP Handshakes & Reliability: The network loses packets and tells nobody. TCP is how two machines get every byte across anyway. (about 32 minutes)
• TLS & HTTPS: How two strangers agree on a secret while everyone listens, and how the client knows who it is talking to. (about 32 minutes)
• HTTP/1.1 vs 2 vs 3: One page is many requests. Three versions of HTTP, three answers to where those requests queue and what one lost packet costs. (about 32 minutes)
• WebSockets: HTTP can only answer. A WebSocket turns one TCP connection into a line both ends may speak on, and you have to keep that line alive. (about 30 minutes)

Advanced

Production depth: hardening, recovery and the trade-offs behind the design.

• Load Balancers: L4 vs L7: One address in front of many servers: spreading connections at layer 4, understanding requests at layer 7, and what each one does when a server dies. (about 35 minutes)
• Firewalls & Packet Filtering: An ordered list of rules and a default: first match wins, a drop is a timeout, a reject is a refusal, and state is why replies get back in. (about 35 minutes)

See what really happens on the network

Networking problems are hard because they are invisible. A page loads slowly, a connection times out, a name does not resolve, and the only clues are a few lines of output. These lessons make the network visible: every packet is drawn as it crosses each hop, with its headers, so you can watch DNS, TCP, TLS and HTTP do their work.

You start with what an IP address and a subnet are, then follow a request from a laptop to a website: ARP, routing and NAT, a DNS lookup through the resolver hierarchy, the TCP handshake and congestion control, a TLS handshake and its certificate chain, HTTP/1.1, HTTP/2 and HTTP/3 over QUIC, load balancers, firewalls and WebSockets. Then you break each layer on purpose: drop packets, block a port, expire a certificate, poison a DNS record, and fix it with the same tools engineers use, such as dig, ping, traceroute, ss, curl and tcpdump-style views.

Understanding the network this way is the foundation for Kubernetes networking, for debugging production outages, and for the networking questions that come up in every system design interview.

After these lessons you can

• Read an IP address, a subnet and a routing table, and explain where a packet will go
• Follow a DNS lookup from the stub resolver to the authoritative server, and read dig output
• Explain the TCP handshake, retransmissions and congestion windows from a live trace
• Debug TLS and certificate errors, and explain what HTTPS actually protects
• Compare HTTP/1.1, HTTP/2 and HTTP/3, and say when QUIC helps
• Find where a connection fails: DNS, routing, a firewall, the load balancer or the application

Who it is for

Developers who want to understand what happens after they call fetch(), engineers moving into DevOps, SRE or networking roles, and anyone preparing for system design or Kubernetes networking.

Common questions

Do I need to know networking already?

No. The first lessons start from what an address and a subnet are. Each later lesson builds on the one before it.

Are these real protocols or a simplified model?

The simulation follows the real protocols closely enough to recognise on a real network: real header fields, real handshakes, real dig, curl and ss output. Where something is simplified, the lesson says so.

How does this help with Kubernetes?

Kubernetes networking is ordinary networking: Services are NAT and load balancing, cluster DNS is DNS, Ingress is HTTP routing. The Kubernetes lessons link back to these when they rely on them.