The Journey of a URL: From Typing to Display

Open a browser, type www.irctc.co.in, press Enter. Less than a second later, a full webpage sits on your screen — text, images, buttons, all in place. Most students treat that second as a black box: "the internet did something." But that one second is not one operation. It is a precise sequence of five separate, well-defined stages, each governed by its own protocol, each capable of failing on its own, and each traceable step by step, the same way you would trace a program's execution line by line. This chapter opens that black box and walks through every stage in order, with real numbers, real message formats, and the exact terms used in networking.

Stage 0: A URL Is Not a Web Address — It Is a Structured Instruction

Before tracing the journey, you need to correctly read the map. Consider this real-looking URL from an Indian government booking site:

https://www.irctc.co.in/nget/train-search?trainNo=12951&date=2026-07-30#results

This single string is not one thing — it is five distinct pieces glued together, and each piece is used for a different purpose by a different part of the system:

• Scheme — https. Tells the browser which protocol to speak, and implies a default port: http means port 80, https means port 443. You can override the default explicitly, as in https://example.in:8443/.
• Host (domain) — www.irctc.co.in. The name of the server to contact. This is the only part DNS ever looks at.
• Path — /nget/train-search. Tells the server's application which resource or page you want, inside that domain.
• Query string — ?trainNo=12951&date=2026-07-30. A list of key=value pairs separated by &, sent to the server as parameters — here, "which train" and "which date."
• Fragment — #results. This part is special and frequently misunderstood: it is never sent to the server at all. It is resolved entirely inside your own browser, after the page has already loaded, to jump to a section of the page (an element with id="results").

A URL is actually a special case of a more general idea called a URI (Uniform Resource Identifier) — a syntax for naming a resource, not necessarily a web page. Indian UPI payment apps use exactly the same bracket-and-parameter syntax with a different scheme: a link like upi://pay?pa=merchant@upi&pn=Chai+Stall&am=20&cu=INR opens your UPI app directly to a pre-filled payment screen instead of asking a web server for HTML. Same structural idea — scheme, then parameters — put to a completely different use. Keeping "URL" and "domain name" as separate ideas matters: the domain is only one of the five pieces above, not the whole address.

Stage 1: Turning a Name into a Number — DNS Resolution

Computers do not locate each other by name. They locate each other by IP address — a number such as 192.0.2.10 (this particular one is a reserved example address, not a real site, used here so we don't misstate anyone's actual server). Names like www.cbse.gov.in exist purely for humans; somewhere, that name has to be converted into a number before a single byte can be sent. The system that does this conversion is the Domain Name System, or DNS — effectively the internet's phone book, except it is not stored in one place. It is split across millions of servers worldwide, organized as a hierarchy, and your request walks down that hierarchy one level at a time.

Here is the exact sequence your computer performs the first time it needs the address for www.cbse.gov.in (a "cold" lookup, nothing cached yet):

