Exercise 3: A Request That "Hangs Forever" Instead of Failing — Possible Solution
====================================================================

Likely cause:

Per the chapter's own warn-box, "a firewall or NAT device silently
dropping any part of the three-way handshake -- most often the SYN-ACK
on the way back -- causes a connection attempt to hang or time out in
a way that's genuinely indistinguishable, from the user's side, from a
server that's simply slow to respond." A request that hangs
indefinitely, rather than failing quickly and cleanly with an explicit
error, is exactly the symptom this scenario describes -- and per the
chapter, this specific symptom is a strong indicator that the TCP
handshake itself never completed, not that a real, working connection
exists but is merely responding slowly.

Why this looks like slowness rather than an outright failure:

If a server were reachable but genuinely slow, the client would still
have a fully established TCP connection (the three-way handshake would
have completed normally, since nothing was blocking it) -- the delay
would be happening entirely at the application layer, after the
connection was already up, while the server took its time producing a
response. But if the SYN-ACK itself is being silently dropped by a
firewall or NAT device somewhere along the path, the client's initial
SYN is simply never acknowledged at all -- per the chapter's own
handshake steps, without step 2 (SYN-ACK) completing, there is no
established connection for the server to even begin working on a
response over. The client is left waiting on a connection attempt that
will never resolve on its own, which presents as an indefinite hang
rather than a clean, fast failure, because nothing ever explicitly told
the client the attempt failed -- the packets carrying that information
were simply dropped, not rejected with an error.

Why this diagnosis matters:

Per the chapter's own point, this is "a common, confusing source of
misdiagnosed connectivity issues" -- someone troubleshooting this
symptom by focusing entirely on the server's own performance (checking
server load, database query times, and so on) would be looking in the
wrong place entirely if the real problem is a handshake being silently
dropped somewhere in the network path before the server was ever
truly involved.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific mechanism (a silently dropped SYN-ACK
leaving the handshake incomplete) and explains why that specific
failure mode produces an indefinite hang rather than a clean error,
directly using the chapter's own warn-box and handshake-step
explanation rather than guessing at generic "server slowness."