Difficulty: Advanced
How does TCP guarantee reliable, in-order delivery over an unreliable network? Explain sequence numbers, ACKs, timeouts, fast retransmit and SACK.
IP underneath TCP can drop, duplicate, delay and reorder packets. TCP builds a reliable byte stream on top of that mess using a handful of ideas that all work together. Picture sending a 10 page document by numbering each page and asking the receiver to tell you what number to send next: if page 4 goes missing, the receiver keeps saying I still need page 4 until you resend it.
Sequence numbers are the foundation. TCP numbers every byte in the stream, and each segment's sequence number is the number of its first byte. The receiver uses these to put data in order, discard duplicates, and detect gaps. Acknowledgements are cumulative: an ACK number of 1001 means I have received every byte up to 1000 and I expect byte 1001 next. That means one ACK can confirm many segments, and a lost ACK is often covered by the next one.
Retransmission on timeout is the safety net. For each unacknowledged segment TCP runs a retransmission timer, the RTO. If no ACK arrives before it expires, the segment is resent. Setting the RTO is delicate: too low causes spurious retransmissions, too high causes long stalls. TCP measures the round-trip time continuously and keeps a smoothed estimate SRTT and a variance RTTVAR, with RTO roughly equal to SRTT plus 4 times RTTVAR (RFC 6298), and a minimum of about 200 ms on Linux. After a timeout the RTO doubles, called exponential backoff, to avoid making congestion worse. Karn's algorithm says do not use RTT samples from retransmitted segments, because you cannot tell which transmission the ACK refers to.
Waiting for a timeout is slow, so TCP has fast retransmit. If a segment is lost but later ones arrive, the receiver sends a duplicate ACK for the same sequence number each time an out-of-order segment arrives. When the sender sees three duplicate ACKs it concludes that the segment was lost, and retransmits immediately without waiting for the RTO. This is one of the most important interview details: 3 duplicate ACKs trigger fast retransmit.
Plain cumulative ACKs have a weakness: if segments 5 and 7 are lost from a window of ten, the sender does not know which later segments were received, and may resend too much. Selective acknowledgement, SACK (negotiated as a TCP option in the handshake), lets the receiver say I have bytes 6000 to 6999 and 8000 to 9999, so the sender fills only the actual holes. Related refinements are delayed ACKs (the receiver waits up to about 40 ms to combine acknowledgements), and the checksum, which detects corrupted segments so they are simply dropped and recovered by retransmission.
Together this is what the sliding window uses: the sender can have many unacknowledged segments in flight, limited by the window, and reliability is maintained without waiting for each ACK individually. Edge cases to know: if the receiver gets out-of-order data it buffers it and reassembles once the gap fills; duplicate segments are discarded using the sequence number; and TCP gives reliability only between the two endpoints, so it cannot protect against an application crash, which is why applications still need their own acknowledgements, for example a message queue confirming that the message was processed, not merely received. The complementary mechanisms, flow control and congestion control, are covered next.
Sender sends: seg1(1-1000) seg2(1001-2000) seg3(2001-3000) seg4 seg5 seg6
seg2 is lost.
Receiver ACKs: ack=1001 (after seg1)
ack=1001 (dup 1, got seg3)
ack=1001 (dup 2, got seg4)
ack=1001 (dup 3, got seg5)
Sender: 3 duplicate ACKs -> retransmit seg2 immediately
Receiver: got seg2 -> ack=6001 (cumulative)Without fast retransmit the sender would wait for the full RTO, often hundreds of milliseconds.
Sequence Numbers, Acknowledgements, Retransmission, RTO, Fast Retransmit