so_keepalive仅是启用内核keepalive机制的开关，不配置探测参数；实际探测行为由tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes三个内核参数决定，应用层需配合协议心跳实现可靠保活。
SO_KEEPALIVE 本身不定义心跳行为，只打开开关；真正决定“什么时候探、探几次、间隔多久”的是内核参数或 setsockopt 设置的三个底层值。
SO_KEEPALIVE 只是启用标志，不是配置接口
调用 setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &enable, sizeof(enable)) 仅告诉内核：“这个 socket 允许走 Keepalive 流程”。它不设置任何时间参数。一旦启用，该 socket 就完全受制于系统级的三个参数：tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes。这些值默认是全局的（7200/75/9），对所有启用 SO_KEEPALIVE 的 socket 生效。
常见错误现象：代码里开了 SO_KEEPALIVE，但连接空闲两小时才断，误以为“没生效”——其实是内核默认值太长，不是 socket 没启。
- Windows 下无法通过 socket 级别覆盖
tcp_keepalive_time，只能改注册表或全局策略 - Linux 3.7+ 支持
TCP_KEEPIDLE/TCP_KEEPINTVL/TCP_KEEPCNT单独设 per-socket 值，但必须在SO_KEEPALIVE启用后调用 - macOS 和 BSD 系统用
TCP_KEEPALIVE（注意不是TCP_KEEPIDLE）传 struct，行为不一致，跨平台需谨慎
为什么不能只靠 SO_KEEPALIVE 做业务保活
TCP Keepalive 探测包本质是空 ACK 或带 RST 标志的探测段，它只确认“对端内核 TCP 栈是否在线”，不触发应用层逻辑。这意味着：
- 远端进程已卡死但 socket 未关闭 → Keepalive 仍能收到 ACK → 连接不断，但请求永远得不到响应
- 连接穿过 NAT 或四层 LB（如阿里云 SLB）→ 中间设备连接老化时间（常为 60~300 秒）早于
tcp_keepalive_time→ socket 还在等探测，连接其实已被设备静默回收 - 容器网络（如 Cilium）启用 eBPF 转发时，某些版本会丢弃 Keepalive 探测包 → 表现为“永远收不到响应”，连接超时时间被拉长到最大 probes × intvl
所以 SO_KEEPALIVE 是兜底手段，不是第一道防线。IM、微服务、数据库客户端必须自己实现协议层心跳（如 Redis PING、gRPC keepalive 参数、HTTP/2 PING 帧）。
如何在代码中正确组合使用 SO_KEEPALIVE 和应用层心跳
典型做法是：应用层心跳负责快速感知业务异常（秒级），SO_KEEPALIVE 负责兜住网络层静默故障（分钟级）。关键点在于避免参数冲突和资源浪费：
- 应用层心跳周期应显著短于
tcp_keepalive_time（例如设为 30 秒），否则 Keepalive 探测还没启动，连接就被 LB 清掉了 - 若应用层已保证高频通信（如每 10 秒发一次业务数据），可直接禁用
SO_KEEPALIVE（enable = 0），省去内核额外探测开销 - Linux 下若需 per-socket 控制，顺序必须是：
setsockopt(... SO_KEEPALIVE ...)→setsockopt(... TCP_KEEPIDLE ...)→setsockopt(... TCP_KEEPINTVL ...)→setsockopt(... TCP_KEEPCNT ...)，漏掉任一都可能 fallback 到全局值 - Go 的
net.Conn.SetKeepAlive、Java 的Socket.setKeepAlive(true)都只是封装了SO_KEEPALIVE开关，不提供参数设置能力，需另行调用系统命令或 JNI
最易被忽略的一点：很多团队调优只改了 tcp_keepalive_time，却忘了同步调整 tcp_keepalive_probes。比如把 time 缩到 600 秒，但 probes 还是 9 次、intvl 还是 75 秒，总超时反而变成 600 + 9×75 = 1275 秒（约 21 分钟），比原来还慢。参数必须成套看、成套调。
