Step 36. UDP and ICMP — The Courier Who Throws and the Status Hotline

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★☆☆☆ | Estimated time: 3 hours

Prerequisites: Step 35 (TCP) must be finished. Work in Windows PowerShell. If you have an Ubuntu virtual machine, you can run the same practice with Linux commands too.

• What you need: a Windows PC, PowerShell, an internet connection.
• Caution: this section’s practice is read-only in the stated lab. Only diagnostic commands (ping, Test-NetConnection). All we do is ask my computer and public servers “please answer”; there isn’t a single command that changes settings.

Last chapter’s TCP was a courteous courier. Shake hands, confirm, keep the order. But there are situations in the world where such etiquette is a luxury. In a video call, if a 0.1-second slice of voice goes missing, ordering that slice again and receiving it 0.5 seconds later — that’s not help, it’s a disaster. It’s the sound of a moment already past. For such worlds, we need a courier who just throws: UDP. And ICMP, which we learn together today, is not a courier but “the network’s status hotline.” The ping you’ve already used a hundred times is a product of this very ICMP.

1. Learning Objectives

By the end of this unit, you will be able to:

• Explain the difference between TCP and UDP by the criterion “is it meaningful to receive the missing piece again?”
• Reason about why a given service chose UDP
• Explain that ping’s true identity is ICMP echo request/reply, and read the time and TTL in ping output
• Explain why “ping fails = the server is dead” is wrong, and know how to cross-check
• Use a diagnostic ladder that splits the vague report “the internet isn’t working” into per-layer questions

2. Background Knowledge — Today’s Tools and Concepts

This section’s Tools at a Glance

2-1. UDP — Throw It and Forget It

The philosophy of UDP (User Datagram Protocol) is simple:

• No handshake: it doesn’t establish a connection. It just sends.
• No confirmation: it doesn’t ask whether it arrived.
• No retransmission: if it’s lost, it’s lost. Order isn’t guaranteed either.

UDP avoids a transport connection handshake and has a small header. Actual latency and throughput depend on the network and application; UDP is not automatically faster. Applications can implement acknowledgments, congestion control, or retransmission over it.

2-2. Reliability vs Speed — Not Superiority, but Purpose

TCP and UDP are not better and worse — they’re different purposes:

Choose a protocol according to application requirements, including latency, reliability, congestion control, and compatibility. Streaming may use reliable TCP or QUIC as well as other UDP-based designs; a service label alone does not determine its transport.

2-3. ICMP — The Report from the Network’s Control Room

ICMP (Internet Control Message Protocol) is not a protocol for carrying data but an administrative protocol for reporting network status. The three representative messages:

• Echo request/reply: “Are you there?” / “Yes, I’m here.” — this is the true identity of ping.
• Destination unreachable reports a forwarding or delivery problem identified by its code. It does not generally mean that the destination address does not exist.
• Time exceeded: “the letter wandered too long and was discarded.” (TTL expired)

So ping is not some separate magic program — it was a tool that sends the echo message of the ICMP administrative protocol and times how long the reply takes to return.

2-4. TTL — The Lifespan Attached to Letters

Every packet carries a number called TTL (Time To Live). It usually starts at 64 or 128 at departure, and decreases by 1 each time it passes a router (a signpost connecting neighborhood to neighborhood). At zero, it’s discarded on the spot. A safety device so that even if signposts mistakenly point at each other, letters don’t spin around forever.

In this section’s practice, this TTL serves as a hint for guessing “how far away the other side is.” A same-neighborhood neighbor arrives barely decremented, while a server in a faraway country arrives heavily decremented.

3. Follow Along

Before you begin. UDP supplies datagrams without delivery or ordering guarantees. An application can add reliability: QUIC and HTTP/3 are examples. DNS supports both UDP and TCP, and encrypted DNS transports also exist. Protocol choice cannot be inferred from an application category alone.

3-1. Firing ICMP Yourself with ping

ping -n 4 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114
Reply from 8.8.8.8: bytes=32 time=32ms TTL=114
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114
Reply from 8.8.8.8: bytes=32 time=33ms TTL=114

Ping statistics for 8.8.8.8:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 32ms, Maximum = 33ms, Average = 32ms

Illustrative output. Values, wording, account names, and available fields vary by environment.

New command — ping -n 4: -n 4 means “send it just four times” (on Linux, ping -c 4). Without it, Windows defaults to four, and Linux keeps sending until you stop it.

