TCP Sequence & Acknowledgement Numbers
The counters that make delivery reliable and in-order
How does TCP actually guarantee that every byte arrives, exactly once, in order? With two running counters: the sequence number and the acknowledgement number. Master these and TCP’s reliability stops being mysterious.
Two counters
Every TCP segment carries a sequence number (SEQ) and an acknowledgement number (ACK). Together they let both sides track exactly which bytes have been sent and which have been safely received.
Where the numbers start (ISN)
Numbers do not start at 0. During the handshake each side picks a random Initial Sequence Number (ISN). Randomizing the start makes it much harder for an attacker to guess sequence numbers and hijack the connection.
SEQ counts bytes, not packets
A subtle but important point: the sequence number counts bytes, not segments. If a segment carries bytes 1–50 it has SEQ=1; the next segment (bytes 51–100) has SEQ=51. So the SEQ is simply the number of the first byte in that segment.
ACK = next byte expected
The acknowledgement number is the number of the next byte the receiver expects. If the server has received bytes 1–50, it replies with ACK=51, which effectively says "I have everything up to byte 50 — send me byte 51 next."
Numbers in the handshake
You can watch this in the handshake itself. The SYN uses SEQ=x. The SYN-ACK replies with SEQ=y and ACK=x+1 (the SYN consumes one number). The final ACK carries SEQ=x+1 and ACK=y+1. From here, data continues the count.
Lost segment → retransmit
Reliability falls out naturally. If a segment is lost, no ACK for it comes back. After a timeout (or on duplicate ACKs), the sender retransmits that exact segment. Because ACKs name the next expected byte, the sender knows precisely what to resend.
Cumulative acknowledgement
ACKs are cumulative: a single ACK=151 confirms every byte up to 150 at once, not just one segment. This keeps overhead low — the receiver does not need to acknowledge each segment individually.