Computer networks, end to end

Every backend engineer has had a 4 AM incident where the issue was DNS, or TLS, or a connection pool exhausting under load. Most of them did not learn networking properly, so they paged a more senior engineer who did. This module makes you that senior engineer.

You will not learn the full OSI seven-layer model. The four layers that actually matter — link, internet, transport, application — plus DNS as a special citizen, are enough for 95% of working engineering. The other 5% you’ll learn in context when you need it.

The opinionated take: most “networking” failures are DNS or TLS, not code. Internalize that bias and you will diagnose problems in minutes that take less-experienced engineers hours.

Set up

Most of what follows uses tools you already have or can install in two minutes.

# Linux
sudo apt install curl dnsutils netcat-openbsd tcpdump wireshark openssl

# macOS
brew install curl bind netcat tcpdump wireshark openssl

Verify:

curl --version && dig +short google.com && echo | openssl s_client -connect google.com:443 2>/dev/null | head -3

Make a project:

mkdir net && cd net
uv venv .venv && source .venv/bin/activate
mkdir server traces notes

Read these first

In this order:

1. Kurose & Ross — Computer Networking: A Top-Down Approach. book site · 6–8 hours · chapters 1–3 (intro, application, transport) are required. Top-down is the right mental model for application engineers.
2. High Performance Browser Networking (Ilya Grigorik). free online · 2–3 hours · the most useful applied networking book. Chapters 1–4 and the HTTP chapters.
3. Beej’s Guide to Network Programming. free site · 1–2 hours · the practical sockets tutorial. Required if your sockets feel rusty.
4. The TLS 1.3 RFC, just §1 and §2. RFC 8446 · 30 minutes · for the canonical handshake.
5. The HTTP/1.1 RFC, request line and headers. RFC 9110 · 30 minutes · just enough to parse a request.

After Kurose chapter 3 and HPBN chapters 1–2 you have most of what you need. Stop reading. Start packet-watching.

What happens when you type a URL?

The interview question. Answer it in real depth, in this order:

1. DNS. Browser checks its cache, then OS resolver cache, then sends a UDP query to the configured DNS server. Recursive resolution: root → TLD (.com) → authoritative server for the domain. Result is one or more IP addresses.
2. TCP handshake. SYN, SYN-ACK, ACK. Three packets, one round trip.
3. TLS handshake. TLS 1.3 takes one additional round trip. ClientHello (cipher suites, key share), ServerHello + certificate, Finished. Now both sides have shared session keys.
4. HTTP request. GET / HTTP/1.1\r\nHost: google.com\r\n\r\n (encrypted under TLS). Server responds with status line, headers, body.
5. Render. Browser parses HTML, kicks off subresource fetches (each with its own DNS / TCP / TLS, possibly reused). JavaScript runs.

The timeline for a cold load on a fast connection: DNS in under 50 ms, TCP in one RTT (say 30 ms), TLS in one RTT (another 30 ms), first HTTP byte in another RTT. So the absolute floor for a cold cross-continental fetch is around 120–200 ms before the server even starts thinking. This is why CDNs exist.

The five-layer model

You will see the OSI 7-layer model in textbooks. The TCP/IP 5-layer model is what working engineers actually use:

Layer	What it does	Examples
Application	Your protocol semantics	HTTP, gRPC, SMTP, DNS
Transport	End-to-end reliability or unreliability	TCP, UDP, QUIC
Internet	Routing across networks	IP, ICMP
Link	One hop on a physical or virtual link	Ethernet, Wi-Fi 802.11
Physical	Bits on a wire / air	copper, fiber, radio

DNS deserves a footnote: it’s an application protocol that everything else depends on. When DNS breaks, the rest of the stack looks broken.

TCP, deeply enough

TCP gives you three things UDP doesn’t: reliability, ordering, and congestion control. The mechanisms are worth knowing because they bite.

• 3-way handshake. SYN (seq=x), SYN-ACK (seq=y, ack=x+1), ACK (ack=y+1). One RTT before any data flows. This is why HTTP keep-alive is so important.
• Retransmits. TCP measures RTT, sets a retransmit timeout, and resends unacknowledged segments. Spurious retransmits hurt throughput.
• Sliding window. Both sides advertise a receive window. Throughput is bounded by window / RTT. On a 100 ms RTT with a 64 KB window, max throughput is 640 KB/s — which is why window scaling exists.
• Congestion control. Slow start, congestion avoidance, fast recovery. Modern stacks use BBR, CUBIC, or Reno. The relevant fact: a single packet loss can collapse a TCP flow’s throughput for seconds.

Capture a real handshake to see all of this:

# Linux
sudo tcpdump -n -i any -w handshake.pcap 'host example.com and port 443' &
curl https://example.com >/dev/null
sudo killall tcpdump
wireshark handshake.pcap

Twenty minutes in Wireshark teaches you more about TCP than a chapter of any book.

UDP and when to use it

UDP is “send a datagram, hope it arrives.” No handshake, no retransmit, no order. Use it when you need:

