How a request reaches your app

You type shop.com and press Enter. Less than a second later, the page is on your screen.

Between those two moments, your request makes four stops: a name lookup, an address and a port, a safe connection, and an HTTP request with its reply. In the last lesson you saw what a server is. In this lesson you follow one request to it.

Browseryou type shop.com

DNS resolverfinds the address

Vercel203.0.113.10:443

Next.js appbuilds the page

Browser to DNS resolver:
1shop.com?
DNS resolver to Browser:
2203.0.113.10
Browser to Vercel:
3TLS on port 443
Browser to Vercel:
4GET /
Vercel to Next.js app:
4build the page
Next.js app to Browser:
4the HTML

Read it top to bottom. The numbers match the sections below.

1. The name becomes an address

Computers on the internet find each other by number, not by name. The turns the name into that number.

┌──────────────────────────────────────────────────────┐
│                                                      │
│   ┌─────────┐   shop.com?    ┌──────────┐            │
│   │ browser │ ─────────────▶ │ resolver │            │
│   │         │ ◀───────────── │          │            │
│   └─────────┘  203.0.113.10  └────┬─────┘            │
│                                   │                  │
│                        ┌──────────┼──────────┐       │
│                        ▼          ▼          ▼       │
│                    ┌───────┐  ┌───────┐  ┌───────┐   │
│                    │ root  │  │ .com  │  │ shop  │   │
│                    └───────┘  └───────┘  └───────┘   │
│                                                      │
└──────────────────────────────────────────────────────┘

The resolver asks three servers, left to right, then gives the browser one address.

Your browser asks a : "What is the address of shop.com?"
The resolver asks the root servers, then the .com servers, then the name server for shop.com.
That last server holds the answer. The resolver gives it to your browser.

Records and TTL

The answer is a . Here is a real lookup for vercel.com, run with the dig tool:

Terminal

$ dig vercel.com A +noall +answer
vercel.com.   600   IN   A   64.239.109.65
vercel.com.   600   IN   A   64.239.123.1

A is the record type: a name points to an address.
The two numbers at the end are two addresses. Big sites have more than one.
600 is the . Resolvers keep this answer for 600 seconds, which is 10 minutes.

Because of the TTL, a DNS change does not reach everyone at once. Old answers stay in caches until their time runs out.

You meet these records when you connect a domain to Vercel. In Settings, Domains, Vercel tells you which record to add at your domain provider:

Record	Use	Example
A	apex domain to an address	`shop.com`
CNAME	subdomain to another name	`www.shop.com`
TXT	proof that you own it	`_vercel.shop.com`

2. An address and a port

The answer is an . The older kind, IPv4, has four numbers from 0 to 255. The newer kind, IPv6, is longer, like 2606:4700::1111.

Docker in Action compares an address to a mailbox. Many people can share one mailbox, so each letter also needs a name on it. On a network, that name is a .

Port	Who listens there
443	HTTPS, the normal web
80	HTTP, the old web without encryption
3000	`next dev` on your laptop
5432	PostgreSQL database

So localhost:3000 means "this computer, port 3000". localhost is a special name for 127.0.0.1, the . When you type https://shop.com, the browser uses port 443 without showing it.

Private and public addresses

Your laptop does not have its own public address.

┌─────────────────────────────────────────────────────┐
│                                                     │
│   ┌──────────────┐                                  │
│   │ laptop       │                                  │
│   │ 192.168.1.23 ├──┐                               │
│   └──────────────┘  │   ┌────────┐                  │
│                     ├─▶ │ router │ ─▶ 203.0.113.7   │
│   ┌──────────────┐  │   └────────┘                  │
│   │ phone        │  │                               │
│   │ 192.168.1.24 ├──┘                               │
│   └──────────────┘                                  │
│                                                     │
└─────────────────────────────────────────────────────┘

Two devices with private addresses share one public address through the router.

Addresses that start with 192.168. or 10. are private. They work only inside one network.
Your router has one public address that the whole internet can reach.
The router swaps the private address for its public one on the way out, and back on the way in. This is .

Servers in the cloud work the same way. Most of them have private addresses, and only a few machines at the edge face the internet.

3. A safe connection

The browser now opens a connection to the address and port. Two protocols do this work. A is like a shared language.

opens the line. The two sides exchange three short messages to agree to talk.
locks the line. The server shows a certificate, which proves it owns the name shop.com. Then both sides encrypt everything.

HTTPS is HTTP inside TLS. Vercel creates and renews the certificate for your domain, so you rarely see this step. Here is what curl -v printed for vercel.com:

Terminal

* Connected to vercel.com (64.239.123.1) port 443
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF

The first line shows the address from DNS and port 443. The second line shows TLS version 1.3. When curl asked for http://vercel.com on port 80, the reply was 308 Permanent Redirect to the HTTPS address.

4. The request and the reply

Now the browser speaks . It sends a request, and the server sends one reply.

Terminal

$ curl -sI https://vercel.com
HTTP/2 200
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, must-revalidate
server: Vercel

A request has three parts:

A method: GET to read, POST to send data, such as a form.
A path: the part after the domain, like / or /cart.
Headers: extra facts, such as which site you want (Host) and your cookies.

The reply has a status code, its own headers, and a body with the HTML. Open DevTools, then the Network tab, and reload. Each row is one request, and the Status column shows its code:

Code	Meaning	You see it when
200	OK	the page loads
301, 308	moved	`http` sends you to `https`
304	not modified	the browser cache is still good
404	not found	a wrong path
500	server error	your code threw an error
503	not available	the server is down or busy

Codes in the 400s mean the request was wrong. Codes in the 500s mean the server failed, and those are the ones that wake people up at night.

Busy sites put more machines in front of the app: load balancers and CDNs. They get their own lesson later in this chapter.

Remember4 points

01
DNS turns a name into an IP address. The TTL decides how long resolvers keep the answer.
02
An IP address finds the machine, and a port finds the program: 443 for HTTPS, 3000 for next dev.
03
TCP opens a connection, and TLS encrypts it with the site's certificate. Together with HTTP, that is HTTPS.
04
Every HTTP reply has a status code. The 400s mean a bad request; the 500s mean the server failed.

How the web works from MDN. The whole trip on one short page.
Adding a custom domain from Vercel. The A and CNAME records you add.
Docker in Action, 2nd edition, chapter 5: read 5.1 on protocols, interfaces, ports and NAT.
Facebook's outage details, the story above, from Meta's engineering blog.
How Facebook disappeared from the internet from Cloudflare. The same outage, as DNS resolvers saw it.

Next, you learn Linux in 20 minutes: the shell, files, processes and permissions on the servers your requests reach.

How a request reaches your app

1. The name becomes an address

Records and TTL

2. An address and a port

Private and public addresses

3. A safe connection

4. The request and the reply

Read more