Sending it reliably: TCP

Complete, and exact

As we saw last lesson,
data becomes small pieces, packets,
and each crosses by its own route.
But the route is not perfect.
One piece may drop on the way,
a later piece may arrive first.
Still, the receiver must get it
with nothing missing and in order.
The promise that handles this is TCP.

Tap the two things TCP promises. Nothing missing, and in order.

The goal is clear now.
Complete, and in order.
Simple to say,
but not easy when the route is imperfect.
TCP solves it with
three small habits.
Tell the sender it arrived,
resend what did not arrive,
put things in order by their number.
Let's follow them one by one.

Say it arrived

The first habit is acknowledging.
Every time a piece arrives, the receiver
replies briefly, "got it."
This reply is called an acknowledgment, ACK.
It is just like tapping "received"
when a parcel is delivered.
The sender only knows a piece arrived safely
once its ACK comes back.
No ACK, and the sender still does not know.

Tap an arrived packet to send back a 'got it' (ACK). When the ACK returns, the sender is at ease.

With an ACK for each piece,
the sender learns what got through.
One more message goes back and forth,
so it can look a bit slower.
But thanks to this one word
you can pinpoint the missing piece.
So what about a piece
whose ACK never came?
The answer is simple. Send it again.

No reply, send again

The second habit is retransmission.
If the sender waits a good while
and some piece's ACK never comes,
it thinks, "ah, that one dropped on the way,"
and sends that same piece again.
The receiver gets the resent piece
and this time returns an ACK.
Filling the missing piece this way,
in the end nothing is left out.

Tap a piece whose ACK never returned to resend it. When the resent piece arrives, the gap is filled.

Thanks to retransmission,
no piece is missing anymore.
Now in the receiver's hands
all the pieces have gathered.
But one thing remains.
The pieces crossed by separate routes,
so the order they arrived in is jumbled.
Sometimes piece 5 is here before piece 2.
So how do we set this order straight?

Order them by number

The third habit is reordering.
TCP sends each piece with a number.
Number 1, number 2, number 3.
The arrival order can be scrambled, that is fine.
The receiver looks at the numbers
and lines them up from the smallest.
Even if 5 arrives first,
it keeps 2's spot open and waits.
Once every number is filled in order,
the original message comes back exactly.

Tap the jumbled pieces in number order (1, 2, 3, 4) to line them up. Get them all and the original message returns.

Lined up by number,
the jumbled pieces
snapped back into the original message.
The missing ones were re-received and filled,
the order was fixed by number.
To the person receiving,
it looks as if no packet was ever lost or swapped.
All that trouble
TCP quietly did in the background.

Let's wrap up

Gathered on one line, it's this.
Packets can get lost or arrive out of order.
TCP sends an ACK when one arrives,
resends what does not come (retransmit),
and orders pieces by their number.
So the receiver always gets it
complete and in order.
Reliability over raw speed, that is TCP's promise.

Tap the key points in order to review. (loss/jumble → ACK on arrival → resend if none → order by number)

For safety, TCP
acknowledges, resends, and lines things up.
That means waiting a little more.
But sometimes that wait is not worth it.
For a voice call or a game,
where being fast beats being perfect,
we use a different way.
Next lesson, let's meet a way
that skips the acknowledgments and just sends fast.