默认 TCP KeepAlive 设置

Question

TCP KeepAlive（套接字选项SO_KEEPALIVE）由三个选项控制——机制触发的时间、探测间隔以及连接被声明中断后失败的探测次数。

它们的默认值是：

• tcp_keepalive_time = 7200
• tcp_keepalive_intvl = 75
• tcp_keepalive_probes = 9

在 1¼ 分钟后发送探测听起来很合理，在 9 次探测失败后宣布失败也是如此，但最初2 小时背后的想法是什么？

甚至tcp(7)说

请注意，底层连接跟踪机制和应用程序超时可能要短得多。

启用 keepalive 的主要目的是防止任何有状态的网络元素丢弃状态信息，但这些元素往往会在几分钟内丢弃连接。对于一些限速服务器，curl短片--keepalive-time似乎可以显着提高下载的可靠性。

那么为什么默认值这么长呢？

Answer 1

TCP Keep-alive 的定义是在防火墙的概念（更不用说状态防火墙或 NAT）可能还没有普及的时候。来自RFC 1122（1989 年 10 月）：

4.2.3.6 TCP 保活

实现者可以在其 TCP 实现中包含“keep-alives”
，尽管这种做法并未得到普遍
接受。如果包含保持活动，应用程序必须
能够为每个 TCP 连接打开或关闭它们，并且
它们必须默认为关闭。

仅当在一定时间间隔内
没有收到连接的数据或确认数据包时，才必须发送保持活动数据包。
该间隔必须是可
配置的，并且必须默认不少于两个小时。

[...]

当时的主要想法不是关于状态信息丢失：

讨论： 当连接 空闲时，即使没有数据要发送，
“保持活动”机制也会定期探测连接的另一端。TCP 规范不包括保持活动机制， 因为它可能： (1) 在短暂的 Internet 故障期间导致良好的连接 中断；(2) 消耗不必要的带宽（“如果没有人使用该 连接，谁在乎它是否仍然良好？”）；(3)按 数据包 收费的互联网路径需要花钱。

[...]

TCP 保持活动机制只能在服务器应用程序中调用
，否则如果 客户端在网络故障期间崩溃或中止连接，服务器应用程序可能会
无限期挂起并消耗不必要的资源 。

我浏览了更新的 RFC，但没有很好地提及 keepalived。