Summary

  • TCP calls a connection half-open when one endpoint has discarded or lost its state without the other's knowledge, leaving their connection histories inconsistent.
  • If the surviving endpoint sends data, the state-less peer responds with RST; the endpoint that still believed the connection established then aborts it.
  • If the rebooted endpoint tries to reopen, the stale peer's sequence-space ACK exposes the mismatch, and the new opener sends RST before continuing with an ordinary handshake.
  • Reset does not restore the old connection or recover lost application work; it removes stale transport state so a new history can begin.

A connection held by two memories

TCP presents applications with a connection, but the protocol implements that connection as compatible state at two separate endpoints. Each side remembers sequence numbers, acknowledgment progress, windows and a place in the state machine. The abstraction holds only while those memories agree.

RFC 793 named the failure case directly. An established connection is half-open when one TCP has closed or aborted without the other's knowledge, or when a crash destroys memory and desynchronizes the two ends. RFC 9293 preserves the same definition. One endpoint may still report ESTABLISHED even though the peer has no transmission control block for the connection at all.

This is not TCP's orderly half-close. A half-close uses FIN to end one direction while the reverse direction remains deliberately available. A half-open connection is accidental disagreement: one side retains a shared history that the other can no longer recognize.

When the survivor sends first

The simplest discovery begins at the endpoint that did not fail. Peer B still believes its connection with A is synchronized and sends data. A has rebooted and has no matching connection.

To A, the segment does not continue any live history. In CLOSED state, it answers the unacceptable non-reset segment with RST. B receives an acceptable reset, aborts the connection it thought was established and reports the failure upward. The specifications describe half-open connections as automatically becoming reset when traffic is attempted in either direction.

That reset carries no missing application state back to B. It does not say which bytes were processed before A failed or whether a transaction committed elsewhere. It says only that the peer cannot participate in the connection B remembers.

When the forgotten side starts again

The paired example is more revealing. After reboot, A tries to open what it treats as a new connection. It chooses a new initial sequence number and sends SYN. B, however, still has the old connection in a synchronized state.

The arriving SYN falls outside the receive window B associates with that old history. B replies with an ACK stating the sequence number it expects next. A is still unsynchronized. The ACK acknowledges nothing A sent in its new attempt, so A recognizes the incompatible history and sends RST.

B processes the reset and aborts its stale connection. A continues trying to establish the new one. Once the obsolete state has been removed, the problem has become an ordinary three-way handshake. The protocol does not merge the histories; it ends the one that can no longer be shared.

Reset as disagreement made visible

In these traces, reset is neither a generic sign of hostility nor a repair packet that reconstructs state. It is the terminal result of comparing incompatible endpoint beliefs. Sequence numbers and acknowledgments expose the mismatch; RST prevents one endpoint from continuing to rely on a connection the other endpoint cannot validate.

That role also explains why the details matter. The reset rules must distinguish a segment that belongs to no connection from one that belongs to a synchronized connection, and modern hardening of reset acceptance addresses additional security questions. Those questions should not be collapsed into the historical half-open example, whose subject is state loss and recovery rather than spoofing.

The application boundary

TCP can clear the transport contradiction. It cannot decide how the application should recover. A restarted service may rebuild local state, retry an operation, resume from a checkpoint or reject the old session. A client may not know whether its last request took effect before the failure.

The RFC examples therefore stop at a disciplined boundary. After reset, the old transport connection is gone and a fresh handshake can establish another. Authentication, transaction identity, replay safety and recovery of undelivered work belong to protocols and applications above TCP.

Sources