TCP

A TCP connection is not just a pipe. Both endpoints create state keyed by the 4 tuple: source IP, source port, destination IP, destination port. When a client calls connect, it sends a SYN segment that proposes an initial sequence number and often a set of options such as MSS, window scaling, and SACK permission. The server replies with SYN ACK, choosing its own initial sequence number and confirming what it accepts, and the client finishes with an ACK. After that point both sides agree on how to number bytes and how to interpret acknowledgements.

That handshake also prevents a big class of confusion. Without it, an old delayed packet from a previous conversation could look like valid data for a new conversation. The handshake forces both sides to prove they are live now and to synchronize sequence number spaces before application data is delivered.

If you look at a packet capture, you will often see more than the classic three segments. Options are how TCP adapts to real networks. MSS prevents oversized segments. Window scaling allows large receive windows on high bandwidth paths. SACK lets a receiver tell the sender which blocks arrived out of order, which reduces needless retransmissions on lossy links.

TCP delivers a byte stream, which means the application does not see message boundaries. Internally, every byte has a position. The sender groups bytes into segments and labels them with sequence numbers. The receiver acknowledges what it has received using acknowledgements that are usually cumulative, meaning it says the next byte it expects. If a segment is lost, the receiver either stays silent about that gap or acknowledges past it only when it can, and the sender eventually retransmits.

Loss detection is a mix of timers and hints. A retransmission timeout is the last resort. Faster recovery comes from duplicate ACKs: if the receiver keeps acknowledging the same next byte, the sender can infer a missing segment and retransmit early using fast retransmit. With SACK, the receiver can be precise about which data it already has, so the sender can focus retransmissions on what is truly missing.

Ordering is handled by buffering. If segments arrive out of order, the receiver can store them and still acknowledge what it has, but it will not deliver bytes to the application until the missing gap is filled. This is why a single lost packet can stall an otherwise fast flow, sometimes called head of line blocking.

Flow control protects the receiver. Each ACK carries an advertised receive window that tells the sender how much additional data the receiver can buffer. The sender must respect that limit even if the network could handle more. If the window drops to zero, the sender pauses and probes periodically until the receiver opens the window again.

Congestion control protects the network. TCP maintains a congestion window that limits how much data can be in flight without being acknowledged. At any moment, the sender is effectively constrained by the smaller of the congestion window and the receive window. This separation is important because receiver overload and network congestion are different problems with different signals.

Real congestion control algorithms vary by operating system and era, but the core idea is stable. Start cautiously, increase the sending rate while acknowledgements come back smoothly, and cut back when loss or delay suggests congestion. That is why throughput ramps up, then stabilizes, and sometimes drops sharply when the path becomes busy.

Most modern applications keep connections open and reuse them. A browser, for example, may open a small number of TCP connections to a site and send many HTTP requests over each. Reuse matters because connection setup costs at least one round trip, and slow start means the sender cannot immediately blast at full speed.

When a connection is idle, middleboxes can forget state. NAT devices and firewalls often time out mappings, so applications that need long lived connections use keepalives or periodic traffic. On lossy wireless links, you will see retransmissions and variable latency, and TCP will adapt by reducing its congestion window and then rebuilding it.

When the application is done, the clean shutdown is a FIN exchange. Each direction can close independently, which is why you may see one side send FIN and still receive data from the other side for a while. After closing, one side enters TIME WAIT to make sure late packets from the old connection do not corrupt a future connection that happens to reuse the same 4 tuple.

If ordering stalls, look for loss. A capture may show repeated duplicate ACKs, SACK blocks that point at a gap, and retransmissions. Even small loss rates can crush throughput on long delay paths because each loss event triggers backoff.

If throughput is capped, check the limiting window. A tiny receive window suggests the receiver or application is not reading quickly. A tiny congestion window suggests the sender is being cautious due to congestion signals. Measuring round trip time and retransmission rates helps you decide which story fits.

If the connection repeatedly resets, you might be seeing a firewall policy, a crash, or an application that is timing out and aborting. An RST is a hard abort, while a FIN is a graceful close. That difference matters for debugging.