../courses.php

The Server's Role

ASERVER

90

The Journey Of A Web Request

Why an address has to be translated before the avatar's request can go anywhere at all.

A user's browser is told to fetch a page from a perfectly correctly typed address. Before the request can even be sent toward the right server, an entirely separate request, to a completely different system, has to succeed first, one the user never typed anything for and never sees happen. If that separate, invisible request fails, the original one never even gets attempted. What is this hidden first step, and why does it have to happen before anything else can?

A web address names a host using a domain name, but the actual network connection a browser makes needs a numeric address, an IP address, not a name. DNS, a separate lookup system, translates the domain name into that numeric address first. This lookup is its own request and response, sent to its own separate set of servers, and the browser cannot send the real request to the right destination at all until this translation step succeeds.

A request's journey begins with the browser needing a numeric IP address for the host named in the URL, since the underlying network has no way to route anything to a domain name directly.

DNS, the Domain Name System, is the separate lookup system that turns a domain name into its current numeric IP address, through its own request and response, before the browser's real request is sent anywhere.

Once the IP address is known, the browser opens a network connection to the server at that address, and only then sends the actual request, the kind of GET or POST request covered in the previous track.

The server receiving that request commonly is not the only computer involved. Many sites place another system in front of the actual server, such as a reverse proxy or a content delivery network, that receives the request first and decides where to actually send it.

The full response then has to travel back along the same general path, through whatever sat in front of the server, back across the network, and finally to the browser, before anything can be displayed.

A request's hidden first step, and the request that follows it

nslookup performs exactly the same kind of DNS lookup a browser performs automatically before sending any request. Running it manually makes a normally invisible step visible.

The returned address is what the browser actually uses to open a connection. The domain name itself is never transmitted at the network level the way the IP address is.

Even though the connection goes to a numeric address, the request still states the original domain name in a Host header, because one server at one IP address can be hosting several different domains at once, and needs to know which one was actually asked for.

The final comment, noting where the request was actually sent, is the entire point of this lecture: the request's destination and the request's stated host are two different pieces of information, resolved by two different mechanisms.

A domain name that does not resolve to any address at all stops the entire process before a connection is even attempted, producing a specific kind of failure, distinct from a connection that is attempted and then refused or timed out.

A DNS failure and a server failure look completely different to the avatar

A domain name that fails to resolve at all produces an error before any connection is even attempted, commonly a DNS lookup failure, which is a categorically different message from a connection that was attempted and timed out or was refused, even though both ultimately mean the page does not load.

One IP address can answer for many different domain names

Because a request states its intended host separately, in its own header, a single server at a single IP address can correctly answer requests for several entirely different websites, deciding which one was actually meant based on that Host header alone, not based on which IP address was used to reach it.

What sits in front of the real server changes who actually answers first

A request passing through a reverse proxy or a content delivery network is answered, at least initially, by that intermediate system, not by the actual server hosting the site's own code. Diagnosing a problem by only checking the real server can miss an issue that is actually happening at this earlier stage.

DNS results do not update everywhere at the same instant

Changing which IP address a domain name points to does not take effect immediately and uniformly everywhere. Different systems across the internet can hold onto an old, cached answer for some time, which is why a DNS change can appear to work for some visitors and not others for a while afterward.

A correctly typed address can still fail for a reason that has nothing to do with the address itself

Every part of this journey, the DNS lookup, the connection, any intermediate system, and the server itself, can fail independently. A perfectly correct, perfectly typed address gives no guarantee that any one of these separate steps will actually succeed.

Checking only the server when a site won't load

Checking DNS resolution before checking the server itself

When an AI tool diagnoses a site that will not load, three things are worth checking. First, does it check DNS resolution as a separate, earlier step before assuming the problem is on the server itself. Second, does it account for an intermediate system, such as a proxy or CDN, that might be answering before the actual server is ever reached. Third, does it correctly distinguish a DNS failure from a connection failure as two different categories of problem.

Run an nslookup-style lookup against a real domain, and identify the IP address it currently resolves to.

Predict what error a browser shows for a domain name that does not exist at all, versus one that exists but whose server is unreachable, then check both.

Explain why a single server can correctly answer requests for several different domain names at once.

Find a real website that uses a content delivery network, and explain, based on its response headers, what evidence suggests an intermediate system answered first.

Explain, in your own words, why changing a domain's DNS records does not take effect identically for every visitor at the same moment.

Assuming a page failing to load is always a problem with the server itself, without first checking whether the domain name resolved at all.

Forgetting that one IP address can host more than one domain, and that a request's Host header, not its destination address, decides which site actually answers.

Diagnosing a problem only at the final server, missing an issue actually occurring at an intermediate system such as a proxy or CDN.

Expecting a DNS change to take effect identically and immediately for every visitor everywhere.

Treating "the address is typed correctly" as proof every step of the request's journey will succeed, when each step can fail independently of the others.

You can now trace a request's full journey, from a domain name through DNS, to a numeric address, through any intermediate systems, to the actual server, and back. You can also tell apart a DNS failure from a connection failure, and explain why one IP address can correctly answer for many different domain names.