Networking / Intermediate: lifecycle, trust, and application protocols / Lesson 8

Read TCP state, flow control, and congestion

Connect sequence space, acknowledgements, windows, retransmission, and connection closure without turning packet symptoms into unsupported causes.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain TCP sequence and acknowledgement meaning.
Separate receiver flow control from network congestion control.
Interpret retransmission and close states with context.

Connection state describes an endpoint’s view

TCP endpoints maintain state during establishment, transfer, and closure. SYN, acknowledgement, FIN, and reset behavior have protocol-defined meanings, but one observed segment does not reveal every prior event. A connection can be half-closed so one direction ends while the other still carries data. TIME-WAIT is part of normal protocol protection, not automatically a leak. Keep both endpoint roles and the observation time. A proxy creates separate TCP connections, so server-side and client-side state may differ even while representing the same application request. Do not diagnose the entire request from one state label.

Acknowledgements refer to byte sequence space

TCP uses sequence numbers to identify byte positions and acknowledgements to indicate the next expected sequence under its rules. SYN and FIN consume sequence space even though they are not application payload bytes. Retransmitted data can repeat a sequence range without representing a second application message. Real sequence arithmetic wraps modulo its field width, so a simple subtraction example is valid only within a stated non-wrapping range. Selective acknowledgement adds information about received ranges, but a basic cumulative ACK alone does not identify exactly where or why a loss occurred.

python Calculate a declared non-wrapping ACK example

initial_sequence = 1000
syn_consumption = 1
payload_bytes = 120
next_expected = initial_sequence + syn_consumption + payload_bytes
print('synthetic_ack=' + str(next_expected))

Expected output

synthetic_ack=1121

A SYN at 1000 followed by 120 consecutive payload bytes leads to 1121 in this simplified fixture. It does not parse or transmit TCP segments.

Receiver capacity and path capacity are different

The receive window limits what the receiver advertises it can accept, while congestion control manages sending according to the network path and its signals. The sender’s usable in-flight budget is constrained by both, along with other protocol and implementation details. A zero receive window suggests a receiver-side flow-control condition rather than proof of network packet loss. A small congestion window can reflect startup or recovery, not merely a configured buffer size. Compare the active limiting mechanism with application reads and path evidence before recommending a buffer or concurrency change.

python Separate two declared window constraints

congestion_window = 6000
receive_window = 4000
inflight = 2500
budget = max(0, min(congestion_window, receive_window) - inflight)
print(f'synthetic_additional_budget={budget} bytes')

Expected output

synthetic_additional_budget=1500 bytes

The conceptual budget is 1,500 bytes in this non-wrapping teaching model. Actual TCP behavior includes timers, segmentation, and implementation rules beyond this arithmetic.

Retransmission is evidence, not a root cause

A retransmission can follow loss, reordering, delayed feedback, or another recovery condition. The observing point may also miss an earlier segment and make an analyst infer a false loss. Timers and duplicate acknowledgements contribute to recovery decisions under the selected algorithm. Do not label every repeated segment a faulty cable or every timeout a firewall drop. Preserve sequence ranges, acknowledgement progress, timing, and capture limitations when using an authorized trace. Here those are synthetic records only; no live capture or test traffic is used. A correct diagnosis needs corroboration across layers and endpoints.

A healthy transport still needs a healthy consumer

An application that stops reading can constrain TCP even when the route and link are healthy. A server waiting on a database can hold an established connection with no immediate response. Connection pools, proxies, idle timeouts, and retries add lifecycle boundaries above TCP. Align transport events with application request identifiers and error outcomes rather than treating an open socket as proof of useful progress. Retry policy must account for whether the operation may already have committed. Improve the mechanism that explains the delay, preserving application correctness rather than blindly tuning transport defaults.

Common errors and fixes

A repeated sequence range is called duplicate business work

Why it happens: Transport recovery was confused with message delivery.
How to fix it: Apply stream reassembly and application framing.
Prevent it next time: Separate byte and request identities.

Receive window and congestion window are conflated

Why it happens: Receiver pressure and path control were treated as one limit.
How to fix it: Identify which budget constrains progress.
Prevent it next time: Record both endpoint and path evidence.

TIME-WAIT alone is called a fault

Why it happens: Normal closure protection was ignored.
How to fix it: Compare counts, lifecycle, and actual failures.
Prevent it next time: Teach state meaning before alert thresholds.

Check your understanding

1. Why does a TCP ACK not prove the report was committed to a database?

Show worked solution

It acknowledges transport sequence progress, not the application’s transaction. The application may not yet have read, validated, or committed the bytes. Require the documented application response and design retries around possible prior completion.

2. A receiver advertises no available window. Which hypothesis should be distinguished from congestion?