Phase 3: How the Internet & APIs Actually Work · ~35 minutes · curl · DNS · TCP

What Actually Happens When You Load a Page

"The internet is down" is never actually the diagnosis. DNS failed, or the connection was refused, or TLS didn't verify, or the server said 404 — four completely different problems that all just look like "it didn't work."

Hiring signal: Diagnoses a network failure by which specific stage broke, not by treating 'the internet' as one opaque thing

What you will learn

Trace the full sequence: DNS resolution, TCP handshake, TLS handshake, HTTP request/response
Use curl -v to observe every stage of a real request directly
Identify which specific stage failed from a given error
Explain why treating 'the internet' as a black box makes every bug feel like magic

Introduction

Type: Learn Languages: HTTP, curl Prerequisites: Phase 02 (Dev Environments & Dependency Management) Time: ~35 minutes

Objective

Learning objectives

Trace the full sequence: DNS resolution, TCP handshake, TLS handshake, HTTP request/response
Use curl -v to observe every stage of a real request directly
Identify which specific stage failed from a given error
Explain why treating "the internet" as a black box makes every bug feel like magic

What you're building

Using curl -v (or your browser's Network tab, if you prefer to work visually):

Make a real request to a real HTTPS URL and annotate, in your own words, each of the four stages as it appears in the real output
Reproduce a real DNS failure (an intentionally nonexistent domain) and capture the exact error
Reproduce a real connection-refused error (a port with nothing listening — localhost plus an arbitrary high port number is safe and reliable for this)
Reproduce a real HTTP-level error (a 404 or similar) from an actual server response, and explain in network_notes.txt why this one is fundamentally different from the first two — specifically, which stages it actually passed through before failing

A request fails instantly with "Could not resolve host." Has the target server's application code run at all, even briefly?

DNS resolution is the very first stage, and it happens entirely before any connection is attempted — the client is only translating a name into an address at this point, with no network path to the actual server established yet. If that translation fails, the client has no address to even attempt a TCP connection to, meaning no packet of any kind reaches the target server, and none of its code — application logic or error handling — ever runs. This is precisely why 'the site is down' and 'DNS failed' are different diagnoses: one means the server had a problem; the other means the server was never even reached.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.