how/network

What happens when I press Enter in the browser

One URL → 12+ packets → 4 different protocols → ~100ms. The full chain from DNS to a rendered page in one overview. This is the finale: all the previous explainers in a single scene.

This is the final explainer. It pulls together everything you learned in the earlier ones into one big picture. Every page on the internet opens through the same sequence of steps:

DNS: get the IP from the name
TCP: open a reliable channel to the server
TLS: set up encryption on top of TCP
HTTP: finally ask the question and get an answer

Each phase is its own series of packets. Each one takes at least 1 round-trip to the server. If the RTT is large (a distant server), you literally feel the page "thinking." If all phases are fast, it just works.

Press ▶ and let's watch the whole chain as a sequence diagram between three actors: your browser, the DNS resolver, and the web server.

step 1/6·00 · pressed Enter

§ steps

You typed https://example.com into the address bar and pressed Enter. From this moment the chain begins.

In this animation there are 3 actors: your browser, the DNS resolver (its address arrived in the DHCP options, for example 8.8.8.8), and the web server example.com. They will now go through 4 different phases, each on its own protocol.

The extra infrastructure (DHCP, ARP, routing) already did its work before this moment. Your laptop has an IP, a mask, a gateway, and DNS. If it did not, you would have to add another ~10 packets at the start.

recap

What to remember:

A full "pressed Enter" = ~12 packets for a single request (minimum): 2 DNS + 3 TCP + 4-5 TLS + 2 HTTP. Each one needs an RTT, so on remote servers the latency is noticeable
Each phase rests on the previous one:
- HTTP will not start without TLS
- TLS will not start without TCP
- TCP will not start without knowing the IP
- The IP cannot be obtained without DNS
- DNS will not start without the [[default-gateway|default gateway]]
- The default gateway is not known without DHCP
- It all begins with the physical link
Optimizations:
- HTTP/2 multiplexes requests over a single TCP connection, so you do not repeat TCP+TLS for every resource on the page
- HTTP/3 uses QUIC over UDP. The TCP+TLS handshake compresses into a single round-trip (or zero on a repeat connection)
- DNS prefetch in the browser resolves names before the user clicks
- Connection reuse (keep-alive): the connection stays open after the first response, and later requests skip TCP+TLS
In the DevTools of any modern browser, Network → Timing shows the breakdown of these phases for each resource. The names there are usually "DNS lookup," "Initial connection," "SSL," "Waiting (TTFB)": exactly the same phases as in our animation
On a real page, a single HTML still triggers dozens of requests for CSS, JS, images, fonts, and analytics. Each is a repeat of the chain, or part of it (if keep-alive is used)

This is the finale of the series. You now have the full picture of "how the internet works," from the link to the rendered page. To go deeper into each part, open the separate explainers (DNS, TCP, TLS) or the articles in the KB.

§ dig into the knowledge base

§ steps

You typed https://example.com into the address bar and pressed Enter. From this moment the chain begins.

In this animation there are 3 actors: your browser, the DNS resolver (its address arrived in the DHCP options, for example 8.8.8.8), and the web server example.com. They will now go through 4 different phases, each on its own protocol.

The extra infrastructure (DHCP, ARP, routing) already did its work before this moment. Your laptop has an IP, a mask, a gateway, and DNS. If it did not, you would have to add another ~10 packets at the start.