How TCP works: handshakes, windows and reliable delivery

Imagine you want to send a long bedtime story to a friend, but you can only post one page at a time, and the post office sometimes loses pages or delivers them in the wrong order. How do you make sure your friend gets the whole story, in the right order?

First you phone them: "Can I send you a story?" They say "Yes, go ahead!" and you say "Great, here it comes!" Now you both know the other one is ready. That little back-and-forth is the handshake.

Then you number every page. When your friend gets page 4, they post back a note: "Got everything up to page 4, send me page 5." If a page never arrives, they keep asking for it, and you post that page again. Nobody reads the story until the pages are back in order.

Your friend can also say "Slow down, my desk is full!" so you do not bury them in pages faster than they can stack them. And when you reach the end, you both say a polite goodbye instead of just hanging up.

TCP (Transmission Control Protocol) is one of the main transport protocols of the internet. Its job is to take a stream of bytes from an application and deliver them to another application on another machine reliably and in order, on top of IP, which itself makes no such promises.

To know which application, TCP uses ports. An IP address gets you to the right machine; a port gets you to the right program on it (for example, web servers usually listen on port 443 for HTTPS). The combination of IP address + port on each side, plus the protocol, identifies a socket — one unique conversation.

• Connection-oriented: a connection is set up before any data flows, and torn down afterwards.
• Reliable: lost data is detected and resent; corrupted data is thrown away and resent.
• Ordered: bytes are delivered to the application in exactly the order they were sent.
• Flow-controlled: a fast sender will not overwhelm a slow receiver.

TCP chops the byte stream into chunks called segments, each wrapped in a TCP header (with ports, sequence numbers and flags) and handed to IP for delivery. The receiver reassembles the segments back into the original stream.

Its counterpart, UDP, skips all of this: no handshake, no acknowledgements, no ordering. That makes UDP faster and leaner, which suits things like live video and DNS lookups where a little loss beats waiting around.

A TCP connection begins with the three-way handshake. Each side picks a random starting sequence number (ISN) and announces it, so both ends agree where the byte numbering starts before any data flows.

1. SYN: the client sends a segment with the SYN flag set and its initial sequence number x.
2. SYN-ACK: the server replies with SYN set (its own ISN y) and ACK set, acknowledging x+1.
3. ACK: the client acknowledges the server's ISN with y+1. The connection is now ESTABLISHED and data can flow.

Sequence numbers count bytes, not segments: each segment's sequence number is the position of its first byte in the stream. Acknowledgement numbers are cumulative — an ACK of 1461 means "I have everything up to but not including byte 1461; send me that next."

If a segment is lost, the receiver keeps acknowledging the last in-order byte it has. The sender notices the missing ACK (via a timer or duplicate ACKs) and retransmits. Every segment also carries a checksum; a segment that fails it is silently dropped and treated as lost.

To avoid sending one segment and waiting for each ACK, TCP uses a sliding window: the sender may have several segments "in flight" (sent but not yet acknowledged) at once. The receiver advertises a receive window (rwnd) in every segment — how much buffer space it has free. The sender must never have more unacknowledged data outstanding than that window.

The receive window protects the receiver, but nothing in it protects the routers between the two endpoints. Congestion control adds a second, sender-side limit called the congestion window (cwnd). The sender may send no more than min(rwnd, cwnd) of unacknowledged data.

Classic TCP congestion control has two phases, governed by a slow start threshold (ssthresh):

• Slow start: cwnd begins small (a few segments) and roughly doubles every round-trip — exponential growth — until it reaches ssthresh or a loss occurs.
• Congestion avoidance: above ssthresh, cwnd grows linearly (about one segment per RTT). This is the additive increase half of AIMD.
• On loss: the sender backs off multiplicatively — the multiplicative decrease half of AIMD — because loss is read as a sign of congestion.

How it reacts depends on how loss was detected. A timeout is treated as serious: cwnd collapses back to one and slow start restarts. But three duplicate ACKs (the receiver repeatedly asking for the same byte) trigger fast retransmit — resend the missing segment immediately without waiting for the timer — followed by fast recovery, which halves cwnd rather than collapsing it, since ACKs are still arriving so the pipe clearly is not dead.

Closing a connection is a four-way exchange, because each direction is shut down independently. One side sends FIN, the other ACKs it (that direction is now half-closed), then sends its own FIN, which is ACKed in turn.

The side that sends the final ACK enters TIME_WAIT and lingers there for 2 × MSL (maximum segment lifetime, often around 60 seconds total). This exists for two reasons: to re-send the final ACK if it was lost (otherwise the peer keeps retransmitting its FIN), and to ensure any stray, delayed segments from this connection die out before the same four-tuple could be reused, preventing them from corrupting a new connection.

Underneath the friendly "ESTABLISHED" lies a formal state machine. Every socket is in exactly one state, and segments (or the application's connect/listen/close calls) drive transitions.

• LISTEN: server has called listen() and is waiting for incoming SYNs.
• SYN-SENT: client has sent a SYN and awaits the SYN-ACK.
• SYN-RECEIVED: server received a SYN and replied with SYN-ACK, awaiting the final ACK.
• ESTABLISHED: the fully open, data-transfer state for both ends.
• FIN-WAIT-1 / FIN-WAIT-2: the active closer has sent its FIN and is awaiting the ACK, then the peer's FIN.
• CLOSE-WAIT: the passive closer received a FIN; the application must still call close() before sending its own FIN.
• TIME-WAIT: the active closer waits 2×MSL before fully releasing the four-tuple.
• CLOSED: the connection no longer exists.

SACK (Selective Acknowledgement) patches a weakness of cumulative ACKs. Without it, after a single loss the sender can only learn "everything up to byte N arrived" and may needlessly resend data the receiver already has. With the SACK option, the receiver reports the specific non-contiguous blocks it received, so the sender retransmits only the genuine gaps. SACK is negotiated in the SYN and is enabled by default on all modern stacks.

Nagle's algorithm reduces tiny-packet overhead by holding back small writes until either the outstanding data is ACKed or a full segment's worth has accumulated. Delayed ACK independently holds back ACKs (up to ~200 ms) hoping to piggyback them on return data. Together they can interact pathologically: Nagle waits for an ACK that delayed ACK is deliberately sitting on, adding latency spikes to small request/response traffic. Latency-sensitive apps set TCP_NODELAY to disable Nagle.

Even with all of this, TCP cannot escape head-of-line blocking at the connection level, and its handshake plus TLS adds round-trips before data flows. QUIC (the transport under HTTP/3) tackles both: it runs over UDP, rebuilding reliability, ordering and congestion control in user space, and carries multiple independent streams in one connection so a loss in stream 3 does not stall streams 1 and 2. It also folds the cryptographic handshake into the transport handshake (see the TLS handshake), cutting setup latency to roughly one round-trip for new connections and zero for resumptions.

For troubleshooting, three tools cover most situations:

Note that DNS resolves the name to an IP address before any of this begins, and whether two IP addresses can even reach each other is an IP routing concern — see subnetting and CIDR.