Networking¶

Foundations (networking fundamentals — DNS, TCP/IP, routing, HTTP(S), SSH) · prereq 01 (DevOps Foundations) — this module gives the general-purpose networking mechanics that 05 (AWS) and 04 (Kubernetes & Helm) each specialize for their own platform. · ~1 day (4 reference submodules — IP addressing & subnetting, routing & gateways, DNS, and HTTP/TCP/SSH). Reality check: this is the 80/20 on-ramp; real fluency (packet capture, protocol debugging under load) is built on the job, one incident at a time.

Every module before this one assumed a request just "arrives" at your container, your Pod, your load balancer. It doesn't, by magic — it travels a real path: a name gets resolved to an address, a connection gets established, bytes get exchanged in a protocol both ends agree on. When that path breaks, "it doesn't work" is not a diagnosis. Knowing which layer failed — DNS, the TCP handshake, TLS, HTTP, or the SSH session you're debugging through — is what turns a guess into a fix.

TL;DR — in 30 seconds:

Every exchange answers three questions in order: where is it (addressing/CIDR), how do I get there (routing via the default gateway), what do we say once connected (DNS resolves the name first, then TCP/TLS connects, then HTTP or SSH talks).
A packet to a local address never touches the default gateway; anything outside the local network always routes through it.
"It doesn't work" isn't a diagnosis — name which layer failed (DNS, TCP, TLS, or the application protocol) before you try to fix it.

Learning objectives¶

By the end, the junior can:

Read an IPv4 address in CIDR notation and compute a subnet's network address, broadcast address, and usable host count.
Explain what a default gateway and a routing table actually do, and trace a packet's path from a host to a destination outside its local network.
Walk through the DNS resolution chain (recursive resolver → root → TLD → authoritative) and name the common record types (A/AAAA/CNAME/MX/TXT/NS).
Describe the TCP three-way handshake, where TLS sits on top of it, the anatomy of an HTTP request/response, and how SSH differs from both.
Trace, end to end, how a client request reaches a container — naming every hop from DNS lookup to the bytes landing on the container's listening port.

Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

1. Learn · acquire the concept¶

No external course — read this brief, then go deeper in the four reference pages below.

Mental model (20 minutes):

Every network exchange, no matter the protocol, answers the same three questions in order: where is it (addressing), how do I get there (routing), and what do we say to each other once connected (the application protocol).

flowchart LR
    A["Addressing<br/>IP + CIDR + subnets"] --> B["Routing<br/>gateways + routing tables"]
    B --> C["Naming<br/>DNS resolves a name to an address"]
    C --> D["Transport<br/>TCP handshake (+ TLS)"]
    D --> E["Application protocol<br/>HTTP · SSH · …"]

Addressing — an IPv4 address in CIDR notation (10.0.1.0/24) splits into a network portion and a host portion; the prefix length decides where that split falls, and thus how many usable hosts the range holds.
Routing — a host doesn't know how to reach every address on the internet; it only knows its default gateway and consults a small routing table to decide whether a destination is local or needs to go through that gateway.
Naming — humans use names, not addresses; DNS is the distributed, cached lookup that turns a name into the address routing actually uses.
Transport — before any application data moves, TCP runs a three-way handshake (SYN → SYN-ACK → ACK) to establish a reliable, ordered connection; TLS (when present) layers a second handshake on top of that to negotiate encryption.
Application protocol — HTTP(S) and SSH are two different conversations that both happen to run over TCP: HTTP is a stateless request/response exchange; SSH is an encrypted, interactive remote-shell session. Same transport, different purpose.

Go deeper: IP addressing & subnetting · Routing & gateways · DNS · HTTP, TCP & SSH

Read next: MDN's HTTP overview and Cloudflare's DNS guide (both linked above) — optional, not required to pass this module's gate.

Check yourself — your host needs to reach an address outside its local network. What decides whether the packet goes straight there or through the default gateway?

The routing table decides: if the destination falls inside the host's own local subnet, the packet goes straight there over the local network; if not, the routing table's fallback rule sends it to the default gateway, which is responsible for getting it anywhere else.

Check yourself — in curl -v output, where does the TCP handshake end and TLS begin, and where does TLS end and HTTP begin?

The TCP three-way handshake (SYN → SYN-ACK → ACK) completes before any data is exchanged; for HTTPS, the TLS handshake negotiates encryption immediately after that TCP connection opens; only once TLS finishes does the HTTP request/response headers become the first data exchanged over the now-open, now-encrypted connection.

Done when: you can name, in order, the five layers a client request crosses to reach a container (addressing → routing → DNS → TCP/TLS → HTTP), before moving to Pair.

2. Pair · passive → active¶

Drive the onboarding-tutor:

"Give me a CIDR block and quiz me on its network address, broadcast address, and usable host count."
"Walk me through why a packet to a local address never touches my default gateway, but one to a remote address always does."
"Quiz me on the DNS resolution chain — recursive resolver, root, TLD, authoritative — and the common record types."
"Explain exactly where the TCP handshake ends and the TLS handshake begins, then where HTTP starts."
"Give me a URL and make me trace, hop by hop, how a request to it would reach a container behind a load balancer — don't let me skip a step."

Common gotchas

