Intuition The 30-second pictureThe internet (IP) is a lossy, reordering, duplicating postman. TCP's job is to turn that
unreliable byte-carrier into a reliable, in-order byte stream . It does this with three ideas:
Number every byte so both sides agree on what is what (sequence numbers ).Acknowledge what arrived so the sender knows what got through (ACK numbers ).Resend whatever wasn't acknowledged in time (retransmission ).
The clever trick is that ACKs are cumulative : "I have everything up to byte N" — one small
number summarizes the whole received prefix.
Definition The problem TCP solvesIP delivers packets that may be lost , reordered , delayed , or duplicated .
The application wants a reliable, ordered stream of bytes . TCP is the layer that bridges
this gap using sequence/ack numbers + timers + retransmission.
WHAT is "reliability" here precisely? Two guarantees:
No loss : every byte the app writes eventually reaches the other app (or the connection breaks).In order : bytes are delivered to the receiving app in the exact order they were sent.
bytes , not packets?
If you numbered packets, retransmitting with a different size would be ambiguous. By numbering
the byte stream itself, every byte has one permanent identity. A segment just says "I carry
bytes [seq, seq+len)". Resends, splits, and merges all stay consistent.
Definition Sequence number (SEQ)The SEQ field of a segment = the stream position of its first data byte .
A segment carrying L L L [ SEQ , SEQ + L ) . [\text{SEQ},\ \text{SEQ}+L). [ SEQ , SEQ + L ) . SEQ + L \text{SEQ}+L SEQ + L
Definition Initial Sequence Number (ISN)Numbering does not start at 0. Each side picks a random ISN during the handshake.
WHY random? To prevent an old, delayed segment from a previous connection (same IP/port pair)
being mistaken for valid new data — and to make sequence guessing/injection attacks harder.
Also the SYN and FIN flags each consume one sequence number (they're treated as 1 phantom byte),
which is why an ACK to a SYN with ISN x x x x + 1 x+1 x + 1
Intuition One number = "everything before this is safe"Instead of listing every received byte, the receiver sends the next byte it expects .
If it ACKs N N N all bytes < N < N < N one ACK can cover many segments , and a lost ACK is automatically
repaired by the next ACK (which carries an even bigger number).
Definition Cumulative ACKACK = ( highest contiguous byte received ) + 1 \text{ACK} = (\text{highest contiguous byte received}) + 1 ACK = ( highest contiguous byte received ) + 1 next byte expected . It acknowledges cumulatively — i.e.
the entire prefix below it. It says nothing about bytes received after a gap.
Worked example Walking the numbers (Why each step?)Sender sends 3 segments, each 100 bytes, starting at SEQ = 1000.
Segment
SEQ
bytes covered
After it arrives in order, receiver ACKs
A
1000
[1000,1100)
1100 — Why? last contiguous byte is 1099, next expected = 1100
B
1100
[1100,1200)
1200 — Why? now contiguous up to 1199
C
1200
[1200,1300)
1300 — Why? contiguous up to 1299
Now break it: suppose B is lost , but A and C arrive.
A arrives → ACK 1100 (Why? contiguous to 1099).
C arrives but there's a gap (1100–1199 missing). Receiver buffers C but cannot advance.
It re-sends ACK 1100 again (a duplicate ACK ) — Why? The highest contiguous byte is
still 1099, so the next expected byte is still 1100, regardless of C sitting in the buffer.
There are two complementary mechanisms.
Intuition "If nobody acknowledged it in time, assume it's gone."The sender starts a timer when it sends data. If the ACK covering that data doesn't arrive before
the Retransmission Timeout (RTO) expires, the sender resends the oldest unacknowledged segment.
Definition Estimating RTO (Jacobson/Karels — derived idea)We must guess the round-trip time (RTT) and add safety margin.
Using exponentially-weighted moving averages with each new sample R R R SRTT ← ( 1 − α ) SRTT + α R \text{SRTT} \leftarrow (1-\alpha)\,\text{SRTT} + \alpha R SRTT ← ( 1 − α ) SRTT + α R RTTVAR ← ( 1 − β ) RTTVAR + β ∣ SRTT − R ∣ \text{RTTVAR} \leftarrow (1-\beta)\,\text{RTTVAR} + \beta\,|\text{SRTT}-R| RTTVAR ← ( 1 − β ) RTTVAR + β ∣ SRTT − R ∣ RTO = SRTT + 4 ⋅ RTTVAR \text{RTO} = \text{SRTT} + 4\cdot\text{RTTVAR} RTO = SRTT + 4 ⋅ RTTVAR α = 1 / 8 , β = 1 / 4 \alpha=1/8,\ \beta=1/4 α = 1/8 , β = 1/4 WHY a moving average? Network RTT varies; a single sample is noisy. SRTT smooths it.
WHY add 4·RTTVAR? If RTT is jittery, we wait longer before declaring loss, to avoid
false retransmissions. On each timeout RTO is doubled (exponential backoff) to avoid
hammering a congested network.
Intuition Don't always wait for the (slow) timer.Duplicate ACKs are a hint that a later segment arrived but an earlier one is missing.
3 duplicate ACKs (i.e. 4 identical ACKs total) strongly suggest loss — not mere reordering —
so the sender resends immediately, without waiting for RTO.
Definition Fast retransmitOn receiving the 3rd duplicate ACK for value N N N N N N
Intuition Strength and weakness in one sentenceCumulative ACKs are robust (a lost ACK is healed by the next one) and compact (one number),
but they are imprecise : they can't say "I got C and D but not B." That single missing segment
can force resending or stall progress — which is exactly why Selective ACK (SACK) was added
as an option to report received-but-non-contiguous ranges.
Recall Feynman: explain it to a 12-year-oldImagine mailing a long letter one numbered page at a time. Your friend doesn't email back
"got page 5, got page 7." Instead they say "I have everything up to page 4, send page 5 next."
If a page gets lost in the mail, they keep saying "still need page 5!" After hearing that a few
times, you just re-mail page 5 — and once it lands, your friend suddenly has pages 5, 6, AND 7
(they were keeping the extra pages on their desk), so they say "now I have up to page 7!"
That "everything up to page X" message is the cumulative ACK , and re-mailing the lost page is
retransmission .
"SEQ says where I START, ACK says what I WANT NEXT."
And: C umulative ACK = C ount the contiguous prefix, report the C oming byte.
Common mistake "The ACK number equals the last byte received."Why it feels right: "acknowledge" sounds like "confirm the last thing I got."
The fix: ACK is the next byte expected = last contiguous byte + 1 . If you ACK the
last byte received instead of +1, the sender would resend that byte forever. Always remember the +1
(and the SYN/FIN +1 too).
Common mistake "A duplicate ACK means the receiver lost data."Why it feels right: repeated identical messages look like a problem report.
The fix: A dup ACK actually means data arrived out of order (so the receiver advanced past
the hole and is re-announcing what it's still missing). It signals a gap , and the data that
caused the dup ACK was successfully received and buffered.
Common mistake "Cumulative ACK 1400 means segments B, C, D each got their own ACK."Why it feels right: TCP looks request/response-like.
The fix: One ACK (1400) cumulatively covers all bytes below 1400 at once. TCP also delays/
coalesces ACKs deliberately. Counting ACKs ≠ counting segments.
Common mistake "On 3 dup ACKs you must wait for the timeout to resend."Why it feels right: RTO is "the" retransmission mechanism in textbooks.
The fix: That's the whole point of fast retransmit — resend on the 3rd dup ACK immediately ,
long before RTO would fire, saving roughly one RTT or more.
What does the TCP sequence number of a segment represent? The stream position of the segment's first data byte; it covers
[ SEQ , SEQ + L ) [\text{SEQ}, \text{SEQ}+L) [ SEQ , SEQ + L ) .
How is the cumulative ACK number computed? ACK = (highest contiguous byte received) + 1 = the next byte expected.
Why does TCP number bytes instead of packets? So every byte has a permanent identity; resends/splits/merges stay unambiguous even if segment sizes change.
Why is the Initial Sequence Number random, not 0? To avoid confusing old delayed segments from a previous connection, and to resist sequence-injection attacks.
What does a duplicate ACK indicate? A later segment arrived out of order while an earlier one is still missing — i.e. there is a gap; the named segment was buffered, not lost.
After how many duplicate ACKs does fast retransmit trigger, and what is resent? After 3 duplicate ACKs; the sender resends the segment starting at the ACK number (the missing one).
Give the RTO formula and its terms. RTO = SRTT + 4·RTTVAR, where SRTT is smoothed RTT and RTTVAR is RTT variation (mean deviation).
Why does cumulative ACK make a lost ACK self-healing? A later ACK carries a larger number that already covers everything the lost ACK would have, so the lost ACK is irrelevant.
Why does one ACK sometimes jump forward by many bytes? Filling a single hole connects all the out-of-order data already buffered, so the contiguous prefix (and thus the ACK) leaps ahead.
What limitation of cumulative ACK does SACK fix? Cumulative ACK can't report received-but-non-contiguous ranges; SACK lets the receiver report exactly which extra blocks it has.
What happens to RTO on repeated timeouts? It is doubled each time (exponential backoff) to avoid overloading a congested network.
Do SYN and FIN flags consume sequence numbers? Yes, each consumes one sequence number, so an ACK to a SYN with ISN x is x+1.
TCP three-way handshake — where ISNs are exchanged and SYN consumes a seq number.Sliding window flow control — the window bounds how many unacked bytes may be outstanding.TCP congestion control — fast retransmit pairs with fast recovery; dup ACKs drive cwnd logic.Selective ACK (SACK) — fixes cumulative ACK's inability to report gaps precisely.Go-Back-N vs Selective Repeat — TCP is a hybrid leaning toward selective repeat with SACK.IP unreliable datagram service — the lossy substrate TCP compensates for.RTT estimation / Jacobson's algorithm — the math behind the RTO timer.
equals highest contiguous plus 1
Reliable in-order byte stream
Intuition Hinglish mein samjhoDekho, internet ka IP layer ek lapervah postman jaisa hai — packets kho sakte hain, aage-peeche
(out of order) aa sakte hain, ya duplicate ban sakte hain. App ko chahiye ek reliable, in-order
byte stream . TCP yahi gap bharta hai teen ideas se: har byte ko number do (sequence number),
jo mila uska acknowledgement bhejo (ACK number), aur jo time pe acknowledge nahi hua use
dobara bhejo (retransmission).
Sabse important cheez hai cumulative ACK . Receiver yeh nahi batata ki "ye-ye segment mile";
balki bolta hai "mere paas byte X tak sab kuch contiguous mil gaya, ab X agla byte bhejo ". Yaani
ACK = sabse last contiguous byte + 1. Isका faayda — agar ek ACT kho bhi jaaye, koi baat nahi, agla
ACK bada number lekar aata hai jo purane ko bhi cover kar leta hai. Self-healing!
Ab maan lo beech ka ek segment (SEQ=1100) kho gaya, par uske aage wale aa gaye. Receiver gap dekh
ke baar-baar wahi purana ACK=1100 bhejta hai — inhe duplicate ACK kehte hain. Yeh galti nahi
hai; iska matlab data out-of-order aaya hai aur ek hole hai. Jab sender ko 3 duplicate ACK
mil jaate hain, woh timer ka wait kiye bina turant woh missing segment dobara bhej deta hai — isko
fast retransmit kehte hain. Hole bharte hi receiver ka ACK ek dum se aage chhalang maar deta
hai (1100 se seedha 1500), kyunki buffer me pade saare segments ab connect ho gaye.
Yeh kyun matter karta hai? Kyunki har reliable cheez jo tum online karte ho — file download, web
page, video buffering — TCP ke isi seq/ack + retransmission machinery pe chalti hai. Bina iske
internet bharosemand hi nahi ban paata. Yaad rakho: SEQ = main kahan se start kar raha hoon,
ACK = mujhe ab kaunsa byte chahiye.
