Capstone: What Happens When You Open google.com

By the end of this lesson you will be able to

• Walk through everything that happens between pressing Enter on google.com and seeing the page, naming every actor: browser, operating system, router, ISP, resolver, Google’s edge and backends.
• Explain what the address bar decides before any packet leaves (search vs address, HSTS, the parts of a URL).
• Follow one packet out through NAT and the internet and back, and say which header fields change at each hop.
• Describe Google’s edge: nearby front ends, TLS termination at the GFE, and routing to backend services.
• Explain the critical rendering path (DOM, CSSOM, render-blocking CSS, blocking vs async/defer scripts, layout, paint, compositing) and why repeat visits are faster (connection reuse, HTTP cache, 304).
• Read a network waterfall with rough millisecond numbers and point to where time is lost and what fixes it.
• Explain why the network must be treated as unreliable (loss, variable delay, partial failure, partitions) and which design tools answer each problem.

#The journey in one picture

This is the capstone of the networking module. Every earlier lesson zoomed in on one piece; here we put them together in order, for the most common action on the internet: typing google.com and pressing Enter.

The short version, worth memorising:

Client → DNS → IP address → connection → packet routing / NAT → Google server → HTTP response → browser rendering

Each piece has its own lesson if you want to go deeper: client–server, layers and encapsulation, IP and MAC addressing, routing and NAT, DNS, TCP, UDP and TLS, network devices, firewalls, proxies and VPNs and diagnostics. This lesson covers what happens between those pieces, and the parts none of them cover: the address bar, Google’s edge, rendering, caching and the timeline.

#The cast of acronyms

#Watch it end to end

Here is the whole journey, actor by actor. Play the first visit, then compare the repeat visit, HTTP/3 and the two failures. The rest of the lesson explains each step in detail.

#Step 1: URL parsing in the address bar

When you type into Chrome’s address bar (the “omnibox”) and press Enter, the browser first decides: is this a search query or a website address?