How to read the output: each line is one echo round trip. time=33ms is how long the round trip took (milliseconds, thousandths of a second); TTL=114 is the number of neighborhoods left before the letter dies. In the statistics below, Lost = 0 (0% loss) means all four letters got replies. 8.8.8.8 is Google’s public DNS server, a good test partner that answers almost always.

Why: just now, you fired and received an ICMP message yourself. The once-mysterious ping has become today “a message of a protocol I know.”

3-2. Comparing TTL — Near and Far

This time, ping our home router (the default gateway). If you don’t know the gateway address, check first with ipconfig (the example computer’s was 172.30.1.254. Yours is most likely something like 192.168.0.1):

ping -n 4 172.30.1.254

Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64
Reply from 172.30.1.254: bytes=32 time<1ms TTL=64

Illustrative output. Values, wording, account names, and available fields vary by environment.

This illustrative gateway reply has a round-trip time below 1 ms and TTL 64. If its initial TTL was 64, no forwarding decrement occurred on the return path. The other reply has TTL 114; assuming an initial 128 suggests fourteen decrements. State that assumption explicitly.

Prediction: record whether a permitted target replies and its received TTL. Explain why the initial TTL and return path must be known before inferring hop count.

3-3. Why Is DNS UDP?

Recall the DNS lookups from Step 33. “What’s the IP for this name?” — “142.250.206.46.” A short transaction that ends with one question and one answer.

DNS commonly uses UDP for small queries, but DNS implementations also support TCP. Truncation and larger responses are examples where TCP matters. Connections can be reused; a new handshake and close are not required for every query. Encrypted DNS transports add further possibilities.

How to read it: there’s a reason behind every protocol choice. The habit of asking “why did this service choose this protocol?” makes you see networks in three dimensions.

3-4. Feeling UDP’s Loss (Thought Experiment)

Instead of an experiment that actually drops packets, let’s do a thought experiment. Suppose 1 out of 10 UDP letters disappears during a video call.

• With TCP, missing bytes can delay delivery of later bytes until recovery. The amount of delay depends on loss detection, round-trip time, and the application; there is no fixed half-second pause.
• Because it’s UDP: at that moment the screen breaks into blocks or the sound cuts out, and it moves right on to the next slice.

Momentary media breakup has several possible causes, including loss, congestion, jitter, and application behavior. This thought experiment illustrates a latency tradeoff; it does not identify the cause of every real video-call problem.

3-5. “ping Fails but the Site Opens” — Correcting the #1 Misjudgment

ping -n 4 www.cloudflare.com

Pinging www.cloudflare.com [104.16.123.96] with 32 bytes of data:
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55
Reply from 104.16.123.96: bytes=32 time=3ms TTL=55
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55
Reply from 104.16.123.96: bytes=32 time=4ms TTL=55

Illustrative output. Values, wording, account names, and available fields vary by environment.

The illustrative output above shows successful echo replies. In a different run, echo may time out while HTTPS works. That difference suggests protocol or path-specific behavior, not a proven configuration or cause.

The cross-check for such cases is the port knocking from Step 34:

Test-NetConnection www.google.com -Port 443

ComputerName     : www.google.com
RemoteAddress    : 142.251.153.119
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 172.30.1.54
TcpTestSucceeded : True

Illustrative output. Values, wording, account names, and available fields vary by environment.

TcpTestSucceeded: True reports successful TCP connection establishment to the tested address and port. It does not validate TLS, HTTP content, or a different address used by a browser.

Why: “ping failure = server down” is the beginner’s #1 misjudgment. Diagnosis always gathers multiple signals.

4. Missions & Exercises

Mission — Build a “The Internet Isn’t Working” Diagnostic Ladder

Imagine a friend calls and says “the internet isn’t working,” and complete the plan by actually running the diagnostic ladder:

1. Write the diagnostic order in your notebook: ① knock on the router with ping → ② knock on the outside world with ping -n 4 8.8.8.8 → ③ resolve a name with nslookup www.naver.com (Step 33 review)
2. Actually run each step and record the results in your notebook (in a normal environment all three will succeed — recording “what everything looks like when it works” is also data)
3. Next to each step, write one line: “if it fails here, which segment’s problem is it?”
4. Finally, add Test-NetConnection www.google.com -Port 443 to put a fourth question (“is the door open?”) on the ladder too

Exercises

