TCP Sequence Numbers, ACKs & Retransmission (RTO)

▶

Steps

setup

Client sends SYN to initiate connection

The client sends a SYN packet to the server to start the TCP three-way handshake. This packet has an initial sequence number (seq=1000).

💡 This step establishes the start of a TCP connection and sets the initial sequence number for tracking data.

Line:

send_packet(src='client', dst='server', seq=1000, flags=['SYN'])

💡 TCP connections begin with a SYN packet to synchronize sequence numbers.

setup

Server receives SYN and replies with SYN-ACK

The server receives the SYN, processes it, and replies with a SYN-ACK packet. The server's sequence number is 3000, and it acknowledges the client's SYN by setting ACK=1001.

💡 The server acknowledges the client's SYN and sends its own SYN to synchronize sequence numbers both ways.

Line:

send_packet(src='server', dst='client', seq=3000, ack=1001, flags=['SYN','ACK'])

💡 TCP handshake requires both sides to synchronize sequence numbers with SYN and ACK flags.

setup

Client receives SYN-ACK and sends ACK

The client receives the SYN-ACK, processes it, and sends an ACK packet back to the server. The ACK acknowledges the server's SYN by setting ACK=3001.

💡 This finalizes the three-way handshake, confirming both sides have synchronized sequence numbers.

Line:

send_packet(src='client', dst='server', seq=1001, ack=3001, flags=['ACK'])

💡 The handshake completes when the client acknowledges the server's SYN.

fill_cells

Client sends first data packet (seq=1001)

The client sends the first data packet with sequence number 1001 and payload 'Hello'.

💡 Data transfer begins after connection setup, with sequence numbers tracking bytes sent.

Line:

send_packet(src='client', dst='server', seq=1001, ack=3001, flags=[], data='Hello')

💡 Sequence numbers track the byte offset of data sent for reliable delivery.

compare

Server receives data and sends ACK (ack=1006)

The server receives the data packet with seq=1001 and payload 'Hello' (5 bytes). It sends an ACK with ack=1006, indicating it expects the next byte at 1006.

💡 ACK numbers confirm receipt of data and indicate the next expected byte.

Line:

send_packet(src='server', dst='client', seq=3001, ack=1006, flags=['ACK'])

💡 ACK numbers advance by the length of received data to confirm delivery.

fill_cells

Client sends second data packet (seq=1006)

The client sends the second data packet with sequence number 1006 and payload 'World'.

💡 Data continues flowing with sequence numbers incremented by previous data length.

Line:

send_packet(src='client', dst='server', seq=1006, ack=3001, flags=[], data='World')

💡 Sequence numbers ensure data ordering and tracking of bytes sent.

prune

Second data packet lost in transit (no ACK received)

The second data packet is lost and does not reach the server. The client waits for an acknowledgment but none arrives before the retransmission timeout (RTO).

💡 Packet loss triggers retransmission mechanisms in TCP to ensure reliability.

Line:

# Packet lost, no ACK received; wait for RTO

💡 TCP detects lost packets by missing ACKs and uses timers to trigger retransmission.

retransmit

Retransmission timeout (RTO) triggers resend of lost packet

The client's retransmission timer expires (RTO). It resends the lost data packet with seq=1006 and payload 'World'.

💡 Retransmission ensures lost data is resent to maintain reliable delivery.

Line:

send_packet(src='client', dst='server', seq=1006, ack=3001, flags=['RTO'], data='World')

💡 TCP uses timers to detect lost packets and trigger retransmission automatically.

compare

Server receives retransmitted packet and sends ACK (ack=1011)

The server receives the retransmitted packet with seq=1006 and payload 'World'. It sends an ACK with ack=1011, confirming receipt of all data up to byte 1010.

💡 ACK confirms cumulative receipt of data, including retransmitted packets.

Line:

send_packet(src='server', dst='client', seq=3001, ack=1011, flags=['ACK'])

💡 TCP acknowledges the highest contiguous byte received, confirming retransmission success.

traverse

Client receives final ACK confirming all data received

The client receives the ACK with ack=1011, confirming all sent data has been received by the server. The connection is now fully synchronized and data transfer is complete.

💡 Final ACK confirms reliable delivery of all data and allows the client to send more data or close connection.

