Networking — Packets to HTTPS
- Explain what IP, TCP, UDP, DNS, and TLS each contribute to one HTTPS request
- Trace a full request with curl -v and name every phase in the output
- Distinguish latency from bandwidth and say which one dominates API performance
- Describe the TLS handshake and what a certificate actually proves
- Read a request waterfall and identify the slowest phase
| Spaced-rep warm-up: due flashcards from Week 6 | 10 min |
| ELI5 + tech read: the layer cake and TLS | 20 min |
| Guided: curl -v anatomy + raw socket HTTP | 35 min |
| Practice: the latency audit | 20 min |
| Project: request waterfall field notes | 25 min |
| Quiz + flashcards | 10 min |
Builds on: Day 41 — HTTP & your first API · Day 39 — OS essentials — processes & file descriptors · Day 6 — The terminal & Linux
Mailing a birthday card involves a whole invisible system: you write an address (DNS turns "grandma's house" into street coordinates), the postal service breaks bulk mail into individual trucks and routes each one independently (IP moves packets hop by hop, and any packet can take a different road), and certified mail adds tracking plus a signature on delivery so lost items get re-sent (TCP numbers every packet and re-transmits the missing ones). If the card is private, you use a tamper-evident envelope that only grandma can open, sealed with a wax stamp a notary vouches for (TLS encryption plus a certificate signed by an authority both of you trust).
One HTTPS request is exactly this stack of services layered on top of each other: DNS finds the address, TCP sets up a reliable two-way channel over unreliable IP, TLS wraps it in the sealed envelope, and only then does your actual HTTP letter — "GET /users/42" — travel inside. Each layer only does its one job and trusts the layer below.
Every AI product you ship is a network service calling other network services: your API calls a model provider, a vector DB, and a cache — each hop adds DNS + TCP + TLS + server time. When a customer says "your assistant takes 4 seconds to answer," you must decompose that into network phases before touching code; the fix for 800 ms of TLS handshakes (connection reuse) is completely different from the fix for slow generation. FDEs also live inside customer networks: firewalls, private DNS, and TLS interception are the top three reasons a demo that worked in your office dies on-site.
Guided practice
Anatomy of one HTTPS request with curl -v
20 min- Run
curl -v https://example.comand read the output top to bottom — do not skim. - Label each block in a scratch file: DNS resolution (the
Trying <ip>line), TCP connect, TLS handshake (TLS handshake, certificate lines: issuer, subject, expiry), the HTTP request you sent (lines starting>), the response (lines starting<). - Find the certificate's issuer and expiry date. Who vouched for this server?
- Run it again with timing: paste the
--write-outcommand from the starter. Record the five phase timings. - Run the timing command twice in a row. Which phases got cheaper the second time, and why? (Hint: DNS cache, connection reuse does NOT happen across curl invocations — so what stayed expensive?)
Speak raw HTTP through a socket
15 minHTTP is just text over a TCP socket. Prove it.
- Run the starter script: it opens a TCP socket to example.com port 80, writes a hand-typed HTTP/1.1 request, and prints the raw response.
- Identify the status line, three headers, the blank line separating headers from body, and the body.
- Break it on purpose: remove the
Hostheader and re-run. What status comes back, and why does a shared server need Host? (One IP hosts many sites.) - Change the path to
/nonexistent. Confirm the 404 arrives as ordinary text — errors are responses too. - Try port 443 with this same script. It fails or returns garbage — explain in one sentence why (no TLS layer).
On your own
The latency audit
20 minPick three real endpoints: a nearby site, an intercontinental one, and an API (e.g. a public JSON API). Using the curl timing template from guided work, collect DNS / TCP / TLS / first-byte / total for each, three runs apiece.
Your goal: (1) a small table of medians; (2) one sentence per endpoint naming the dominant phase; (3) answer: for the API, what fraction of total time is connection setup (TCP+TLS) — and therefore what would connection reuse save a client making 100 sequential calls?
Hints (only if stuck): setup cost is roughly (connect + appconnect − namelookup); a pooled client pays it once, not 100 times.
Request waterfall field notes
Create networking_notes.md in your practice repo: an annotated trace of ONE full HTTPS request to a real API. Include the labeled curl -v output (trimmed), a phase-timing table from three runs, a hand-drawn-in-ASCII waterfall (DNS → TCP → TLS → request → server → response), and a "so what" section: three concrete rules you will apply when building LLM clients (connection reuse, timeout placement, why streaming changes perceived latency). Commit it — you will reuse these rules verbatim when you build the robust LLM client wrapper on Day 107.
Common mistakes & misconceptions
- Thinking HTTPS is a different protocol from HTTP. It is HTTP inside a TLS tunnel over TCP — same verbs, same headers, encrypted transport.
- Blaming "slow internet" (bandwidth) for slow APIs. Small JSON messages are latency-bound: round trips times distance, not megabits per second.
- Assuming DNS happens on every request. Resolvers cache aggressively per TTL — but the FIRST request after a deploy or in a fresh container pays full price.
- Believing TLS certificates encrypt traffic. The certificate authenticates identity; encryption uses a symmetric session key derived during the handshake.
- Forgetting that TCP guarantees delivery, not timeliness. A "reliable" connection can stall for seconds on retransmission — which is why your clients need timeouts (Day 107 makes this law).
- Ignoring the Host header. One IP serves many domains; without Host (or SNI in TLS), the server cannot know which site you want.
Q1. A client makes 50 sequential HTTPS calls to the same API without connection reuse. What cost does it pay 50 times that a pooled client pays once?
Q2. Your API response is 2 KB of JSON but takes 900 ms from another continent. The dominant cause is most likely…
Q3. What does a TLS certificate actually prove?
Go deeper — curated resources
- HTTP/3 and QUIC — TCP reimagined over UDP — QUIC merges transport and TLS handshakes and fixes head-of-line blocking. Skim the idea; the mental model (fewer round trips) is what matters.
- curl -v trace fully labeled: DNS, TCP, TLS, request, response
- Raw-socket script run, Host-header experiment explained
- Latency audit table complete with dominant phase named per endpoint
- Field notes committed with three client-design rules
- Quiz ≥ 2/3
← Back: On Day 41 you used HTTP through httpx and FastAPI as a black box; today you opened it — sockets, ports, and file descriptors are the Day 39 machinery underneath. The terminal fluency from Day 6 made curl feel natural.
Forward →: Day 44 adds locks to this postal system (TLS was privacy; auth is identity and permission). On Day 107 your LLM client wrapper applies today's rules — pooling, timeouts, streaming — and on Day 155 you'll decompose model latency (TTFT vs tokens/sec) with exactly this waterfall thinking.
Unlocks: D44 Security, AuthN & AuthZ · D49 Week 7 Checkpoint: Design & Build a URL Shortener