What's the role of sequence numbers and ACK numbers in TCP, and how do they relate to each other?
Sequence numbers count bytes the sender has sent. ACK numbers count bytes the sender has received +1. Together they tell each side exactly what the other has and hasn't seen.
The relationship:
A's Seq = the next byte A is sending
B's Ack = the next byte B expects from A (= A's Seq + length acknowledged)
Concrete example:
A sends 100 bytes, starting at Seq=1000
Packet: Seq=1000, Len=100 → bytes 1000-1099
B receives all 100 bytes, replies:
Packet: Ack=1100 ← "I got everything up to 1099, send me 1100 next"
Why both directions need this:
TCP is full-duplex — both sides send data simultaneously. Each side maintains its own sequence numbering. So a single packet typically carries:
Seq= where my outgoing data isAck= how much of yours I've received
What if a packet is lost?
A sends bytes 1000-1099 (lost) and 1100-1199 (delivered)
B replies: Ack=1000 ← "I expect 1000, I haven't gotten it yet"
A retransmits 1000-1099
This is the foundation of TCP's reliability.
Why initial sequence numbers are random:
If A always started at Seq=0, an attacker could inject crafted packets into a session. RFC 6528 mandates ISN randomization to prevent TCP sequence prediction attacks.
Tip: In Wireshark's display, "Relative Sequence Numbers" is enabled by default — it shows Seq=1 instead of Seq=3,857,621,432. Disable this in TCP preferences if you want raw values.
Go deeper:
TCP — reliable transmission (Wikipedia) — how seq counts bytes sent and ack signals the next byte expected.- RFC 9293 — TCP — the current authoritative definition of sequence/ack bookkeeping.