Summary

  • TCP simultaneous open occurs when both endpoints actively open the same connection and their bare SYN segments cross while both are in SYN-SENT.
  • Each endpoint acknowledges the other's sequence space, passes through SYN-RECEIVED, and reaches ESTABLISHED; the exchange creates one connection, not two.
  • RFC 9293 requires support for this path and requires implementations to remember whether SYN-RECEIVED followed an active or passive open.
  • The mechanism proves that TCP establishment is protocol-symmetric, but it does not guarantee that NATs, firewalls, socket APIs, or applications permit the packets to meet.

The handshake before the roles

TCP is commonly taught as a dialogue between unlike parties. A client sends SYN. A listening server replies with SYN+ACK. The client acknowledges, and the connection exists. That sequence is correct, but the labels can make an application convention look like a transport rule.

RFC 793 framed the three-way handshake more generally as connection synchronization. It said that one TCP normally initiates and another responds, then immediately added that the procedure also works when two TCP endpoints initiate simultaneously. The important objects are not client and server roles. They are two independently chosen sequence spaces that must be acknowledged before either endpoint treats incoming data as belonging to the new connection.

When the SYNs cross

Suppose peer A and peer B both perform an active OPEN for the same pair of sockets. A chooses its initial sequence number and sends a SYN. B does the same. Before either SYN is answered, the two segments cross in the network.

Each peer is now in SYN-SENT when it receives a segment containing SYN but no acknowledgment. Instead of rejecting the segment because nobody was listening, the simultaneous-open path treats it as the other half of synchronization. Each endpoint records the peer's initial sequence number, enters SYN-RECEIVED, and sends SYN+ACK.

The acknowledgment advances by one because SYN itself occupies one place in TCP's sequence space. When A receives B's acceptable SYN+ACK, it knows B has received A's SYN; B reaches the same conclusion from A's SYN+ACK. Both enter ESTABLISHED. The two active opens have converged on one bidirectional connection identified by the same endpoint pair.

Symmetry still needs memory

The path is symmetric on the wire, but it is not stateless. Each endpoint must remember the sequence number it selected, the sequence number announced by its peer, what has been acknowledged, and how it arrived in SYN-RECEIVED.

RFC 9293 makes that last fact explicit. Alongside its requirement that implementations support simultaneous open, it requires them to track whether SYN-RECEIVED resulted from a passive OPEN or an active OPEN. The distinction matters later because reset and error handling can return a passive opener to LISTEN while an active opener must report failure to the user. The same visible state therefore carries different recovery meaning depending on its provenance.

This is a subtle engineering point. Protocol symmetry does not mean that all local histories become interchangeable. It means both endpoints can execute the same state machine while retaining enough local history to choose the correct next transition.

The duplicate that looks like a knock

RFC 793 warned that an old duplicate SYN can make it appear that simultaneous initiation is under way. That possibility is one reason the handshake has three steps rather than simply accepting the first synchronization segment it sees.

The endpoint must determine not only that a SYN arrived, but that the acknowledgments and sequence numbers describe a coherent current exchange. Reset processing provides a way to reject apparent connections when one side has no matching state. The simultaneous-open feature therefore sits inside TCP's broader defense against confusing one connection incarnation with another; it is not a shortcut around those defenses.

What the standard does not promise

At the transport layer, neither endpoint must be a permanent listener. At the deployment layer, many other conditions remain. Packets need routes. Firewalls need rules that admit the exchange. Address translators may need compatible mappings. Socket APIs and applications must expose or exercise the active-open behavior on both sides.

The two standards do not provide measurements of current use or guarantees about middlebox traversal. Simultaneous open is therefore not evidence that arbitrary peers can punch through any network boundary. It is a precise, narrower claim: if the matching SYNs reach two TCP endpoints in the right state, the standardized state machine knows how to synchronize them.

Sources