The Request Journey: DNS, TCP, TLS and HTTP
What happens between typing a URL and the first byte back: DNS, the TCP handshake, TLS, and how HTTP/1.1, 2 and 3 differ.
- 4 round tripsCold HTTPS with TLS 1.3, DNS uncached
- 200 msThat journey at a 50 ms round trip
- 1 round tripA warm, kept-alive connection
Show what to say
“The browser resolves the name through DNS, opens a TCP connection, negotiates TLS, then sends the HTTP request, and each stage costs at least one round trip. On a repeat visit the address, the connection and the TLS session are reused. HTTP/2 multiplexes streams on one connection, and HTTP/3 over QUIC also removes TCP head-of-line blocking.”
Trade-offs
- Long vs short DNS TTL: a long TTL saves lookups; a short one lets you fail over fast but adds resolver load.
- HTTP/2 vs HTTP/3: HTTP/2 multiplexes over TCP and stalls on loss; HTTP/3 isolates streams but UDP can be blocked and costs more CPU.
- TLS 0-RTT vs 1-RTT: early data saves a round trip for returning clients but can be replayed, so only safe requests.
Bring it up before they ask
A bad DNS record or expired certificate is fixed in minutes but caches keep serving it for the TTL, so lower TTLs before risky changes.
Before a server sees your request, the client resolves a name with , opens a connection and sets up , each costing at least one round trip. shares one connection between requests, and also removes TCP's .
What happens when you type a URL
Four stages in order: find the address (), connect (), secure it (), ask for the page (HTTP).
Read more · 112 words
Each needs at least one round trip, so is the round-trip time times the trips.
- Client
- DNS
- Service
Text description
- Browser → DNS resolver: address of example.com?
- DNS resolver replies to Browser: 93.184.216.34, TTL 300 s
- Browser → Server: SYN
- Server replies to Browser: SYN-ACK
- Browser → Server: ACK + ClientHello (key share)
- Server replies to Browser: ServerHello, certificate, Finished
- Browser → Server: Finished + GET /
- Server replies to Browser: 200 OK + HTML
DNS: names to addresses
Computers connect to addresses, not names.
Read more · 134 words
Your browser asks a recursive resolver. On a cold the resolver follows referrals: a root server points to the .com servers, which point to the domain's authoritative server, which holds the answer.
Every answer carries a , how long anyone may cache it. That is why is fast but changes are slow: lower the TTL a day before a planned move.
Tap any box to see what it is and what it talks to.
- Client
- DNS
Text description
- Browser asks: address of www.example.com?
- Resolver asks a root server. It does not know, but points to the .com servers.
- Referral: ask the .com servers.
- Resolver asks a .com server, which points to example.com's name server.
- Resolver asks the authoritative server for the real answer.
- 93.184.216.34, valid for 300 seconds.
- Answer returned and cached in the resolver.
// A toy recursive resolver. Each server answers with either an address (and a TTL)
// or a referral: "I don't know, ask that server." Answers are cached until their TTL runs out.
export function makeResolver(servers, now = () => Date.now()) {
const cache = new Map(); // name -> { ip, expires }
return function resolve(name) {
const hit = cache.get(name);
if (hit && hit.expires > now()) return { ip: hit.ip, queries: 0 };
let server = 'root';
for (let queries = 1; queries <= 8; queries++) {
const reply = servers[server](name);
if (reply.ip) {
cache.set(name, { ip: reply.ip, expires: now() + reply.ttl * 1000 });
return { ip: reply.ip, queries };
}
server = reply.refer; // follow the referral
}
throw new Error('too many referrals');
};
}The TCP handshake
gives ordered, reliable delivery over unreliable packets.
Read more · 91 words
The client sends SYN, the server answers SYN-ACK, and the client's completes it: one round trip before data flows, and the ACK can already carry the next stage's first bytes.
Three messages are needed because each side must show it can send and receive and learn the other's starting sequence number. It also stops a delayed old SYN from opening a connection nobody wants. Lesson 6 goes inside TCP.
TLS: encryption and identity
adds confidentiality, integrity and authentication on top of .
Read more · 61 words
In TLS 1.3 the client's first message carries its half of a key exchange. The server replies with its half, its certificate and proof it holds the private key. Both derive one session key and the request follows: one round trip.
The browser trusts the certificate if it chains to a known authority, matches the hostname and has not expired.
HTTP/1.1, HTTP/2 and HTTP/3
Read more · 186 words
| HTTP/1.1 | HTTP/2 | HTTP/3 | |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (over UDP) |
| Requests per connection | One at a time | Many streams | Many streams |
| Head-of-line blocking | Between requests | In TCP, on loss | Per stream only |
HTTP/1.1 handles one request at a time per connection, so browsers open about six. multiplexes streams on one connection, but they share one byte stream, so one lost packet stalls all of them. runs on QUIC: a lost packet delays only its own stream, 1.3 is built into the handshake, and a connection survives a change of network.
Putting numbers on it
Assume a 50 ms round trip to the server and nothing cached.
Read more · 125 words
| Setup | Round trips | Time to the response |
|---|---|---|
| DNS + TCP + TLS 1.2 + request | 1 + 1 + 2 + 1 = 5 | 250 ms |
| DNS + TCP + TLS 1.3 + request | 1 + 1 + 1 + 1 = 4 | 200 ms |
| DNS + QUIC + request | 1 + 1 + 1 = 3 | 150 ms |
| Warm connection, request only | 1 | 50 ms |
The biggest wins are not new protocols but not repeating the setup: keep connections alive and reuse them, serve from a near the user so the round trip itself is short, and resume sessions.
Speeding up the first byte
Read more · 231 words
- Connection reuse. and mean the handshakes are paid once.
- Nearby servers. A or edge node ends the and handshake close to the user.
- Resumption. A returning client can resume a TLS session and skip full key exchange. TLS 1.3 early data (0-RTT) saves another round trip but can be replayed, so use it only for safe, repeatable requests.
- Hints.
preconnectopens the connection early;dns-prefetchresolves a name early. - Fewer origins. Each extra hostname costs its own , TCP and TLS setup.
For how pools and keep-alive show up on the server side, see connections, pooling and keep-alive and request flows end to end.
Where this goes wrong
Read more · 249 words
- Certificate problems. Expired, wrong hostname, or a missing intermediate certificate cause hard failures in browsers.
- Stale DNS after . Clients that ignore TTL, or long-lived connections, keep using the dead address.
- Middleboxes. Some networks block or throttle UDP, so must fall back to over .
Follow-up questions
What happens when you type a URL into a browser?
The browser checks , resolves the name through , opens , negotiates , sends the HTTP request and renders the response.
How does TLS give you a secure channel?
A key exchange gives both sides a secret nobody on the wire can compute, a certificate proves the server's identity, and a symmetric cipher protects the data.
What does HTTP/3 fix that HTTP/2 does not?
streams share one TCP connection, so one loss blocks all of them. delivers streams independently and merges the handshakes.
Check yourself
Question 1 of 7Score 2 out of 3 or better to mark this page complete.