How the Internet Actually Works

Sign in to save your progress across devices. Until then it is kept in this browser.

Why this matters

Most "mysterious" production bugs are networking: a DNS change that has not propagated, a TLS certificate that expired, a request that is slow only for users far away. You cannot debug what you cannot picture.

Learning outcomes

1. Trace one request from the browser to the database and back, naming every hop.
2. Explain DNS resolution, TTLs and why changes "take time."
3. Explain TCP vs UDP and what HTTP/2 and HTTP/3 change.
4. Configure TLS correctly and encrypt internal traffic.
5. Measure latency correctly: percentiles, not averages.

Lessons

2.1 The life of a request

Browser → DNS lookup → TCP (or QUIC) connection → TLS handshake → CDN edge → reverse proxy / load balancer → app server → database / cache / third-party APIs → back. Each hop adds latency and is a failure point.

2.2 DNS (97)

• Records: A/AAAA (address), CNAME (alias), MX (mail), TXT (verification, SPF, DKIM, DMARC), CAA (which CAs may issue certs).
• TTL controls caching. Lower the TTL a day before a migration, not during.
• Common failures: expired domain, wrong CNAME, missing email records (mail goes to spam), DNS provider outage.

2.3 TCP vs UDP (98) and HTTP versions (99)

• TCP: reliable, ordered; a lost packet stalls everything behind it (head-of-line blocking).
• UDP: no guarantees, low overhead; used by video, voice, games, DNS and QUIC.
• HTTP/1.1: one request at a time per connection.
• HTTP/2: many streams multiplexed on one TCP connection; still TCP head-of-line blocking.
• HTTP/3: runs on QUIC over UDP; independent streams, faster handshakes, survives network changes (Wi-Fi to mobile). Usually you get it free from your CDN.

2.4 TLS, encryption in transit (71, 73)

• TLS 1.2 minimum, prefer TLS 1.3. Automate certificates (Let's Encrypt, or your platform).
• HSTS header so browsers never downgrade to HTTP.
• Encrypt internal traffic too (app to DB, service to service). "It's inside our VPC" is not a control.
• Database connections: require SSL (sslmode=require or stricter).

2.5 Latency, throughput, percentiles (91 to 94)

• Latency: time for one request. Throughput: requests per second.
• Never report averages. Report p50, p95, p99. One slow request in 100 sounds rare, but a page that makes 20 backend calls hits the p99 on a large share of page loads. That is tail latency amplification.
• Rough numbers every engineer should know: same-region network round trip roughly 1 ms or less; Singapore to US West roughly 170 ms round trip; an LLM call takes seconds. Design around the slowest hop.

Lab 2: Trace and measure

1. dig your domain; record every record and TTL. Add CAA and check SPF/DKIM/DMARC for your mail domain.
2. Run curl -w timing (dns, connect, tls, ttfb, total) against your app from two regions.
3. Check your TLS setup with an online TLS grader; fix to A grade.
4. Load test one endpoint with k6 at 10, 50, 100 virtual users; chart p50/p95/p99.

Definition of Done

• DNS inventory note, with CAA, SPF, DKIM, DMARC presentEvidence
• TLS grade A, HSTS enabled, DB connections require TLSEvidence
• Latency budget written for your main user journey (which hop gets how many ms)Evidence
• k6 report with percentiles attachedEvidence

AI prompt pack

• "Add timing instrumentation that logs DNS, connect and TTFB for every outbound HTTP call."
• "Explain the request path of this app hop by hop based on the config files. Flag any hop without TLS."