Exercise 3: Three Different Places "The Website Won't Load" Could Actually Be Failing — Possible Solution
====================================================================

Using the chapter's own journey -- "a DNS lookup... routing across a
chain of networks... a TCP handshake... and finally an actual HTTP
request and response" -- at least three fundamentally different points
where "the website won't load" could actually originate:

1. DNS resolution failure. If the domain name itself can't be turned
into an IP address -- the DNS lookup step -- the browser never even
learns which server to contact. This would look identical to the user
as any other kind of failure ("the website won't load"), but the
actual problem has nothing to do with the website's server at all; it
never got contacted in the first place.

2. Routing failure. Even if DNS resolves the domain to a correct IP
address, the packets attempting to reach that address have to be
routed across a chain of networks. If routing breaks down somewhere
along that path -- anywhere between the user's own network and the
destination -- the connection attempt would time out or fail, again
looking to the user like "the website won't load," despite DNS having
worked perfectly and the destination server being completely healthy.

3. TCP handshake or application-layer failure. Even once the correct
IP address is known and the network path is routable, the actual
server might not respond correctly at the point of establishing the
connection (the TCP handshake itself failing or being refused) or
could accept the connection but fail to send back a valid HTTP
response (an application-layer problem, e.g. the web server software
itself has crashed or is overloaded). Both of these would present to
the user exactly the same as the previous two scenarios, despite being
completely different failures happening much later in the journey.

The point of naming these three separately: because all three produce
the identical user-facing symptom ("the website won't load"), the
chapter's own framing -- "knowing which layer the problem most likely
lives in... is what separates a systematic diagnosis from random
guessing" -- is exactly what would let someone actually distinguish
between these three genuinely different causes, rather than guessing
or assuming the entire website is simply "down" as a single
undifferentiated failure.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies three genuinely distinct failure points spanning the
chapter's own named journey (DNS, routing, and the
handshake/application layer together), and explains why they all look
identical to an end user despite being fundamentally different
problems -- directly illustrating the chapter's own point about why
layer-awareness matters for real diagnosis.