Line:

# Client processes final ACK

💡 TCP uses ACKs to confirm data delivery and maintain flow control.

def send_packet(src, dst, seq, ack=None, flags=None, data=None):
    # STEP 1-10: Simulate sending TCP packets with sequence and acknowledgment numbers
    packet = {'src': src, 'dst': dst, 'seq': seq, 'ack': ack, 'flags': flags or [], 'data': data}
    # Normally send packet over network
    return packet

# STEP 1
send_packet('client', 'server', seq=1000, flags=['SYN'])

# STEP 2
send_packet('server', 'client', seq=3000, ack=1001, flags=['SYN','ACK'])

# STEP 3
send_packet('client', 'server', seq=1001, ack=3001, flags=['ACK'])

# STEP 4
send_packet('client', 'server', seq=1001, ack=3001, data='Hello')

# STEP 5
send_packet('server', 'client', seq=3001, ack=1006, flags=['ACK'])

# STEP 6
send_packet('client', 'server', seq=1006, ack=3001, data='World')

# STEP 7
# Packet lost: no send_packet call

# STEP 8
send_packet('client', 'server', seq=1006, ack=3001, flags=['RTO'], data='World')

# STEP 9
send_packet('server', 'client', seq=3001, ack=1011, flags=['ACK'])

# STEP 10
# Client receives final ACK (no send_packet call needed)

📊

TCP Sequence Numbers, ACKs & Retransmission (RTO) - Watch the Algorithm Execute, Step by Step

Watching this step-by-step visualization helps you understand how TCP manages sequence numbers and acknowledgments to guarantee data delivery, and how retransmission works when packets are lost or delayed.

Client sends SYN to initiate connection and set initial sequence number

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

🔌 protocolTCP

🚩 flagsSYN

src→10.0.0.1:50000

dst→10.0.0.2:80

flags→SYN

SYN: client→server (seq=1000)

Server replies with SYN-ACK to acknowledge client's SYN and send its own sequence number

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

🔌 protocolTCP

🚩 flagsSYN, ACK

src→10.0.0.2:80

dst→10.0.0.1:50000

flags→SYN, ACK

SYN: client→server (seq=1000)

SYN-ACK: server→client (seq=3000, ack=1001)

Client sends ACK to complete handshake and confirm server's sequence number

Hop: 3

Client

Server

📦Packet

↗ fromclient

↘ toserver

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.1:50000

dst→10.0.0.2:80

flags→ACK

SYN: client→server (seq=1000)

SYN-ACK: server→client (seq=3000, ack=1001)

ACK: client→server (seq=1001, ack=3001)

Client sends first data packet with sequence number 1001

Hop: 4

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadHello

🔌 protocolTCP

🚩 flags

src→10.0.0.1:50000

dst→10.0.0.2:80

data→Hello

SYN-ACK: server→client (seq=3000, ack=1001)

ACK: client→server (seq=1001, ack=3001)

DATA: client→server (seq=1001, data='Hello')

Server acknowledges receipt of 5 bytes, expecting next byte 1006

Hop: 5

Client

Server

📦Packet

↗ fromserver

↘ toclient

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

flags→ACK

ACK: client→server (seq=1001, ack=3001)

DATA: client→server (seq=1001, data='Hello')

ACK: server→client (seq=3001, ack=1006)

Client sends second data packet with sequence number 1006

Hop: 6

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadWorld

🔌 protocolTCP

🚩 flags

src→10.0.0.1:50000

dst→10.0.0.2:80

data→World

DATA: client→server (seq=1001, data='Hello')

ACK: server→client (seq=3001, ack=1006)

DATA: client→server (seq=1006, data='World')

Second data packet lost; client waits for ACK but none arrives

Hop: 7

Client

Server

ACK: server→client (seq=3001, ack=1006)

DATA: client→server (seq=1006, data='World')

Packet lost: DATA seq=1006

Client retransmits lost packet after timeout (RTO)

Hop: 8

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadWorld

🔌 protocolTCP

🚩 flagsRTO

src→10.0.0.1:50000

dst→10.0.0.2:80

data→World

flags→RTO

DATA: client→server (seq=1006, data='World')

Packet lost: DATA seq=1006

