Sequence Numbers and Acknowledgements

TCP gives every byte it sends a number, the sequence number, and the receiver replies with an acknowledgement number: the number of the next byte it expects. Because the acknowledgement always names the first missing byte, the sender can tell exactly what has arrived and what has not, which is the base of everything else TCP does.

Each segment's header carries the sequence number of its first byte. A segment with sequence number 1001 that carries 100 bytes holds bytes 1001 to 1100, so the next segment starts at 1101. When those 100 bytes arrive, the receiver acknowledges 1101: everything before it is here, and 1101 is what it wants next.

Two properties follow from the design.

Acknowledgements are cumulative. An acknowledgement of 1301 says every byte before 1301 has arrived, not only the last segment. A lost acknowledgement therefore costs nothing, because the next one covers it.

Loss becomes visible. If segment 2 is lost and segment 3 arrives, the receiver still has nothing after byte 1100 that it can deliver in order, so it acknowledges 1101 again. A repeated acknowledgement tells the sender a gap exists, and where.

Sequence numbers do not start at zero. Each side picks a random starting number for each connection, the initial sequence number, so a stray segment from an old connection, or one forged by an attacker, is unlikely to fit. The examples here use small round numbers to keep the arithmetic easy to follow.

The number is 32 bits, so it wraps round after about 4 GB and starts again; a fast connection handles that with a timestamp option.

So when you read a packet capture, the acknowledgement number answers one question directly: up to which byte has the other side received everything.