TCP

TCP turns an unreliable network that can lose, duplicate and reorder packets into a reliable, ordered stream of bytes — using sequence numbers, acknowledgements and retransmission.

Send "Hello world!" reliably

Client
Server

Server receive buffer

????

The app only receives bytes in order — a gap holds everything after it back.

IP delivers packets on a best-effort basis: they can be lost, duplicated or reordered. TCP builds a reliable, ordered byte stream on top.

Step 1 / 14
Segments sent
0
Retransmits
0

What's happening?

  1. The three-way handshake (SYN, SYN-ACK, ACK) agrees each side's starting sequence number.
  2. Every byte has a number; the receiver acknowledges the next byte it is waiting for.
  3. A lost segment shows up as repeated (duplicate) ACKs or a timeout, and the sender resends it; the app only ever sees bytes in order.

Where you'll meet it

HTTP/1 and HTTP/2, SSH, database connections and email all run on TCP. Video calls and games often prefer UDP, where late data is useless anyway.

Common mistake

Assuming a sent message has arrived. TCP guarantees order and retries, but the connection can still break — apps need timeouts and idempotent retries.

FAQ

Why random starting sequence numbers?

So packets from an old connection can't be mistaken for this one, and so attackers can't guess them.

What is a duplicate ACK?

The receiver repeating "I'm still waiting for byte N" because later bytes arrived first — a sign that N was lost.

TCP vs UDP?

TCP is reliable and ordered but adds round trips; UDP just sends packets, with no guarantees and no waiting.