保活

TCP keepalive 询问的是：连接安静了一段时间后，对面的 TCP 端点是否仍然响应。它不询问 HTTP handler 是否正常、数据库查询是否推进、后台工作线程是否卡住。即使应用已经停顿，内核仍然可能确认收到的数据。因此，“传输对端能够回应”和“应用给出了有用结果”必须作为两个不同的观察项。 传输层探针不是应用心跳 保活有助于暴露远端连接状态已经消失，或者网络路径悄悄停止传递报文的情况。实现会在满足空闲条件后发送探针，并按照未响应探针的策略最终报告失败；但单个探针丢失不等于对端死亡，不能把网络中的临时丢包直接解释成确定性故障。 探针在应用字节流以下处理，不会变成 HTTP 请求、数据库查询或 WebSocket 心跳。如果连接终止在代理上，探测对象就是代理自身的 TCP 端点，不是代理后面的源站。某些中间设备的连接跟踪可能受探针影响，但不能由此承诺刷新应用的空闲计时，更不能保证所有 NAT 映射都会一直保留。 已经发出而尚未确认的数据还有自己的重传与失败规则，因此保活参数不是繁忙连接的通用总截止时间。正常 FIN、连接重置、应用读取超时和静默丢包是不同事件，恢复动作也未必相同。知道是哪一层报告了什么错误，比统一把它们写成“连接死了”更有用。 配置真正承载请求的 socket RFC 1122 对可选保活机制要求默认关闭，并规定默认空闲间隔不得短于两小时且应可配置。但应用和库可以显式启用并选择更短间隔，Go 的拨号器就有自己的设置。因此，查到操作系统默认值，并不能直接推出当前应用实际使用的策略；还需要沿着创建连接的代码检查有效配置。 Linux 的 tcp_keepalive_time、tcp_keepalive_intvl 和 tcp_keepalive_probes 分别表示探测前的空闲秒数、探针间隔和未响应探针数量，文档默认值为 7200、75、9。启用 SO_KEEPALIVE 后，还可以通过 TCP_KEEPIDLE、TCP_KEEPINTVL、TCP_KEEPCNT 为单个 socket 定制策略。这些名称与接口不是 macOS、Windows 通用的系统参数，不能跨平台照搬命令。 ...