How TCP provides reliability and flow control

Before any data moves, TCP establishes a connection. The three-way handshake achieves two things: both sides agree that the channel is open, and both sides synchronise (SYN) their initial sequence numbers. Sequence numbers are what make reliable delivery possible.

The client sends a SYN segment with its initial sequence number. The server responds with a SYN-ACK: it acknowledges the client's sequence number and announces its own. The client confirms with an ACK. At that point, both sides know the connection is live and have the information needed to track byte position in the stream.

This costs one round-trip time (RTT) before a single byte of application data can be sent. On a connection with 100 ms RTT, that handshake alone adds 100 ms of latency before the browser sees the first HTTP byte. High-latency paths pay that cost on every new TCP connection.

Teardown is the mirror of setup. A normal close uses a FIN (finish) flag: the initiating side sends FIN, the other side ACKs, then sends its own FIN, and the first side ACKs that. Four segments total (sometimes collapsed into three). An RST (reset) is an abrupt close: no handshake, no waiting, just termination. Firewalls and load balancers often send RST when they drop a connection.

TCP is a byte-stream protocol. Every byte in the stream has a position, tracked by the sequence number. When the sender transmits bytes 1000 through 1499, the receiver responds with ACK 1500, meaning "I have received everything up to byte 1499, send me byte 1500 next." This is cumulative acknowledgement.

If a segment is lost, the receiver keeps acknowledging the last contiguous byte it has. The sender sees repeated ACKs for the same position, called duplicate ACKs (dupACKs). Three duplicate ACKs trigger fast retransmit: the sender retransmits the missing segment immediately without waiting for a full retransmission timeout (RTO).

The retransmission timeout is a fallback. If no ACK arrives within the RTO window, the sender retransmits and assumes the segment was lost. RTO starts high and is adjusted based on measured RTT. On a lossy path, RTO expiry can cause the sending rate to collapse dramatically.

The receive window (rwnd) is the amount of data the receiver is willing to accept at one time without being overwhelmed. It is advertised in every ACK. The sender may not have more than one window of unacknowledged data in flight at a time.

If the receiver's buffer fills up, the window shrinks to zero. The sender halts. The receiver sends a window update when space opens. This is flow control: the receiver directly throttles the sender to match its own processing capacity.

This is why a fast sender and a slow receiver can still have a degraded connection even on a perfect, zero-loss network. The bottleneck is application processing speed, not bandwidth. Wireshark labels these events as TCP Window Full and TCP ZeroWindow.

The congestion window (cwnd) is the sender's own limit on how much data to send, separate from the receiver's flow control window. It exists because the network between sender and receiver may not be able to handle the full rate, even if the receiver can.

Slow start is the algorithm TCP uses when a connection is new or recovering from loss. The sender begins with a small cwnd and doubles it for each RTT where all segments are acknowledged. This sounds fast but starts very conservatively to probe path capacity without causing immediate congestion.

When cwnd reaches a threshold called ssthresh (slow start threshold), the algorithm switches to congestion avoidance: the window grows by roughly one segment per RTT instead of doubling. When loss is detected, ssthresh is reduced and slow start or congestion avoidance begins again.

The effective sending rate is governed by the minimum of cwnd and rwnd. A slow application consumer, a congested path, and a lossy link can each independently reduce throughput. This is why "bandwidth is fine" does not end the conversation about why a file transfer is slow.

RFC 9293 describes TCP as providing "a reliable, in-order, byte-stream service." That is the complete description. It covers reliability (lost segments are retransmitted), ordering (segments are delivered in sequence), and byte-stream (TCP does not preserve message boundaries; the application must frame its own messages).

What TCP does not guarantee: exactly-once delivery at the application level, guaranteed latency, or protection from the connection being terminated early. If the network path fails entirely, TCP will eventually give up and close the connection. The application sees an error, not a delivery receipt.

The distinction matters for distributed systems. "TCP is reliable" is a transport statement. "The database write was committed exactly once" is a business logic statement. TCP can confirm that bytes were delivered to the receiving kernel. It cannot confirm that the application processed them, or that the processing was idempotent.