Exercise 1: What a Healthy Network Path Still Doesn't Confirm — Possible Solution
====================================================================

WHAT CHAPTER 5's CHECKS ACTUALLY CONFIRM
------------------------------
A clean ping and a complete traceroute confirm that packets can travel
from here to the destination machine - the network path itself is
healthy. Neither check involves the specific application or port at
all; per this chapter, they say "nothing about whether anything on
that machine is actually listening on the specific port the
application needs."

WHY THAT'S NOT THE SAME AS THE APPLICATION WORKING
------------------------------
Per this chapter, "a server can respond to ping perfectly while the
specific service you care about... has crashed, was never started, or
is deliberately firewalled off from where you're testing." The network
path being healthy and the specific service being available are two
separate facts - one doesn't imply the other.

WHAT THIS CHAPTER'S CHECKS ADD
------------------------------
Per this chapter, "the only way to confirm the actual port is to try
connecting to it directly" - tools like telnet, nc, and curl -v attempt
a real TCP connection to the specific port in question, which
confirms (or rules out) whether something is actually listening and
accepting connections there, closing the gap Chapter 5's network-level
checks leave open.

WHY THIS WORKS AS AN ANSWER
------------------------------
It distinguishes the network-layer fact Chapter 5 confirms from the
port/service-layer fact this chapter confirms, using the chapter's own
stated reasoning for why one doesn't imply the other, and correctly
identifies what a direct connection attempt adds on top of a clean
ping/traceroute.