TCP KeepAlive（套接字选项SO_KEEPALIVE）由三个选项控制 - 触发机制的时间、探测间隔以及连接中断后宣布失败的探测次数。
它们的默认值是：
- tcp_keepalive_time = 7200
- tcp_keepalive_intvl = 75
- tcp_keepalive_probes = 9
1/4分钟后发送探测听起来很合理，9次探测失败后宣布失败也是如此，但最初的想法是什么2小时？
甚至TCP(7)说
请注意，底层连接跟踪机制和应用程序超时可能会短得多。
启用保活的主要目的是防止任何有状态的网络元件丢弃状态信息，但这些元件往往会在几次内丢弃连接。分钟。对于一些速率受限的服务器，curl短时间--keepalive-time似乎可以显着提高下载的可靠性。
那么为什么默认值这么长呢？
答案1
TCP Keep-alive 是在防火墙的概念（更不用说状态防火墙或 NAT）可能还没有普及的时候定义的。从RFC 1122（1989 年 10 月）：
4.2.3.6 TCP 保活
实现者可以在其 TCP 实现中包含“keep-alives”
，尽管这种做法并未得到普遍
接受。如果包含保持活动，应用程序必须
能够为每个 TCP 连接打开或关闭它们，并且
它们必须默认为关闭。仅当在一定时间间隔内
没有收到连接的数据或确认数据包时，才必须发送保持活动数据包。
这个间隔必须是
可配置的并且必须默认不少于两个小时。
[...]
当时的主要想法不是关于状态信息丢失：
讨论：当 连接空闲 时，即使没有数据要发送，
“保持活动”机制也会定期探测连接的另一端。 TCP
规范不包括保持活动机制，
因为它可以： (1) 在短暂的互联网故障期间导致良好的连接
中断； (2)
消耗不必要的带宽（“如果没有人使用该
连接，谁在乎它是否仍然良好？”）；和（3）
按 数据包 收费的互联网路径需要花钱。
[...]
TCP 保持活动机制只能在
服务器应用程序中调用，否则如果 客户端在网络故障期间崩溃或中止连接，服务器应用程序可能会
无限期挂起并消耗不必要的资源 。
我浏览了更新的 RFC，但没有很好地提及 keepalived。