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