RTO Retransmit: client→server (seq=1006, data='World')

Server acknowledges receipt of retransmitted data up to byte 1010

Hop: 9

Client

Server

📦Packet

↗ fromserver

↘ toclient

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.2:80

dst→10.0.0.1:50000

flags→ACK

Packet lost: DATA seq=1006

RTO Retransmit: client→server (seq=1006, data='World')

ACK: server→client (seq=3001, ack=1011)

Client receives final ACK confirming all data received

Hop: 10

Client

Server

📦Packet

↗ fromserver

↘ toclient

🔌 protocolTCP

🚩 flagsACK

src→10.0.0.1:50000

dst→10.0.0.2:80

flags→ACK

RTO Retransmit: client→server (seq=1006, data='World')

ACK: server→client (seq=3001, ack=1011)

ACK received: client confirms all data received

Key Takeaways

✓ TCP uses sequence numbers and ACKs to track data sent and received, ensuring reliable delivery.

This insight is hard to see from code alone because sequence and ACK numbers are abstract counters; visualization shows their flow and updates clearly.

✓ Retransmission timeout (RTO) triggers resending lost packets automatically to recover from packet loss.

Plain English explanation: when an ACK is not received in time, TCP resends the missing data to guarantee delivery.

✓ The three-way handshake synchronizes sequence numbers between client and server before data transfer begins.

Seeing the SYN, SYN-ACK, and ACK packets in sequence clarifies how TCP establishes connection state.

Practice

1. When a link failure occurs in a network running Distance Vector routing, what sequence of events typically happens before all routers have updated their routing tables?

easy

A. Routers immediately flood the network with link state advertisements, then recompute shortest paths

B. Routers notify neighbors of the failure, update their tables, and neighbors propagate updates iteratively until convergence

C. Routers wait for a periodic timer to expire before sending updates, causing immediate global convergence

D. Routers use a centralized controller to recompute routes and push updates to all routers

Solution

1. Step 1: Identify Distance Vector update mechanism

   Distance Vector routers share routing information only with neighbors and rely on iterative updates.

2. Step 2: Trace the failure propagation

   When a link fails, a router detects it and updates its routing table, then sends updates to neighbors. Neighbors update their tables and propagate changes further, iteratively converging.

3. Step 3: Analyze options

   Routers immediately flood the network with link state advertisements, then recompute shortest paths describes Link State behavior, not Distance Vector. Routers wait for a periodic timer to expire before sending updates, causing immediate global convergence is incorrect because updates are sent immediately upon detecting changes, not only on timers, and convergence is not immediate. Routers use a centralized controller to recompute routes and push updates to all routers is incorrect because Distance Vector is decentralized.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   Distance Vector uses neighbor-to-neighbor iterative updates after failure detection.

Hint: Distance Vector updates propagate hop-by-hop, not flooded globally

Common Mistakes:

• Confusing Distance Vector with Link State flooding
• Assuming immediate global updates without iteration
• Thinking Distance Vector uses centralized control

2. Which of the following statements about HTTP 4xx and 5xx status codes is INCORRECT?

medium

A. 4xx status codes indicate client-side errors, meaning the client must modify the request to succeed.

B. 5xx status codes indicate server-side errors, meaning the server failed to fulfill a valid request.

C. A 403 status code means the client is forbidden from accessing the resource, even if authenticated.

D. A 404 status code means the server is temporarily unavailable and the client should retry later.

Solution

1. Step 1: Review meanings of 4xx and 5xx status codes

   4xx = client errors; 5xx = server errors.

2. Step 2: Analyze each statement

   4xx status codes indicate client-side errors, meaning the client must modify the request to succeed. is correct: 4xx means client must fix request.
   5xx status codes indicate server-side errors, meaning the server failed to fulfill a valid request. is correct: 5xx means server failed.
   A 404 status code means the server is temporarily unavailable and the client should retry later. is incorrect: 404 means 'Not Found', not temporary unavailability; 503 indicates temporary server unavailability.
   A 403 status code means the client is forbidden from accessing the resource, even if authenticated. is correct: 403 means forbidden access regardless of authentication.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   404 is about missing resource, not server availability.

Hint: 404 = Not Found, 503 = Service Unavailable

Common Mistakes:

