TCP builds a ministry.

UDP brings a cannon.

TCP says:

“Let us establish state, negotiate sequence numbers, acknowledge bytes, retransmit loss, manage congestion, close carefully, and leave behind a respectful graveyard of TIME_WAIT sockets.”

UDP says:

“Here is a datagram. Good luck.”

This is not stupidity.

This is ideology.

I. What UDP Actually Is

UDP is the User Datagram Protocol, specified in RFC 768 in August 1980.

It is small enough to explain without a committee hostage crisis.

UDP adds four fields above IP:

0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|     Source Port | Destination Port |
+--------+--------+--------+--------+
|        Length   |      Checksum    |
+--------+--------+--------+--------+
|              data ...              |
+------------------------------------+

That is the whole palace.

No sequence number. No acknowledgment number. No connection state. No retransmission timer. No ordered byte stream.

Just:

• source port
• destination port
• length
• checksum
• payload

UDP is not unreliable because it is broken.

UDP is unreliable because it declines the position.

II. Datagram Means Datagram

UDP preserves message boundaries.

If an application sends one UDP datagram, the receiver gets one datagram or gets nothing.

This is different from TCP’s byte stream.

UDP send:
  "GLORY"
  "TO"
  "PACKETS"

UDP receive may be:
  "GLORY"
  "TO"
  "PACKETS"

or:
  "GLORY"
  "PACKETS"

or:
  nothing useful because the network is a weather event

UDP will not split your stream because there is no stream.

UDP will not reassemble lost intent because it does not care about intent.

The datagram is the unit of politics.

III. Why Use UDP At All

The civilian asks:

“Why use a protocol that does not guarantee delivery?”

Because not every application wants TCP’s ministry.

Some traffic values latency, simplicity, or application-controlled recovery more than generic reliable ordering.

Use case	Why UDP fits
DNS	small queries, fast retry, low ceremony
NTP	tiny time exchanges, simple request/response
VoIP	late audio is worse than missing audio
games	fresh state matters more than old state arriving perfectly
telemetry	occasional loss may be acceptable
QUIC / HTTP/3	transport logic moves into userland over UDP

If a game packet says “player was here 200 milliseconds ago,” perfect late delivery is not victory.

It is archaeology.

The game wants the current state, not a museum exhibit.

IV. UDP Does Not Mean No Responsibility

A common peasant error:

“UDP has no congestion control, therefore I may blast packets until the router confesses.”

Incorrect.

UDP itself does not provide congestion control. Applications using UDP still have a responsibility not to destroy the network.

This is why modern protocols built on UDP, such as QUIC, implement their own reliability and congestion behavior above UDP.

IP
  |
UDP
  |
QUIC
  |
HTTP/3

UDP is the carrier. QUIC is the bureaucracy smuggled inside the envelope.

Google looked at TCP in the kernel, looked at middleboxes, looked at deployment timelines, and said:

“What if the transport protocol escaped into userland wearing a UDP costume?”

This is not an insult. This is a successful prison break.

V. DNS: The Classic UDP Citizen

DNS traditionally uses UDP port 53 for many queries.

The logic is straightforward:

• query is small
• response is often small
• retry is cheap
• no long-lived connection is needed

client -> UDP/53: "What is kimjongrails.com?"
server -> UDP/ephemeral: "Here is the answer, if the gods permit."

Modern DNS is more complicated because DNSSEC, large responses, TCP fallback, DNS over TLS, DNS over HTTPS, and DNS over QUIC all entered the room carrying clipboards.

But the old design explains UDP perfectly:

ask a small question, receive a small answer, retry if the packet was eaten by the border dogs.

VI. NTP: Time By Small Cannon

NTP commonly uses UDP port 123.

This is also appropriate.

Time synchronization does not need a long reliable stream to say:

“Here is the time, adjusted through a suspicious amount of math.”

If a packet is lost, the client asks again.

The Republic approves.

Do not build a cathedral when a timestamp will do.

VII. UDP And Firewalls

TCP gives firewalls connection state to inspect:

• SYN
• established
• FIN
• RST

UDP gives firewalls a shrug.

There is no connection.

Stateful firewalls therefore invent temporary state from observed traffic:

internal host sends UDP packet out
firewall records tuple for short timeout
external response matching tuple is allowed back
timer expires
state disappears

This works.

It is also why UDP timeouts matter and why long-idle UDP-based applications sometimes fail in strange ways.

The firewall is not tracking a connection.

It is remembering a rumor.

VIII. UDP Amplification: The Loudspeaker Problem

UDP’s lack of handshake creates a security problem.

If a service replies with a large response to a small request, and if source addresses can be spoofed, an attacker can send forged requests that make reflectors blast traffic at a victim.

attacker spoofs victim IP
  |
  v
open UDP service receives request
  |
  v
service sends large reply to victim

This is reflection and amplification.

The technical moral:

• do not run open amplifiers
• implement source-address validation
• rate-limit exposed UDP services
• design protocols so small forged requests do not trigger huge replies

The political moral:

never give anonymous strangers access to a loudspeaker connected to artillery.

IX. UDP-Lite, SCTP, And Other Roads Not Taken

UDP is not the only alternative to TCP.

There are other transport ideas:

Protocol	Idea	Why it matters
UDP	minimal datagrams	simple, everywhere
UDP-Lite	partial checksum coverage	useful for error-tolerant media in theory
SCTP	message-oriented, multi-streaming, multi-homing	technically interesting, deployment-hostile
QUIC	modern transport over UDP	deployable through existing UDP paths

The lesson is brutal:

technical elegance does not guarantee deployment.

UDP survived because it was simple and already everywhere.

QUIC succeeded partly because it did not ask the entire Internet to recognize a new IP protocol number.

It hid inside UDP like a dissident in a grain truck.

X. The Real Story (Suppressed)

Officially, UDP means User Datagram Protocol.

Unofficially, early Pyongyang notes give the expansion as:

Unapologetic Delivery Politics.

The protocol designers looked at TCP’s state machine and said:

“Not every message needs a wedding ceremony.”

So they created UDP:

• no handshake
• no goodbye
• no promises
• no therapy

Just a datagram and the cold dignity of consequences.

In the original suppressed draft, the API returned only two statuses:

SENT
NOT MY PROBLEM

Western committees removed this for morale reasons.

XI. The Lesson

UDP is not the inferior TCP.

UDP is the transport protocol for applications that want to make their own bargain with the network.

Sometimes that bargain is wise:

• real-time media
• gaming
• DNS
• NTP
• application-specific reliability
• QUIC’s userland transport model

Sometimes it is foolish:

• custom protocols with no congestion control
• exposed amplifiers
• telemetry floods
• “reliable UDP” projects that rediscover TCP badly

The decree is simple:

Use TCP when ordered reliable bytes are the right abstraction.

Use UDP when datagrams, latency, or application-controlled recovery matter.

Do not use UDP because you think reliability is for cowards.

Use UDP because you are prepared to govern the consequences yourself.

— Kim Jong Rails, Supreme Leader of the Republic of Derails