• Has a scheme (https://…) or looks like a host name (no spaces, ends in a real top-level domain such as .com or .bd, or is an IP address or localhost): it is an address.
• Has spaces or no valid host: it is a search, sent to your default search engine as https://www.google.com/search?q=….
• A single word like printer: treated as a search, but the browser quietly checks DNS and may offer “Did you mean http://printer/?”.

Then it picks the scheme. You typed no https://, but the browser will still use HTTPS:

• HSTS (HTTP Strict Transport Security) is a site’s instruction “only ever contact me over HTTPS”. Browsers remember it after the first visit, and ship a built-in preload list of sites that are HTTPS-only from the very first visit; many Google domains are on it. For those, even http://google.com is rewritten to https:// inside the browser (an internal redirect), so no plain-text request ever leaves your computer.
• Even without HSTS, modern browsers try HTTPS first for typed addresses.

Finally it splits the URL (Uniform Resource Locator) into parts:

https://www.google.com:443/search?q=dns#results
└─┬─┘   └──────┬─────┘└┬┘└──┬──┘└──┬──┘└──┬───┘
scheme       host    port  path  query  fragment (never sent to the server)

The port is usually not typed: 443 is the default for https, 80 for http.

The browser is the program that sends requests and displays responses; the OS (operating system, e.g. Windows) manages the network hardware and system resources the browser relies on. Before any of this, the browser may already have pre-resolved google.com and even opened a connection while you were still typing, because it predicted you would press Enter.

#Step 2: DNS lookup

Computers do not route by name; they need the destination’s IP address. The lookup checks, in order, the browser’s DNS cache, the OS cache and hosts file, then asks the recursive DNS resolver (your ISP’s, or a public one like 8.8.8.8 or 1.1.1.1). If the resolver has nothing cached, it walks the tree:

• Root DNS server: “ask the .com TLD servers”.
• TLD DNS server (.com): “Google’s authoritative name servers are ns1–ns4.google.com”.
• Authoritative DNS server (Google’s): “www.google.com is this address, cache it for 300 seconds”.
• Recursive resolver: caches the answer and returns the IP to your computer.

Example: google.com → DNS resolution → IP address. With a valid answer in any cache, the root, TLD and authoritative servers are not contacted at all, which is the normal case for a name as popular as Google. If DoH is turned on, the browser sends the DNS query inside HTTPS so the network cannot read it.

Two details that matter for this journey:

• The answer depends on where you ask from. Google’s name servers look at the resolver’s location (or a client-subnet hint) and return the address of a front end near you. A user in Dhaka and one in London get different IPs for the same name.
• The TTL is short (300 seconds) so Google can move traffic between locations quickly.

Full details, record types, caching layers and failures are in the DNS lesson.

#Step 3: Connection establishment

With the IP in hand, the browser creates a transport connection, or reuses one that is already open.

For HTTPS over TCP:

1. SYN (synchronize): the client starts the connection.
2. SYN-ACK: the server acknowledges and answers.
3. ACK (acknowledgment): the client confirms.

That is the TCP three-way handshake: one round trip. Then the TLS handshake sets up encryption. With TLS 1.3 it takes one more round trip: the client sends its supported ciphers, a key share, the server name (SNI) and the protocols it speaks (ALPN, “h2” for HTTP/2); the server answers with its key share and Google’s certificate, which the browser checks (right name, valid dates, signed by a trusted authority). TCP gives reliable, ordered delivery; TLS encrypts and proves the server’s identity.

The exception: HTTP/3 does not use TCP. It runs on QUIC over UDP, which combines the transport and TLS handshakes into one round trip (and zero on some repeat visits). So a TCP three-way handshake is not mandatory for every HTTPS connection. The browser learns that Google supports HTTP/3 from an alt-svc header in an earlier response (or from a DNS HTTPS record), and falls back to TCP if UDP is blocked.

Connection reuse. Handshakes cost round trips, so browsers keep connections open after a page loads and reuse them for the next request to the same server, and one HTTP/2 or HTTP/3 connection carries many requests at once. A page can also ask for early setup with <link rel="preconnect"> (DNS + TCP + TLS in advance) or <link rel="dns-prefetch"> (DNS only) for other hosts it will need soon. The TCP, UDP and TLS lesson shows each handshake packet by packet.

#Step 4: Sending the HTTP request

Over the secure connection, the browser asks for the page:

GET / HTTP/2
Host: www.google.com
Accept: text/html
Accept-Language: bn-BD,en;q=0.9
Accept-Encoding: gzip, br
Cookie: …

This is a simplified, readable version. Real HTTP/2 does not send headers as text like this: they are compressed into binary frames (and in HTTP/2 the host travels as a pseudo-header called :authority).

• HTTP (Hypertext Transfer Protocol) defines how web requests and responses look; HTTPS is HTTP inside TLS.
• GET is the method for fetching a resource; the path / means the home page.
• Headers carry extra information: which languages and compression formats you accept, cookies that identify your signed-in session, and so on.

#The request inside its envelopes

Before it leaves your computer, the request is wrapped layer by layer: HTTP data inside a TLS record, inside a TCP segment (ports), inside an IP packet (addresses), inside a Wi-Fi or Ethernet frame (MAC addresses for this one link). This is encapsulation; each router opens only the outer envelopes, and only Google’s edge opens them all. See layers and encapsulation for the models behind it.

#Step 5: Router, ISP and internet routing

The packet now has to cross several networks to reach Google’s IP.

• Default gateway: Google’s IP is not on your local network, so your computer sends the frame to the default gateway, your home router (its MAC address found with ARP).
• NAT: your laptop has a private address (192.168.1.10) that is meaningless on the internet. The router replaces the source with its own public IP and a port (203.0.113.25:62001) and records the mapping in its NAT table so the reply can be sent back to you. If your ISP uses carrier-grade NAT (CGNAT), this happens a second time inside the ISP.
• Routers: each router looks at the destination IP, checks its routing table and forwards the packet to the next hop. No router knows the whole end-to-end path. Between networks, BGP decides which neighbour network to hand the packet to.
• ISP: your Internet Service Provider carries the packet to the wider internet. Large ISPs connect to Google directly at exchange points (peering), so the path is often only a handful of hops.
• The return path can be different from the request path, because each network makes its own forwarding choices.

Watch which header fields change at each hop: the MAC addresses change on every link, TTL drops by one at each router, the source IP and port change once at NAT, and the destination IP never changes.

More on routing tables, default gateways and NAT in routing and NAT.

#Step 6: Google’s side and the HTTP response

The packets arrive at a Google edge location (a point of presence, or PoP) close to you. Google’s side is layered:

1. Getting you to a nearby edge. Google’s DNS answers with a nearby front-end address, and many of Google’s addresses are anycast: the same IP is announced via BGP from many locations, so internet routing delivers you to the closest one. If one location fails, its route is withdrawn and traffic flows to the next.
2. The GFE (Google Front End) is Google’s fleet of reverse proxies. It terminates TLS close to you (short round trips for the handshake), protects against floods and abuse, and decides which backend service and data centre should handle the request.
3. Backends. The GFE forwards the request over Google’s private backbone (not the public internet) using already-open connections. The search frontend calls other services in parallel (your account, today’s doodle, and so on) and builds the HTML.
4. The response goes back through the GFE, which compresses and encrypts it and streams it to you.

A simplified response looks like this:

HTTP/2 200
content-type: text/html; charset=UTF-8
content-encoding: br
cache-control: private, max-age=0
alt-svc: h3=":443"

• HTTP response: the server’s answer: a status code, headers and a body.
• Response body: the HTML (or other content).

Status codes you will meet on this journey:

Receiving the HTML is not the end: the browser usually has to send more requests for CSS, JavaScript, images and fonts.

#More requests: CSS, JavaScript, images and fonts

As the HTML streams in, the parser (and a preload scanner that reads ahead) discovers the other files the page needs. They are fetched in parallel:

• On HTTP/2 or HTTP/3, all requests to the same host share one connection as separate streams, with priorities (CSS first, because it blocks rendering). No new handshakes.
• On old HTTP/1.1, one connection carries one request at a time, so browsers open up to 6 connections per host, each with its own handshake.
• A file on another origin (a different host, like a font server) needs its own DNS lookup and handshakes, unless a preconnect hint started them early.
• Many files are served straight from the edge’s cache, and come with long cache lifetimes so the next visit needs no network at all.

#Step 7: Browser rendering

The browser now turns HTML, CSS and JavaScript into pixels. This sequence is called the critical rendering path:

1. HTML → DOM. Bytes are decoded into characters, tokens and then nodes of the DOM (Document Object Model), a tree of every element that JavaScript can read and change. This builds the page’s structure.
2. CSS → CSSOM. Stylesheets are parsed into the CSSOM (CSS Object Model): the rules for style, colour, size and layout. CSS is render-blocking: the browser will not paint until the CSSOM is ready, to avoid flashing unstyled content.
3. JavaScript execution. Handles interaction, events and dynamic content. A plain <script src> is parser-blocking: parsing stops until it is downloaded and run. defer scripts download in parallel and run after parsing (before DOMContentLoaded); async scripts run as soon as they arrive, in any order.
4. Render tree. DOM + CSSOM are combined into the tree of visible elements with their computed styles.
5. Layout (reflow). The exact size and position of every box is calculated for the current screen width.
6. Paint. Boxes are turned into drawing commands (text, colours, borders, images), often on several layers.
7. Composite → display. Layers are rasterised into pixels and the compositor, mostly on the GPU, stacks them on screen.

These stages do not run strictly one after another. The browser parses HTML while it is still downloading, fetches CSS and images in parallel, and can paint the top of the page before the bottom has arrived.

After the page has loaded, changes are cheapest when they touch fewer stages: changing geometry (width, position in the flow) re-runs layout, paint and composite; changing a colour re-runs paint and composite; changing transform or opacity on its own layer only re-composites. That is why smooth animations use transform and opacity.

#Repeat visits: caching

Open Google again a minute later and almost everything is skipped:

• DNS: the IP is still in the browser and OS caches (TTL 300 s).
• Connection: the HTTP/2 connection may still be open; if not, TLS session resumption (or QUIC 0-RTT) makes the new handshake cheaper.
• HTTP cache: files stored with Cache-Control: max-age=… are reused from memory or disk without any request while fresh. Big sites put a hash of the content in the file name (app.3f9a1c.js) and cache it for a year: a new version simply gets a new name.
• Revalidation: a stale file with an ETag (version tag) is checked with a conditional request (If-None-Match). If unchanged, the server answers 304 Not Modified with no body.
• Personal pages are marked private (no shared caches such as proxies or CDNs) and often no-cache or max-age=0, so the HTML is always fetched fresh. Google’s home page is one of these.

#The timeline: where the milliseconds go

Put it all on one time axis and you get the waterfall you see in a browser’s developer tools. The numbers below are rough, for a good broadband connection with about 30 ms round trips to Google’s nearby edge:

What the scenarios show:

• Round trips dominate, not bandwidth. On a 300 ms mobile connection the same page takes about 3 seconds, almost all of it waiting for round trips. That is why Google puts edges near users, prefers HTTP/3, uses preconnect and inlines critical CSS.
• Repeat visits are dramatically faster thanks to DNS caching, connection reuse and the HTTP cache.
• Performance teams track TTFB (time to first byte), the first paint and LCP (Largest Contentful Paint: when the main content becomes visible).

#When something goes wrong

The steps also tell you where to look when a page will not load. Each error points at one stage:

The diagnostics lesson shows the tools (ping, traceroute, nslookup, curl) to check each stage.

#The network is unreliable

Everything above is the happy path. Every step crossed links, routers and machines that can fail, and at the scale of Google, or of any busy system, something is always failing somewhere. Systems that stay up treat failure as normal input, not as a surprise.

#What actually goes wrong

• Packet loss. Queues overflow, Wi-Fi frames collide, cables are cut. TCP and QUIC hide loss by resending, but every loss costs at least one more round trip, and a lost SYN costs a full second. To a user, loss looks like slowness, especially in the slowest requests (p99), not like an error.
• Variable delay. The same request takes 30 ms or 300 ms depending on queues along the path. From the outside, “slow” and “dead” look identical until you decide to stop waiting.
• Partial failure. On one computer, a program either works or crashes. Across a network, some parts work while others fail, and when no reply comes you cannot know why: the request was lost, the server is slow, the server crashed before doing the work, or it did the work and the reply was lost.
• Partitions. A cut link can split machines into groups that are all running but cannot reach each other. Each side may believe the other is dead and carry on alone.

#Designing for it

The Google journey you just followed is built exactly this way: DNS answers come from caches and several name servers, your operating system has a second resolver, TCP resends lost segments, the browser falls back from QUIC to TCP when UDP is blocked, anycast withdraws a failed edge location and sends users to the next one, and the GFE retries a request on a different backend.

When you reach chapter 18 (CAP, PACELC and consistency) and chapter 28 (timeouts, retries, idempotency, circuit breakers and load shedding), remember where it all starts: a packet that may or may not arrive.

#The whole process at a glance

1. URL parsing: the browser understands the address.
2. DNS resolution: the domain’s IP is found if needed.
3. Connection: TCP + TLS, or QUIC + UDP.
4. Packet encapsulation: the HTTP data is carried inside transport, IP and link headers.
5. Routing + NAT: routers forward the packet; address translation happens where needed.
6. Google server: the front end and the relevant backends process the request.
7. HTTP response: the server’s answer travels back to the client.
8. Browser rendering: the page is built from HTML, CSS and JavaScript.

The most important differences, for exams and real work:

• DNS tells you which IP address to use for a domain.
• A router picks the next hop based on the destination IP.
• NAT changes the IP address and port mapping where needed.
• TCP/UDP carry data at the transport layer; TCP gives reliable delivery, UDP by itself does not.
• TLS secures HTTPS communication.
• HTTP defines the rules for web requests and responses.
• Google’s servers process the request and send a response.
• The browser builds the web page from the response and shows it on screen.

The formula to remember:

Client → DNS → IP address → connection → packet routing/NAT → Google server → HTTP response → browser rendering

#Try it yourself

# Time each phase of a real request (Windows: use curl.exe in PowerShell)
curl -o /dev/null -s -w "dns  %{time_namelookup}s\ntcp  %{time_connect}s\ntls  %{time_appconnect}s\nttfb %{time_starttransfer}s\ntotal %{time_total}s\n" https://www.google.com/

# See the redirect, the status code and the headers
curl -sI https://google.com | head -n 5
curl -sI https://www.google.com | grep -iE "^HTTP|cache-control|alt-svc|content-type"

# Which IP does Google give you? (compare with a friend in another city)
nslookup www.google.com

# The hops between you and Google's edge
tracert www.google.com        # Windows
traceroute www.google.com     # macOS / Linux

# The certificate the GFE presents
openssl s_client -connect www.google.com:443 -servername www.google.com </dev/null | head -n 20

In Chrome, open the developer tools (F12), go to the Network tab, tick “Disable cache”, and load google.com. Right-click the column headers to add Protocol (you will see h2 or h3), hover a row to see its timing breakdown (DNS, initial connection, SSL, waiting for server response, content download), and compare with a second load without “Disable cache”. chrome://net-internals/#hsts lets you query a domain’s HSTS status.

#Summary

Key takeaways

• The journey: Client → DNS → IP → connection → routing/NAT → Google server → HTTP response → rendering, with heavy overlap and caching in real life.
• Before any packet: the address bar decides search vs address, applies HSTS to force HTTPS, and splits the URL into scheme, host, port and path.
• DNS returns a nearby Google front-end IP with a short TTL; usually from a cache.
• Connection: TCP (1 round trip) + TLS 1.3 (1 round trip), or QUIC over UDP (1, sometimes 0). Browsers reuse connections and can preconnect.
• On the way: the request is encapsulated; your router does NAT; routers forward hop by hop on the destination IP; MACs change per link, TTL drops per hop; the return path may differ.
• Google’s edge: anycast/DNS steer you to a nearby PoP; the GFE terminates TLS, filters abuse and routes over Google’s backbone to backend services. CDN ≠ GFE.
• Rendering: HTML → DOM, CSS → CSSOM (render-blocking), scripts (blocking vs defer/async), render tree → layout → paint → composite. Subresources load in parallel over HTTP/2.
• Repeat visits skip DNS, handshakes and most downloads (HTTP cache, 304). In the waterfall, round trips cost the most time.
• The network is unreliable: loss shows up as delay, a missing reply cannot tell you whether the work happened (partial failure), and partitions split live machines. Answer with timeouts, retries with backoff, idempotency keys, graceful degradation, and the trade-offs of chapters 18 and 28.

Self-check: what happens when you open google.com30 questions