摘要

  • TCP Keep-Alive 探测要求空闲对端依据已有序列状态作出回应；它不是应用健康检查。
  • TCP 不保证只含 ACK 的报文会可靠送达，因此一次探测没有收到回复，不能证明连接已经失效。

如果长时间没有收到入站报文，也没有新数据可发或等待重传的未确认数据，TCP 连接可以保持沉默。这种沉默可能只是健康应用暂时没有数据，也可能掩盖了路径或对端已经不可达。Keep-Alive 正是在这个边界上请求对既有序列状态进行一次额外观察。

这个机制不替代重传。只要已发送的数据仍未获确认，TCP 就已有重传与 User Timeout 机制来判断数据交付能否继续。Keep-Alive 只在连接除此以外处于空闲状态时才开始工作。

RFC 1122 描述的探测通常使用 SND.NXT-1 作为序列号，位于发送方下一次发送新数据所用字节之前。仍保有 TCP 状态的对端可以依据该状态回复。探测应当不携带数据；对于不能正确处理无数据形式的错误实现，可以提供一个单字节兼容形式。无论哪种形式，这都是传输层控制交换，而不是普通应用消息。

Keep-Alive 支持是可选的。实现该功能时，应用必须能够按连接启用或禁用，而且默认必须关闭。只有在没有已发送但仍待确认的数据，并且在配置间隔内没有收到数据或确认报文时，才可以发送探测。该间隔必须可配置，标准规定的默认值不得少于两小时。

RFC 9293 保留了 RFC 1122 的关键限制：TCP 不保证只含 ACK 的报文会可靠送达。对端可能收到探测并生成预期确认，但确认仍可能在途中丢失。因此，不能把某一次探测未获回复单独解释为连接已失效。规范的整合也没有把这一机制变成普遍的存活服务。

来源