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: today’s practice is 100% safe. 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 chapter, 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

Today’s Tools at a Glance

Category	Details
Language/environment	PowerShell 5.1 (normal privileges are enough). An Ubuntu terminal is optional
Today’s commands	`ping -n 4 address` (Windows) / `ping -c 4 address` (Linux); review: `Test-NetConnection address -Port 443`, `nslookup`
Concepts needed	UDP (connectionless delivery), ICMP (status-reporting protocol), echo request/reply, TTL, reliability vs speed

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.

What it gains in return is speed and lightness. It skips the greetings and gets straight to the point, so delay is low, and with no confirmation procedure, the burden is small. If TCP is certified mail (proof of sending, confirmation of arrival, resend on loss), UDP is just a postcard.

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

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

Criterion	TCP	UDP
Connection	Established first (handshake)	None, just sends
Arrival confirmation	Yes (retransmission too)	No
Order guarantee	Yes	No
Speed/latency	Relatively slow	Fast
Used by	Web, SSH, mail, file transfer	DNS, video/voice calls, games, broadcast

The selection criterion is one: "Is it meaningful to receive the missing piece again?" A file is useless with even one character missing, so TCP. A 0.1-second slice of live video is useless if it arrives late, so UDP.

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: a return notice saying "that address doesn’t 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 today’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

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

(Measured 2026-09-09. On Korean Windows it displays in Korean, like 8.8.8.8의 응답: 바이트=32 시간=33ms TTL=114. Time and TTL will differ in your 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 measured 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

(Measured 2026-09-09. Replace the router address with your own.)

How to read it: two differences are visible. The time is time<1ms — same neighborhood, so it takes less than 1 ms. And TTL=64 — the number exactly as it departed, not decremented at all. Since the router is reached without passing through any router (it’s the same neighborhood), the lifespan stays intact. By contrast, 8.8.8.8 a moment ago was TTL=114 — if the other side departed at 128, the math says it passed 14 routers on the way.

Predict: if you run ping -n 4 www.naver.com with the same command, what will the TTL be? Larger than 64, or smaller? Write your prediction and check. (Hint: Naver isn’t our home either, so it passes routers.)

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.

Predict: if this short transaction used TCP, what would be wasted? Imagine the three handshake lines from Step 35. (Answer: for a single question you’d have to do "three hello lines + four goodbye lines," so the greetings are longer than the substance. That’s why ordinary DNS lookups are designed on UDP. For short, fast round trips, the throwing delivery fits.)

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.

If it were TCP: the screen freezes for 0.5 seconds while that one piece is retransmitted, and the recovered slice is a screen from a past that’s already gone.
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.

How to read it: the "momentary breakup" you experience in video calls is exactly UDP’s loss. And it’s not a malfunction but a designed trade-off — the result of the choice that nothing is better than something late.

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

(Measured 2026-09-09. In the measured environment, Cloudflare responded. In your environment, a response may or may not come.)

How to read it: if there’s no response yet the site opens in a browser, that is today’s key evidence. The server isn’t dead — it’s configured not to answer ICMP. Many servers ignore ping for administrative burden or security reasons.

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

(Measured 2026-09-09.)

How to read it: TcpTestSucceeded : True means the TCP handshake (SYN → SYN-ACK → ACK) succeeded. ping (ICMP) and port knocking (TCP) are questions of different layers. If one stays silent but the other answers, the server is alive.

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:

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)
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)
Next to each step, write one line: "if it fails here, which segment’s problem is it?"
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. You pinged one address and got TTL=64, and another address gave TTL=114. What does this difference tell you, and which side is the "closer" partner?

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?

5. Model Answers & Completion Criteria

Mission Model Answer

The principle of the diagnostic ladder is "from the lower floors, from the nearest place." The order and the meaning of each step:

① 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

Example run results from the measured computer (2026-09-09):

① 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
④ TcpTestSucceeded : True                                ← Google's port 443 open

How to verify: you ran the four steps in order, and next to each step is written "the segment to suspect on failure" — done. The power of this ladder is that it splits the one-liner "it doesn’t work" into four different illnesses — break at ① and it’s our house, at ② the line, at ③ the phone book (DNS), at ④ the other side. The question at which it breaks is the diagnosis itself.

Exercise Solutions

Q1 solution. TCP: ① transfers (a disaster if even one character goes missing), ⑤ file downloads (the file breaks if even one chunk is missing). UDP: ② sports streaming (a past frame that arrives late is useless), ③ DNS lookups (a short round trip of one question, one answer — greetings are a luxury), ④ FPS game positions (the position from 0.1 seconds ago matters less than the position now).

Q2 solution. "ping is a tool that sends the echo message of the ICMP protocol and times the reply." ping is not a separate program — it borrows a function of the network’s administrative protocol.

Q3 solution. TTL is a packet’s lifespan, decremented by 1 for each router passed. TTL=64 means the starting value (64) is nearly intact, so it’s a same-neighborhood partner that passed no routers (e.g., the router); TTL=114 means a faraway partner that departed at 128 and passed about 14 routers. The closer side is TTL=64 (confirmed by measurement on 2026-09-09 as well: router=64, 8.8.8.8=114).

Q4 solution. Most likely it’s not dead. The server is configured not to answer ICMP echo — many servers ignore ping for administrative burden or security reasons. Additional verification uses a question from another layer: test the TCP handshake with Test-NetConnection serveraddress -Port 443. The fact that browser access works is already evidence that "the server is alive and its port 443 is open."

Completion Criteria Checklist

[ ] I can explain the TCP/UDP difference by the criterion "is retransmission meaningful?"
[ ] I can reason about why each service chose its protocol
[ ] I can explain that ping is ICMP echo request/reply
[ ] I can read time (ms) and TTL in ping output, and estimate distance from TTL
[ ] I can explain why ping silence may not mean server down, and the cross-check method
[ ] I can recite the four steps of the diagnostic ladder in order
[ ] Mission: I ran the diagnostic ladder myself and completed the record

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 (measured 2026-09-09):

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

Today’s Concepts

Concept	One-line description
UDP	"Throwing delivery" with no handshake, confirmation, or retransmission — fast but can lose things
ICMP	The administrative protocol that reports network status (echo, unreachable, time exceeded)
ping	A tool that sends an ICMP echo request and times the response
TTL	A packet’s lifespan — decremented by 1 per router, discarded at 0
Diagnostic ladder	The procedure of asking in order: router → outside (8.8.8.8) → name (DNS) → port (TCP)

Today’s Commands

Command	What it does
`ping -n 4 address`	Send 4 ICMP echoes, check replies, time, TTL (Linux: `ping -c 4`)
`Test-NetConnection address -Port 443`	TCP handshake test — a question from a different layer than ping
`nslookup name`	Check name → address conversion (Step 33 review)

The Instinct That Matters More Than Commands

Today’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. Click the checkbox in the sidebar to save your progress.