• Confusing 404 with temporary server errors
• Assuming 403 means unauthenticated rather than forbidden
• Mixing client and server error categories

3. Why might using TCP for a real-time multiplayer game cause performance issues compared to UDP?

medium

A. TCP packets are always larger than UDP packets, increasing bandwidth usage

B. TCP does not support packet loss detection, causing inconsistent game state

C. UDP requires establishing a connection first, which delays game startup

D. TCP's retransmission and ordering guarantees introduce latency that can disrupt real-time responsiveness

Solution

1. Step 1: Identify real-time game requirements

   Low latency and timely updates are critical; some packet loss is tolerable.

2. Step 2: Analyze TCP behavior

   TCP ensures reliability and ordered delivery by retransmitting lost packets, which adds latency.

3. Step 3: Analyze UDP behavior

   UDP sends packets without retransmission or ordering, reducing delay.

4. Step 4: Evaluate options

   TCP's retransmission and ordering guarantees introduce latency that can disrupt real-time responsiveness correctly explains TCP's latency impact. TCP does detect packet loss, so TCP does not support packet loss detection, causing inconsistent game state is incorrect. UDP is connectionless, so UDP requires establishing a connection first, which delays game startup is incorrect. Packet size depends on payload, so TCP packets are always larger than UDP packets, increasing bandwidth usage is incorrect.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   TCP's reliability mechanisms add latency unsuitable for real-time games.

Hint: TCP = reliable but slower; UDP = faster but less reliable.

Common Mistakes:

• Believing TCP does not detect packet loss
• Thinking UDP requires connection setup
• Assuming TCP packets are always larger

4. Which of the following statements about UDP is INCORRECT?

medium

A. UDP provides built-in congestion control to avoid network overload

B. UDP is connectionless and does not guarantee packet delivery

C. UDP is suitable for applications where speed is more important than reliability

D. UDP packets may arrive out of order or be duplicated

Solution

1. Step 1: Review UDP characteristics

   UDP is connectionless, unreliable, and does not guarantee delivery or order.

2. Step 2: Analyze congestion control

   UDP does not implement congestion control; it sends packets without adjusting to network conditions.

3. Step 3: Evaluate options

   UDP provides built-in congestion control to avoid network overload is incorrect because UDP lacks congestion control. Options A, C, and D correctly describe UDP behavior.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   UDP is simple and fast but does not manage congestion.

Hint: UDP = no connection, no reliability, no congestion control.

Common Mistakes:

• Assuming UDP has congestion control like TCP
• Believing UDP guarantees packet order
• Confusing connectionless with unreliable

5. If a domain's authoritative DNS server is down, which of the following best describes how DNS resolution behaves assuming the recursive resolver has a cached entry with a TTL of 300 seconds that expired 10 seconds ago?

hard

A. The recursive resolver will attempt to query the authoritative server despite the expired TTL and return an error if unreachable.

B. The recursive resolver will return the expired cached record to the client to avoid resolution failure.

C. The recursive resolver will immediately return a SERVFAIL error to the client since the authoritative server is unreachable.

D. The recursive resolver will query the root server again to find an alternative authoritative server.

Solution

1. Step 1: Understand TTL expiration

   Once TTL expires, cached records are considered stale and should not be served without validation.

2. Step 2: Behavior on authoritative server failure

   The recursive resolver tries to refresh the record by querying the authoritative server.

3. Step 3: Outcome if authoritative server is down

   If unreachable, the resolver returns an error (e.g., SERVFAIL) to the client.

4. Step 4: Why other options are incorrect

   The recursive resolver will immediately return a SERVFAIL error to the client since the authoritative server is unreachable ignores retry attempt; The recursive resolver will return the expired cached record to the client to avoid resolution failure violates TTL rules by serving expired data; The recursive resolver will query the root server again to find an alternative authoritative server is incorrect because root servers do not provide alternative authoritative servers.

5. Final Answer:

   Option A -> Option A

6. Quick Check:

   Expired TTL triggers retry; failure returns error -> correct

Hint: Expired TTL means resolver must retry; failure leads to error, not stale data.

Common Mistakes:

• Assuming expired cache is always served
• Thinking root servers provide alternative authoritative servers
• Believing resolver returns error immediately without retry