Live model · Loading a website
What Actually Happens When You Type google.com
The browser first asks DNS for google.com's address, a walk down from the root servers that caches usually cut short. Then it opens a connection: a TCP handshake and a TLS handshake, a round trip each, or one for both on HTTP/3. Only then does the request leave. Round trips, not bandwidth, are most of the wait.
Pressing Enter on google.com, message by message
- CH2 DNS
- CH4 TCP
- CH3 TLS
- CH1 Request
How to read the stage
Each column is a machine and time runs down the page, so a slow trip is a steep arrow. With nothing cached and a server 40 ms away, DNS takes 80 ms, the first byte of the page arrives at 230 ms, and the page is on screen at 310 ms. Of the time before that first byte, 120 ms is three round trips: TCP, TLS, then the request itself.
Why DNS almost never asks the root
Every answer comes with a time to live. The root's pointer to the .com servers, and .com's pointer to Google's own name servers, each last two days, while google.com's address lasts 300 seconds. So after one lookup your ISP's resolver skips the top of the tree. Here four lookups send 7 questions upstream and only 1 reaches a root server; coming back after the address expires costs one question, to ns1.google.com.
One resolver, four lookups, and what it keeps
- CH2 Reached a root server
Handshakes cost round trips, not bandwidth
A handshake is a question and its answer, so each one costs a full round trip whatever your connection's speed. With a server 100 ms away, the first byte comes at 430 ms on TCP with TLS 1.2, 330 ms with TLS 1.3, 230 ms on HTTP/3, and 130 ms on an HTTP/3 return visit that sends the request in its very first packet.
The same request over four protocols
- CH2 TCP + TLS 1.2
- CH3 TCP + TLS 1.3
- CH4 HTTP/3 (QUIC)
- CH1 HTTP/3, 0-RTT
Why the page comes in waves
TCP doesn't know how fast the path is, so it sends a first window of about 14 KB, ten packets, then waits to hear it arrived before sending twice as much. That's slow start. The 130 KB page arrives in four rounds: 14 KB, then 28, 56 and the last 32. The parser asks for the stylesheet, script and logo as soon as the first 14 KB names them.
What the model leaves out
Real loads overlap more than this one: browsers look up and connect to several hosts at once, Google's page pulls from other domains, and a lost packet adds time. The resolver's distances, the server's 30 ms and the page's sizes are round numbers, not measurements. The handshake counts and the doubling windows are the protocols' own, from their RFCs.
Questions
- What is DNS, in one sentence?
- The internet's phone book: it turns a name like google.com into an IP address like 142.250.80.46, which is what your computer actually connects to.
- Why is the first visit to a site slower than the second?
- The second visit skips work. The browser and the resolver still hold the address, so DNS takes no time, and with HTTP/3 the browser can resume its last session and send the request in the first packet. Files the browser cached don't need fetching at all.
- Does faster internet make pages load faster?
- Only partly. Bandwidth decides how much arrives per round trip once data flows, but DNS and the handshakes are questions and answers, and each takes a full round trip no matter how fast your plan is. For a small page, the distance to the server matters more than the speed.
- What's the difference between HTTP and HTTPS here?
- HTTPS adds the TLS handshake, which agrees on keys so nobody on the path can read or change the page. TLS 1.3 needs one round trip for it, TLS 1.2 needed two.
- How many root servers are there?
- Thirteen named identities, A through M, run by 12 organizations. Each name is served from many machines around the world, about 2,000 in all, so the nearest copy answers.