Sending it fast: UDP
TCP checks each piece was received, and resends what didn't come. That makes it accurate, but it also waits. Yet in a moment like a video call, where a tenth of a second matters, it's better to be fast even if a piece or two drops. That is when we use UDP.
Skip the check
Recall TCP from last lesson.
Each time a piece arrived,
an acknowledgment (ACK) went back and forth.
That one word makes it accurate,
but each exchange costs time.
UDP flips the idea.
Never mind the check, just be fast.
Without asking whether it arrived,
it just fires the pieces off in a row.
Tap send to fire pieces off in a row. Unlike TCP, it doesn't wait for an ACK.
With no waiting for a check,
the pieces leave nonstop.
In the same time, far more,
and far faster, can be sent.
But one thing was given up.
UDP does not care
about which pieces arrived.
So what happens
if a piece drops on the way?
A few drop, keep going
TCP would have asked
for the dropped piece again.
UDP does not.
Even if one piece drops on the road,
it does not stop; it just moves on.
What's lost is left lost.
It may look careless,
but sometimes stopping everything
to patch one or two losses costs more.
Tap send. Some pieces drop on the way, but UDP keeps going to the end with no resend.
Even with a few pieces dropped,
the send finished without a break.
The receiver got a few gaps,
but the flow never once stopped.
This is exactly UDP's character.
Not stopping, over being perfect.
But if something is missing,
is that really okay?
Looking at where it's used gives the answer.
When to use it
Where UDP fits
is things that must not be late.
Think of an online game.
A position update that's a beat late
is old news even if you get it again.
Video calls and live broadcasts are the same.
This very moment matters,
so receiving again a single piece
that dropped a moment ago is pointless.
Tap to switch examples. Games, video calls, and live broadcasts all must not be late, so UDP fits.
All three share one thing.
Being late is more fatal
than losing a little.
In a game, a frozen screen,
or a voice that cuts and lags,
is the more frustrating thing.
UDP avoids that frustration.
A little rough, but never stopping,
it chooses to keep the now flowing.
TCP versus UDP
It's not that one is better.
Their goals just differ.
TCP puts accuracy first.
Check, resend, line up.
For that, it waits a little more.
UDP puts speed first.
Fire without a check, leave the losses.
For that, it can be rough.
What matters more decides the choice.
Tap the two modes to compare. TCP is accurate but waits; UDP is rough but fast.
The comparison makes it clear.
Text or files that must be exact and complete,
leave to TCP.
Games and calls, where this moment
is everything, leave to UDP.
The internet has both
because the world holds
two kinds of urgency.
You just pick the right tool.
Let's wrap up
Gathered on one line, it's this.
UDP skips the acknowledgment (ACK)
and fires pieces off fast in a row.
If some drop, it just goes, no resend.
So it fits things that must not be late,
games, video calls, and live broadcasts.
If accuracy comes first, TCP;
if speed comes first, UDP.
Two promises with different goals.
Tap the key points in order to review. (skip the check → fast in a row → a few drop, keep going → for games, calls, broadcasts)
Now you know both TCP and UDP.
If accuracy matters, TCP;
if speed matters, UDP.
The internet picks
the promise that fits the situation.
How to send the pieces is settled.
But the address those pieces head for,
finding just one place
among countless computers, comes next.