Summary

  • A TCP keep-alive probe asks an idle peer to restate transport state; it does not carry a general application-health verdict.
  • Because a data-free acknowledgment is not reliably delivered, one unanswered probe must not be treated as proof that the connection is dead.

The connection has carried no segment for a long interval. There is no new data to send and no unacknowledged data waiting for retransmission. Nothing in TCP's ordinary traffic now forces either endpoint to speak. That silence may mean a healthy application has nothing to say, or it may conceal a vanished path or peer. The keep-alive mechanism enters precisely at this boundary: not to manufacture activity, but to solicit one more observation from established sequence state.

RFC 1122 described the probe in an intentionally peculiar form. Its sequence number generally sits at SND.NXT-1, immediately before the next byte the sender would use for new data. A surviving peer can answer from the state it already holds. The probe should contain no data, although implementations may offer a one-octet compatibility form for peers that mishandle the data-free version. Either way, the exchange belongs to the transport control surface, not to the application's message stream.

The permission to probe came with governance. Keep-alive support is optional. If an implementation includes it, the application must be able to switch it on or off for each connection, and it must default to off. The probe may be sent only when no sent data remains outstanding and the connection has received neither data nor acknowledgments for the configured interval. That interval must itself be configurable, with a standards default of no less than two hours.

Those rules matter because keep-alive is not ordinary retransmission. When sent data is outstanding, TCP already has retransmission and user-timeout machinery for deciding whether delivery can continue. Keep-alive begins only after the connection is otherwise idle. Its question is narrower: does enough of the remote TCP state remain reachable to produce a sequence-space-valid response?

RFC 9293 preserves the most important limit from the earlier host requirements. ACK-only segments are not reliably transmitted by TCP. A peer might receive a keep-alive probe and generate the expected acknowledgment, yet that response can still disappear. The probing endpoint must therefore not interpret failure to answer any one specific probe as a dead connection. Silence is an observation, but one silence is not a conclusive failure certificate.

That distinction survives the consolidation from RFC 1122 into the current TCP specification. The mechanism did not become a universal liveness service. It remained optional, disabled by default, scoped to idle connections and constrained in how negative evidence may be interpreted. The historical design is less about periodically sending packets than about limiting what a missing packet is allowed to prove.

Sources