• Low-latency real-time (voice, video, games) where a late packet is worse than a missing one.
• Multicast / broadcast that TCP can’t do.
• Your own reliability layer (QUIC, DNS, NTP).

The most relevant modern UDP user is QUIC — the transport under HTTP/3. QUIC re-implements TCP’s reliability features in user space, on top of UDP, with TLS baked in and 0-RTT resumption. It exists because TCP is calcified into operating systems and middleboxes.

TLS, the handshake you must read

TLS does three jobs at once: confidentiality, integrity, and authentication of the server (and optionally the client). The TLS 1.3 handshake (the version you should care about; 1.2 is deprecated for new use) is one round trip:

1. ClientHello. Supported versions, cipher suites, list of named groups (key-share offers).
2. ServerHello + Certificate + Finished. Server picks a cipher, sends its certificate chain, finishes the handshake. Application data can now flow.

The certificate chain is what gets you confused at 2 AM. The browser walks: leaf cert → intermediate(s) → root in the OS trust store. If any link is missing, you get the dreaded “certificate not trusted” warning. The fix is almost always the server isn’t sending the intermediate, not “the cert is wrong.”

Tooling:

# What does the server actually send?
echo | openssl s_client -showcerts -connect example.com:443 2>/dev/null | grep -E 'subject|issuer'

# Is the chain valid from a clean root store?
curl -v https://example.com 2>&1 | grep -E 'SSL|certificate'

When something is broken, run those before doing anything else. Half the time the answer is in the output.

HTTP/1.1, 2, 3

HTTP/1.1 is text-based, one request per connection (without pipelining, which never worked properly), and the dominant protocol for two decades. HTTP/2 multiplexes many streams over one TCP connection (eliminates head-of-line blocking at the HTTP layer, but not at the TCP layer). HTTP/3 runs over QUIC, eliminating both kinds of head-of-line blocking and shaving a round trip on resumption.

The pragmatic version for backend engineers in 2025:

• Default to HTTP/2 between services. Use HTTP/3 at the edge for browser clients.
• HTTP/1.1 is fine for simple internal tools.
• gRPC runs on HTTP/2. Almost all the “is gRPC fast?” answers come down to HTTP/2 multiplexing.

The build: a tiny HTTP/1.1 server in raw sockets

No framework. Just sockets. About 80 lines of Python.

# server/tiny_http.py
import socket

def handle(conn):
    data = b""
    while b"\r\n\r\n" not in data:
        chunk = conn.recv(4096)
        if not chunk: return
        data += chunk
    req_line = data.split(b"\r\n", 1)[0].decode()
    method, path, _ = req_line.split()
    body = f"<h1>{method} {path}</h1>".encode()
    resp = (b"HTTP/1.1 200 OK\r\n"
            b"Content-Type: text/html\r\n"
            f"Content-Length: {len(body)}\r\n\r\n".encode() + body)
    conn.sendall(resp)

s = socket.socket(); s.bind(("0.0.0.0", 8080)); s.listen(64)
while True:
    conn, _ = s.accept()
    try: handle(conn)
    finally: conn.close()

Run it, hit it with curl, then with two concurrent curls, then with ab -c 10 -n 1000. Notice it serializes requests because it’s single-threaded. Add a threading.Thread per connection. Notice it falls over at higher concurrency. That’s the journey from raw sockets to needing a real server (gunicorn, uvicorn, axum, fasthttp). That journey is the lesson.

Going deeper

When you have specific questions, in this order:

1. High Performance Browser Networking (Grigorik). free online · the applied volume; HTTP/2, HTTP/3, and TLS chapters are excellent.
2. TCP/IP Illustrated, vol. 1 (Stevens). book · the canonical TCP/IP reference. Heavy.
3. Beej’s Guide to Network Programming. free site · the practical sockets reference.
4. Cloudflare blog — networking section. link · ongoing field reports from people running networking at scale.
5. The QUIC RFC. RFC 9000 · only when you need it; not light reading.

Skip “DNS explained in 60 seconds” videos. DNS deserves more than 60 seconds.

Checkpoints

If any one wobbles, redo the corresponding section.

1. Walk through every step from typing https://google.com to seeing the rendered page. Include DNS, TCP handshake, TLS handshake, HTTP, and rendering. Estimate the total time on a 50 ms RTT link.
2. You’re getting “certificate not trusted” errors from one client but not another against the same server. What is the most likely cause, and what command do you run first?
3. Why does HTTP/2 not solve TCP head-of-line blocking, and why does HTTP/3 over QUIC solve it?
4. Your tiny HTTP server falls over at 1000 concurrent connections. Name two distinct reasons (one per process limit, one per architecture choice) and a fix for each.
5. You can ping a host but TCP connections to port 443 hang. Name three layers where the problem could live and how you’d narrow it down with the tools in this module.

If you can answer all five from memory, you’ve earned 02.5. Move on to 02.6 (Databases and SQL, deep) — where the data behind your servers lives.