1. The browser checks its own cache — has it resolved this name in the last few minutes? If yes, the whole process below is skipped entirely and the cached IP is used immediately.
2. If not cached, the operating system asks a recursive resolver — usually run by your ISP (Jio, Airtel, BSNL), or a public one such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. This resolver does the heavy lifting on your behalf.
3. If the resolver itself has nothing cached, it asks a root server: "who is responsible for the .in part?" The root server does not know the final answer — it only points further down the hierarchy, replying with the address of the .in top-level-domain (TLD) servers.
4. The resolver asks a .in TLD server: "who is responsible for gov.in?" (India's .in registry is operated by NIXI — the National Internet Exchange of India.) The TLD server replies with the address of the authoritative name servers for gov.in.
5. The resolver asks that authoritative server: "what is the IP address for www.cbse.gov.in, specifically?" This server actually owns the answer and replies with the real IP address.
6. The resolver caches this answer for future requests (respecting a "time to live" set by the domain owner) and hands it back to your browser.

Notice this is not one message — it is a referral chain, each hop narrowing the search: root → TLD → authoritative. If each hop costs roughly one round trip of about 20 milliseconds, a fully cold lookup can take 60–100 ms. But this expensive path is rare in practice: because resolvers cache aggressively, the overwhelming majority of real-world lookups are answered from a cache in under a millisecond. This is the same caching idea you'll meet again and again in computer science — trade a little memory for a lot of speed.

A common misconception, corrected: many students assume DNS "loads the website." It does not, and it never touches a single byte of HTML, CSS, image, or video. DNS's only job, from start to finish, is translating a name into a number. After DNS finishes, your browser knows exactly one thing it didn't know before — an IP address to knock on next. It has received zero content.

Stage 2: Building a Reliable Pipe — the TCP Three-Way Handshake

Your browser now has the server's IP address. But the underlying transport of the internet (the IP protocol) makes no promises — packets can arrive out of order, arrive twice, or not arrive at all. Before any real data is exchanged, the browser and server use TCP (Transmission Control Protocol) to establish a connection that guarantees ordered, reliable delivery. This setup is called the three-way handshake, and it happens before a single byte of your actual request is sent.

Think of it like a phone call before a conversation: you don't launch straight into your question the instant the line connects — there's a beat where both sides confirm the connection works. TCP does exactly that with three messages:

1. Client → Server: SYN. "I'd like to start a connection; here's my starting sequence number (say, 1000), which I'll use to keep my messages in order."
2. Server → Client: SYN-ACK. "Got it — I acknowledge your sequence number (1001, i.e., yours +1). Here is my own starting sequence number (say, 5000)."
3. Client → Server: ACK. "Acknowledged — your sequence number is 5001."

Only after this three-message exchange completes is the connection considered "established," and only then can the browser send its actual request. This handshake costs exactly one full round trip (RTT) of pure setup time before anything useful happens — an unavoidable tax paid on every fresh connection.

Stage 3: Locking the Conversation — the TLS Handshake (HTTPS Only)

If the scheme was https (as it should be for anything handling personal data — booking details, passwords, payment information), one more negotiation happens before your request goes out: the TLS (Transport Layer Security) handshake. The server presents a digital certificate, issued by a trusted Certificate Authority, proving it is genuinely www.irctc.co.in and not an impostor intercepting your connection. Using that certificate, the browser and server agree on a shared secret encryption key, and from that point on, every byte exchanged between them — the request, the response, everything — is scrambled so that only the two of them can read it. The padlock icon in your address bar is simply the browser telling you: "this handshake succeeded, and this connection is encrypted." Plain http skips this stage entirely, which is exactly why it shows no padlock and why sensitive Indian government and banking portals always use https.

Precision matters here: the older TLS 1.2 requires two full round trips to complete its handshake; the newer TLS 1.3, now the default on most modern servers, was specifically redesigned to need only one.

Doing the Arithmetic: How Long Does All This Setup Actually Take?

We now have enough pieces to calculate something real. Let RTT stand for the round-trip time between your device and the server — the time for a signal to travel there and back. Suppose a student in Chennai has an RTT of 50 ms to a particular server (a reasonable number for a decent Indian broadband or 4G connection to a server that isn't too far away). "Time to first byte" (TTFB) — the moment the browser receives the very first byte of the HTML response — can be estimated as:

TTFB ≈ (RTT_dns + RTT_tcp + RTT_tls + RTT_http) × RTT

Using round numbers: a cold DNS lookup through the referral chain costs about 2 round trips; the TCP handshake costs 1; a TLS 1.3 handshake costs 1; and the first HTTP request/response exchange costs 1. That's a coefficient of 2 + 1 + 1 + 1 = 5, so:

TTFB ≈ 5 × 50 ms = 250 ms

Now compare two realistic variations, using the same simple multiplication:

• With the older TLS 1.2 (2 round trips instead of 1): coefficient becomes 2+1+2+1 = 6, so TTFB ≈ 6 × 50 ms = 300 ms — a full 50 ms slower, purely from an older security protocol.
• With a warm DNS cache (0 extra round trips instead of 2, since the answer is already sitting in memory): coefficient becomes 0+1+1+1 = 3, so TTFB ≈ 3 × 50 ms = 150 ms — 100 ms faster than the cold case, just from caching.

This is the same reasoning engineers use to decide where to spend effort improving a website's speed: each stage has a concrete, addable cost, and shaving a stage off (through caching, or upgrading a protocol) has a directly calculable payoff.

Stage 4: The Actual Ask — HTTP Request and Response

The pipe is now built (and, for HTTPS, encrypted). Only now does the browser send the thing you actually asked for: an HTTP request. It is literally a small, precisely formatted block of text — you can read every line of it:

GET /nget/train-search?trainNo=12951&date=2026-07-30 HTTP/1.1
Host: www.irctc.co.in
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-IN,hi;q=0.9

Reading it line by line: the request line names the method (GET — "give me this resource," as opposed to POST, which sends data to the server, used when you submit a form), the path plus query string, and the HTTP version. The Host header exists for an important reason many students miss: a single IP address frequently hosts hundreds of different domains on the same physical server (called "virtual hosting"), so the server needs this header just to know which website you actually meant. User-Agent identifies the browser and operating system. Accept-Language tells the server your preferred language — many Indian users configure en-IN or hi here, which is how some sites serve Hindi content automatically.

The server receives this, looks up the path, possibly queries a database (in IRCTC's case, real seat availability for train 12951 on that date), and sends back a response — also just structured text, followed by the actual page content:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 48213
Set-Cookie: sessionid=a93f7c1e...

<!DOCTYPE html>
<html>...

The status line's three-digit code is worth knowing precisely, since it appears constantly in exams and in real debugging:

• 200 OK — success, the requested content follows in the body.
• 301 / 302 — redirect: "the resource has moved, go fetch this other URL instead" (commonly used to force an upgrade from http:// to https://).
• 404 Not Found — the server exists and responded, but nothing lives at that specific path.
• 500 Internal Server Error — the server itself crashed or hit a bug while trying to build the response.

A second misconception, corrected: students often picture this one response as delivering the entire page — images, fonts, styling, and all. In reality, this first response usually contains only the raw HTML text. As the browser reads that HTML, it discovers references to other resources — a <link> to a stylesheet, an <img> tag, a <script> tag — and fires off separate, additional HTTP requests for each one, often dozens of them, many in parallel. A single "page load" is frequently the result of thirty, fifty, or more individual request/response exchanges, not one.

Stage 5: Turning Text into Pixels — the Rendering Pipeline

The browser now holds raw HTML bytes. Converting that text into the picture on your screen is itself a precise, ordered pipeline inside the browser's rendering engine (Chrome and Edge use one called Blink; Firefox uses Gecko):

1. Parse HTML → DOM tree. Every tag becomes a node in a tree structure called the Document Object Model. <body> contains <p>, which contains a text node, and so on.
2. Fetch and parse CSS → CSSOM. The moment the parser hits a <link rel="stylesheet">, it fires the HTTP request for that CSS file (a repeat of Stage 4, but for a different file) and builds a second tree of style rules called the CSS Object Model.
3. Combine DOM + CSSOM → Render Tree. Only the nodes that will actually be visible are kept — the <head> is dropped, elements styled display: none are dropped — and each remaining node is paired with its final computed style.
4. Layout (also called reflow). The browser walks the render tree and computes the exact pixel position and size of every single box, respecting each element's width, margins, and padding (the "box model"). This is effectively solving a set of geometric constraints, top to bottom.
5. Paint. The browser fills in actual pixels — text glyphs, background colors, borders, images — for every box, according to the geometry Layout computed.
6. Composite. Separate painted layers (there can be several, especially with things like fixed headers or animations) are assembled by the GPU into the single final image you see.

Trace this on a tiny concrete example:

<!DOCTYPE html>
<html>
  <head><style>p { color: navy; }</style></head>
  <body><p>Hello</p></body>
</html>

The DOM tree is html → (head, body), with body → p → "Hello". The CSSOM has exactly one rule: p maps to color: navy. The render tree keeps only body → p → "Hello" — the head and its style tag are never painted, only used to build the CSSOM. Layout assigns the p box a position starting at the top-left of the content area, with a width equal to the viewport and a height tall enough for one line of text. Paint fills that box with the word "Hello" rendered in navy blue at that exact position. Composite places this single layer on screen. That is, in miniature, exactly what happens for a page with a thousand elements instead of one.

A third misconception, corrected: students often imagine a page "loads" the way a photograph loads — steadily, top to bottom, once, and then it's done. Real browsers don't wait for every resource before painting anything; they paint as soon as they have enough to show something useful. But this creates a real cost: if a stylesheet or a font arrives late and changes an element's size, the browser must redo Layout and Paint for everything affected — called a reflow. Pages that trigger many reflows (for example, by changing element sizes repeatedly through JavaScript) visibly jump around and feel slow; this is a genuine, measurable performance problem, not just a cosmetic annoyance.

The Full Journey, Visualized

Summary

• A URL has five parts — scheme, host, path, query string, fragment — and only the host is used to find the server; the fragment never leaves the browser.
• Stage ① – DNS translates the host name into an IP address by walking a hierarchy (root → TLD → authoritative), and answers nothing about page content.
• Stage ② – TCP handshake (SYN, SYN-ACK, ACK) establishes a reliable connection before any data is exchanged, costing one round trip.
• Stage ③ – TLS handshake (HTTPS only) verifies the server's identity and negotiates encryption, costing one round trip with TLS 1.3 or two with the older TLS 1.2.
• Stage ④ – HTTP request/response is the actual exchange: a GET request with headers like Host and Accept-Language, answered with a status code (200, 301/302, 404, 500) and, on success, the HTML body — followed by many more requests for CSS, images, and scripts discovered inside that HTML.
• Stage ⑤ – Rendering converts HTML into a DOM tree and CSS into a CSSOM, merges them into a render tree, computes geometry (Layout), fills in pixels (Paint), and assembles the final image (Composite) — and can repeat Layout and Paint mid-page as a "reflow" when late resources change element sizes.
• Total setup time before your first byte of content is the sum of the round trips spent on DNS, TCP, and TLS — which is exactly why caching (skipping DNS) and modern protocols (TLS 1.3 over 1.2) measurably speed up every website you visit.

Check Your Understanding

1. In the URL https://exams.cbse.gov.in/results?roll=4521&year=2026#marks, identify the scheme, host, path, query string, and fragment. Which part is never sent to the server?
2. A friend says, "DNS is what actually sends you the HTML of the webpage." Explain precisely why this is incorrect, and state what DNS's job actually is.
3. Put these in the correct order and name the protocol responsible for each: (a) HTTP GET request sent, (b) TLS certificate verified, (c) SYN sent, (d) DOM tree built, (e) authoritative name server replies with an IP address.
4. Why does an HTTP request need a Host header at all, if the browser already connected to the correct IP address using TCP?
5. A server responds with status code 404. Has the TCP connection and TLS handshake succeeded or failed? What has actually gone wrong?
6. Using RTT = 40 ms, and assuming a warm (cached) DNS lookup, a TCP handshake, a TLS 1.3 handshake, and one HTTP request/response, calculate the estimated time to first byte.
7. Explain, using the terms DOM, CSSOM, Layout, and Paint, what has to happen again if a web font that changes text size finishes downloading after the page has already been painted once.

Answer key: (1) scheme=https, host=exams.cbse.gov.in, path=/results, query=roll=4521&year=2026, fragment=#marks (never sent to the server — resolved locally in the browser). (2) DNS only translates a domain name into an IP address; it never transmits HTML, CSS, images, or any page content — that only happens later, via HTTP. (3) Correct order: c (TCP, Stage ②) → b (TLS, Stage ③) → a (HTTP, Stage ④) → d (rendering, Stage ⑤); note (e), the DNS answer, actually comes first of all, in Stage ①, before TCP can even begin. (4) Because a single IP address commonly hosts many different domains on one server (virtual hosting); without the Host header, the server would not know which of those domains you actually meant to reach. (5) TCP and TLS have both succeeded — a 404 is an HTTP-level response, meaning the connection is fully working and encrypted, but the server found nothing at that specific path. (6) coefficient = 0 (cached DNS) + 1 (TCP) + 1 (TLS 1.3) + 1 (HTTP) = 3; TTFB ≈ 3 × 40 ms = 120 ms. (7) The browser must redo Layout (recompute box sizes and positions using the new text size) and then Paint again over the affected area — a reflow — before Compositing the updated image.