You type bank.com, hit Enter and, almost immediately, the page is
there. It feels instant. But "instant" is an illusion: in those milliseconds, your
browser and half a dozen systems coordinate a precise sequence of steps.
Understanding it isn't an academic exercise —it's what separates someone who
uses the web from someone who can diagnose why it
sometimes doesn't respond.
The question behind it all
A URL looks like a single thing, but it's a compressed map: it states the protocol
(https), the server name (bank.com) and the path within
it (/accounts). The browser doesn't know how to "go" to a name; it
knows how to talk in numbers and connections. Everything that happens after Enter is
the work of turning that readable address into a page on your screen.
A URL is just an address: text pointing to a resource. It doesn't contain the page; it only says where to find it.
Reaching it coordinates several layers in a chain: translating the name into a number, opening a connection, sending a request and, with the response, rendering. Each layer solves one part and hands the result to the next.
1. From name to number
Machines don't find each other by name, but by IP address —a
number like 93.184.216.34—. The first step, then, is to translate
bank.com into that address. That's the job of DNS
(Domain Name System), the address book of the internet.
The browser asks "what IP does bank.com have?" and a chain of DNS
servers answers. If it queried recently, the answer comes from a cache in
milliseconds; if not, the question travels across several servers until it reaches
the domain's authority. The detail of how that chain works is covered in the
DNS: the address book of the
internet entry.
2. Opening the connection
With the IP in hand, the browser opens a TCP connection to that server. TCP is the protocol that guarantees the data arrives complete and in order; in HTTPS, that connection goes to port 443. Opening it costs a network round trip: the browser says hello, the server replies, they're in sync.
If the site uses HTTPS —as any bank should—, before sending a single useful byte the TLS handshake happens: browser and server negotiate the encryption and verify the site's certificate. Only once that tunnel is ready does anything real travel. The reasoning behind TCP versus its alternative is in TCP vs UDP, and what that padlock actually protects is in HTTP and HTTPS.
3. The HTTP request
With the tunnel open, the browser finally sends the HTTP request:
something like GET /accounts, plus a set of headers stating who's
asking, which language it prefers and which caches it carries. It's the concrete
ask: "give me this resource".
- The browser sends the request: method (
GET), path (/accounts) and headers. - The server processes it and responds with a status code (
200if all went well,404if it doesn't exist,301if it redirects…). - Along with the code, the server returns the body: usually the page's HTML.
That status code and that HTML are the response. The details of what travels in each request and what stays protected by encryption are in HTTP and HTTPS: what travels in the clear and what the padlock protects.
4. The browser builds the page
Receiving the HTML doesn't mean having the page ready: it means having the blueprint. The browser parses that HTML and, as it reads it, discovers it needs more things: stylesheets (CSS), scripts (JS), images, fonts.
For each of those resources, the browser fires a new request —and each one repeats, in part, the previous cycle: it may require another DNS resolution, another connection, another response—. As they arrive, the browser builds the visual tree, applies the styles, runs the JavaScript and finally renders: it paints the page you see. A single URL can end up generating dozens of requests.
What's along the way
None of this travels in a straight line. Between your browser and the final server, the request crosses DNS resolvers, routers that route it hop by hop, and often CDNs (which serve a nearby copy of the content), proxies and load balancers that spread traffic across servers. Each piece exists to go faster or handle more load, but each is also a point where something can stall.
- DNS: the name
bank.comis translated into an IP address. - TCP: the browser opens a connection to that IP (port 443 in HTTPS).
- TLS: browser and server negotiate the encryption and verify the certificate.
- HTTP: the browser sends the request (
GET /...). - Response: the server returns a status code and the HTML.
- Render: the browser parses, requests more resources and paints the page.
The banking angle
When the page is a customer's online banking, this choreography stops being a curiosity and becomes a responsibility. Each layer adds latency and, at the same time, is a point of failure: a slow DNS resolution or a distant server feels like "the bank is slow", even when the problem is far upstream of the backend.
That's why, in banking, specific things are guarded:
- Reliable DNS resolution —with redundancy and low latency—, because if that first hop fails, no page matters.
- Mandatory TLS —never plain HTTP—: a customer's data never travels readable across the network.
- Measuring the time of each hop: DNS, connection, server response, render. Only by measuring each leg do you know which one dominates when something is slow.
A simple URL hides a choreography: name to number, connection, request, response and render, each step leaning on the one before. Understanding that sequence is, literally, understanding how the web works —and knowing exactly where to look when it stops working.
