Summary

  • TCP's three-way handshake is not ceremony before the real work. Its principal historical purpose is to keep an old duplicate SYN from being mistaken for a fresh connection attempt.
  • Each endpoint chooses its own initial sequence number. The responder can combine acknowledgment of the initiator's number with its own SYN, but the initiator must send a third message to prove that it saw the responder's current challenge.
  • Quiet time, TIME-WAIT, secret-offset ISNs and SYN cookies solve adjacent problems: old data, guessable numbers and premature server state. None turns TCP into cryptographic peer authentication.

A packet from the wrong conversation

An internetwork may delay, duplicate and reorder packets. That means correctness cannot be inferred from arrival alone. Imagine that two applications close a TCP connection and soon reuse the same source address, source port, destination address and destination port. A SYN from the old connection may still be wandering through the network when the new one begins.

The receiver sees the familiar four-tuple and a SYN flag. It cannot read history from the packet's face. If it accepts the segment as sufficient evidence of a new conversation, an expired request can create current state.

RFC 761, published in January 1980, framed the problem in sequence space. Each side chooses an initial send sequence number and learns the other's during connection establishment. The numbers allow later data to be ordered and duplicates rejected, but first the endpoints must agree on which numbers belong to this incarnation.

Four facts in three messages

Synchronization requires four logical statements. Endpoint A tells B, “my sequence number begins at X.” B confirms X. B tells A, “mine begins at Y.” A confirms Y.

TCP compresses the middle two statements into one segment. A sends SYN X. B replies SYN Y, ACK X+1. A returns ACK Y+1. This is why four facts need only three messages.

The arithmetic carries meaning. A SYN occupies one position in sequence space, so the next expected number is X+1. A pure ACK consumes no sequence number; otherwise acknowledgments would themselves require an endless chain of acknowledgments. RFC 793 made this exchange the standard connection-opening state machine in September 1981.

The endpoints do not consult a global connection register. Nor do they need one clock to assign all sequence numbers. Each implementation makes a local choice, and the messages make those choices mutually visible.

The third message is the proof

Why not stop after B's SYN-ACK? B has seen A's number, and A has received B's reply. But B does not yet know whether A sent the SYN now. The first SYN might be an old duplicate, and B's response might be travelling toward a host that no longer remembers it.

The final ACK closes that evidentiary gap. It tells B that whoever controls A's current endpoint state received Y and returned the expected acknowledgment. RFC 761 called this a trade-off between memory and messages: if B cannot retain a complete history of earlier numbers for every endpoint pair, it asks the apparent initiator to verify the current exchange.

This is narrower than identity. A correctly acknowledged sequence number proves reception within TCP's model. It does not identify the person operating the machine, authorize an application request or defeat an observer who can see and modify the exchange.

Old packets need time as well as numbers

The handshake protects connection initiation, but old data can survive beyond opening. TCP therefore binds sequence numbers to time as well as to a tuple. A number remains hazardous while a segment carrying it could still exist in the internetwork.

The early specifications used a maximum segment lifetime, or MSL, of two minutes as an engineering assumption. If a host crashed and lost its memory of recently used sequence space, it was supposed to remain quiet for one MSL before emitting new segments. If it retained the memory, it could resume with numbers beyond those already used.

After a normal close, TIME-WAIT holds the connection identity for twice the MSL. That pause lets delayed segments drain and allows the final acknowledgment of the close to be retransmitted. Waiting is not bureaucratic inertia; it is state that prevents an old packet from acquiring new meaning.

The current base specification, RFC 9293, preserves the model but says reboot quiet time is usually unnecessary in contemporary systems. Randomized ports and initial numbers reduce accidental reuse, effective packet lifetimes are shorter, and rebooting often takes longer than the danger interval. At high data rates, timestamps and PAWS address rapid sequence-space wrap. The principle survived even as the practical remedy changed.

When TIME-WAIT forgot its job

Time-based protection is only useful while implementations preserve it. RFC 1337 documented “TIME-WAIT assassination”: an old segment can provoke an ACK; the peer, which has already discarded its state, answers with a reset; accepting that reset can terminate TIME-WAIT prematurely.

If the same tuple is reopened immediately, old data or acknowledgments may overlap the new receive window. The memo demonstrated erroneous data acceptance, desynchronization and connection failure. Its lesson is not that TCP's handshake was useless. It is that several protections have different scopes: the handshake rejects an old initiating SYN, sequence checks police a live incarnation, and TIME-WAIT separates successive incarnations.

Deleting one layer because another exists confuses complementary evidence with redundancy.

A fresh number is not an authenticated peer

The original specifications already warned that the old-duplicate strategy did not stop spoofing. A host that could predict the next initial sequence number might forge the acknowledgments expected by a server without seeing its reply.

RFC 6528 hardened the choice. It combines a timer with a pseudorandom function of the local and remote addresses, ports and a secret. Different four-tuples receive sequence spaces without an obvious external relationship, while progression helps avoid reuse.

That repair protects a bounded claim: an off-path attacker should have difficulty guessing an acceptable number. An on-path observer sees the exchange. Cryptographic application or transport security is still required when the question is who the peer is rather than whether this TCP state is current.

Carrying state inside the challenge

The handshake also exposes a resource asymmetry. A public server may allocate a transmission control block after receiving the first SYN, before the apparent client has returned any proof. An attacker can send many forged SYNs and fill the half-open queue with state that never completes.

RFC 4987 records how SYN flooding became public and operationally serious in 1996. One response, the SYN cookie, delays allocation. The server constructs its SYN-ACK sequence number from the client tuple, the client's number, time, selected parameters and a secret. If a valid final ACK returns, the server reconstructs enough state to accept the connection.

The cookie turns the responder's number into a compact commitment. It preserves the third message as evidence while moving memory allocation to the point where that evidence arrives. The bargain is not free: limited bits can constrain option negotiation, and implementations differ.

The wider history is therefore not simply “three packets open TCP.” It is a sequence of narrower decisions about evidence. The network forwards claims. Endpoints choose sequence spaces. Reciprocal acknowledgment makes those choices shared. Time bounds stale meaning. Secrets resist blind guessing. Deferred state contains the cost of unanswered claims. None of these powers needs to become a global authority, and none proves more than its mechanism can observe.

Sources and evidence limits

The RFCs establish specifications, stated rationales and selected failure analyses. They do not provide one deployment date for every TCP stack. The architectural reading—local choices becoming shared through reciprocal evidence—is an inference from those mechanisms, not a phrase the RFCs use.