Q1. For each of the following services, classify whether it uses TCP or UDP, with a one-line reason: ① a bank app’s transfer ② live sports streaming ③ DNS name lookup ④ bullet positions in an online FPS game ⑤ file downloads

Q2. What is ping’s true identity? Fill in the blanks in this format: “ping is a tool that sends the ○○ message of the ○○○○ protocol and times the reply.”

Q3. One reply has TTL 64 and another TTL 114. What can you infer without knowing their initial TTL values? Explain why the numbers do not directly measure geographical distance.

Q4. A web server doesn’t respond to ping, but it’s reachable in a browser. Is the server dead? What setting is likely, and what command can you use to further verify the server’s life?

① ping 172.30.1.254 (router)       → if it fails: problem between my device and the router (cable, Wi-Fi)
② ping -n 4 8.8.8.8 (outside world) → if it fails: problem in the router-to-ISP segment
③ nslookup www.naver.com (name)     → if it fails: DNS problem (Step 33)
④ Test-NetConnection ... -Port 443  → if it fails: problem with the far server or a middle firewall

① Reply from 172.30.1.254: bytes=32 time<1ms TTL=64     ← doorstep alive
② Reply from 8.8.8.8: bytes=32 time=33ms TTL=114        ← outside passage possible
③ Addresses: 223.130.192.247 plus 3 more (www.naver.com) ← name resolution OK
④ TcpTestSucceeded : True                                ← Google's port 443 open

6. Common Pitfalls & Fixes

Wall 1. “ping failed so I reported the server as dead.”

Symptom: you conclude “down” from ping failure alone.
Cause: a server that blocks ICMP stays silent to ping even when alive.
Fix: ping is just “one of several questions.” For a web server, connect with a browser or cross-check with Test-NetConnection address -Port 443. One signal’s silence is a clue, not a conclusion.

Wall 2. “They say UDP is fast — then why not do everything in UDP? Why TCP?”

Symptom: the fast thing looks better, so the question arises naturally.
Cause: UDP’s speed comes from “giving up confirmation.” For data that needs confirmation (files, account transfers, logins), that confirmation is the essence.
Fix: think of “fast” and “trustworthy” separately. The selection criterion is not speed but “is this data that must not be lost?”

Wall 3. “My ping time came out at 200 ms. Is it broken?”

Symptom: responses come, but the time is large.
Cause: if the other side is far (an overseas server), tens to hundreds of ms is normal given the speed-of-light limit. Korea to a US server at ~150 ms round trip is physics.
Fix: the standard is not an absolute number but “comparison to usual.” If the same target was usually 20 ms and suddenly reads 300 ms, that’s an anomaly signal. The baseline habit of recording usual numbers (Step 15) applies here too.

Wall 4. “I pinged a name but a strange name came back instead of the one I typed.”

Symptom: you ran ping www.microsoft.com and got a line like this (Illustrative source example):

Pinging e13678.dscb.akamaiedge.net [104.94.218.45] with 32 bytes of data:

Cause: not poisoning — the normal operation of a CDN (content delivery network). Large services like Microsoft keep replica servers worldwide, and at the name-lookup stage you’re directed to the name of “the server closest to the person connecting.” akamaiedge is a server of the CDN company Akamai.
Fix: it’s nothing strange — it’s a trace of Step 33’s DNS doing its job. Read it as “asked for a name and got back a different name and address = a service behind a CDN.”

7. Summary

This section’s Concepts

This section’s Commands

The Instinct That Matters More Than Commands

This section’s real harvest is “the skill of splitting questions.” “The internet isn’t working” is a tangle of: can’t resolve names (DNS), can’t complete handshakes (TCP), the road itself is cut (verified with ICMP). The moment the same “doesn’t work” splits into per-layer questions, the problem is half solved.

Remember two more things. First, the latest web standard HTTP/3 uses a protocol called QUIC, which rebuilds reliability on top of UDP — the program implemented on its own the confirmation the protocol gave up, a good example that “the classification table is not absolute.” Second, just because ICMP is administrative doesn’t make it innocent. In the past, attacks like the Ping of Death — downing systems with giant ping fragments — were in fashion, which is why many servers today restrict ICMP; the “silent servers” of Wall 1 carry this history. For the record, UDP has no handshake, so it’s hard to scan with “answer = open” the way TCP is. That a protocol’s character reshapes even the terrain of attack and defense — that’s why we learn protocols.

Once every box is checked, Step 36 is complete.