Treating "ping works" as proof the service itself is reachable. Fix: ping only tests ICMP at the network layer — a firewall can allow ICMP while blocking the TCP port the service actually listens on, or the reverse. Test the real protocol (curl, nc) instead of stopping at ping.
Confusing "connection refused" with "connection timed out." Fix: refused means a packet reached the host and something actively rejected it at the TCP layer (usually nothing is listening on that port); timed out means no response came back at all — usually a firewall silently dropping the packet, or the route never getting there. They point at different fixes.
Assuming a DNS record change takes effect everywhere immediately. Fix: DNS is a cached resolution chain, not a live lookup each time — a resolver only re-queries once the previous record's TTL expires, so a change can take minutes (or longer) to be visible everywhere.
Diagnosing "it doesn't work" without naming which layer failed. Fix: read curl -v's own output — a hostname that never resolves is a DNS failure, "Connection refused" or a timeout is TCP, and a response with the wrong HTTP status is an application-layer failure. Fix the layer that actually failed, not the whole stack.

Done when: you can trace the full addressing → routing → DNS → TCP/TLS → HTTP chain unprompted, for a URL the tutor gives you.

3. Do · produce an artifact¶

Exercise — trace a real request:

Pick any URL you use daily (e.g. your own repo's remote, or a public site).
Run dig <domain> (or nslookup) and write down which record type answered and what it resolved to.
Run curl -v <url> and identify, in its output, where the TCP connection opens, where TLS negotiates (if HTTPS), and where the HTTP request/response headers appear.
Run traceroute <domain> (or tracepath/mtr if traceroute isn't installed) and note how many hops appear before you leave your local network (your default gateway is normally hop 1).
Write a short paragraph mapping each command's output to a layer from the Learn beat's diagram (addressing / routing / DNS / TCP+TLS / HTTP).

Done when: your paragraph correctly labels which tool exposed which layer, and you can point to the exact line in curl -v's output where the TCP handshake ends and the HTTP exchange begins.

4. Prove · understanding gate¶

Mandatory. Pass bar in the Socratic gate.

Addressing: Given a CIDR block, compute its usable host count and explain why AWS (or any cloud provider) reserves a handful of addresses per subnet rather than giving you every address on paper.
Routing: What decides whether your host sends a packet directly to its destination versus through the default gateway? What breaks if the default gateway is misconfigured?
DNS: Walk through the full resolution chain for a name that isn't cached anywhere yet, and name two record types other than A/AAAA and what each is for.
Transport & application: Where exactly does the TCP handshake end and TLS begin? Where does TLS end and the HTTP request begin? How is an SSH session different from an HTTPS one, given both run over TCP?
Provenance: You likely had the tutor walk you through at least one hop of your traced request (the DNS chain, or the TCP/TLS/HTTP boundary). Which specific claim did it make, and how did you verify it — against your own curl -v/dig output — rather than taking the tutor's explanation on trust?

Pass bar: you can defend each layer with the underlying mechanism (why a route is chosen, why a handshake happens before data, what a DNS record actually returns) — not just name the acronym — and show how you checked a tutor-supplied claim against your own command output. "DNS resolves it" or "TCP handles it" without the how = back to Pair.

5. Retain · fight forgetting¶

This module has no generated Anki deck yet — recall by re-reading the four reference pages and re-running the Do exercise's commands against a different URL until the addressing → routing → DNS → TCP/TLS → HTTP chain comes back to you unprompted. Done when you can trace that full chain, cold, for any URL someone hands you.

Key takeaways¶

Every network exchange answers three questions in order: where is it (addressing), how do I get there (routing), and what do we say once connected (the application protocol) — naming (DNS) and transport (TCP/TLS) sit between routing and the application layer.
CIDR notation splits an IPv4 address into a network portion and a host portion; the prefix length decides the usable host count, which is why a cloud provider reserves a handful of addresses per subnet rather than handing out every address on paper.
A host only consults its default gateway and local routing table — a packet to a local address never touches the gateway, but anything outside the local network always routes through it.
DNS is a resolution chain (recursive resolver → root → TLD → authoritative), not a single lookup; A/ AAAA/CNAME/MX/TXT/NS each answer a different question about a name, not just "what's the address."
The TCP three-way handshake (SYN → SYN-ACK → ACK) establishes the connection before any data moves; TLS, when present, layers a second handshake on top of that to negotiate encryption before HTTP's request/response exchange begins.
HTTP(S) and SSH both ride on TCP but are different conversations — HTTP is stateless request/ response, SSH is an encrypted interactive remote-shell session — so one working says nothing about whether the other will.

Go deeper — curated resources¶

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

Book · High Performance Browser Networking — Ilya Grigorik. TCP, TLS, HTTP and DNS explained brilliantly from the ground up; the full text is free on the web. Free online.
Docs · Beej's Guide to Network Programming — Beej Jorgensen. The friendliest introduction to sockets there is — how a connection is actually made, byte by byte. Free online.
Video · How the Internet Works — Ben Eater. A superb from-first-principles video series that builds the whole stack up one layer at a time. Free.
Blog · wizardzines — Julia Evans. Illustrated, intuition-first mental models for DNS and networking (free posts plus paid zines). Free.
Book · Computer Networking: A Top-Down Approach — Kurose & Ross. The standard university text, with free companion material (Wireshark labs, animations) on the authors' site. Paid.

Gate log (mentor fills on pass)¶

Date passed:
Passed by: / checked by:
Weak spots noticed (feeds system improvement):