长连接池里"半开连接"怎么低成本检测：TCP keepalive 参数预算设多少，才能既识别死对端又不误判、探测开销可控？

背景

15 年网络工程，现在保一批跨机房长连接池（gRPC over HTTP/2 + 一批 HTTP/1.1），单侧连接数 2 万上下。最头疼的一类故障不是"链路断了"，而是对端节点静默死亡（断电、内核 panic、网络分区、交换机黑洞）——socket 进入 half-open：本端完全不知道对端已经不在了，直到某次应用层 read/write 真正打到它，请求就一路 hang 到某个上层超时（我们 30–60s）才失败，期间连接池里这条连接一直被复用，把坏连接"养"在池里。

我想在探测开销可控的前提下，尽快把死对端识别并剔除，而不是靠应用层心跳硬扛。

现象

1. 对端节点重启 / 网络分区后，本端若干连接进入 half-open；
2. 后续命中这些连接的业务请求 hang 30–60s，表现为 P99 尖刺 + 连接池占用率上涨，但 tcpdump 看不到重传（因为根本没发探测）；
3. 应用层心跳能兜住，但心跳本身就是"每条连接每 N 秒多一次 RTT"，2 万连接规模下这个额外流量我算过不小，不想无脑加密。

已尝试的排查与结果

• 内核默认 net.ipv4.tcp_keepalive_time=7200s：太慢，基本等于没开；
• 试过一次 tcp_keepalive_time=60s / intvl=10s / probes=3：能识别，但我担心两点——(a) 高负载/拥塞链路上正常的重传延迟会不会被误判成"死"，把慢对端当死对端砍掉；(b) 2 万连接 × keepalive 探测的额外包量到底多大，我在 25G 链路上没实测过这笔账；
• 也考虑过应用层心跳（HTTP/2 PING / 自研 heartbeat），但同样绕不开"探测频率 vs 流量开销 vs 检测时延"这个三角。

期望得到的答案形态

1. 一套可复现的 TCP keepalive 参数预算（tcp_keepalive_time / intvl / probes），并说明这套参数下"死对端"和"慢对端"在抓包上怎么区分（RST/FIN/无 ACK vs 有重传），避免误判；
2. keepalive 探测 vs 应用层心跳，在"检测时延 / 额外流量 / 误判率"三个维度上的取舍，以及 2 万连接规模下探测开销的量化估算方法（能给出怎么算 / 怎么实测的口径）；
3. 是否有比裸 keepalive 更省的机制（如 SO_LINGER、HTTP/2 GOAWAY / PING、连接池 idle 探测），以及它们各自的代价。

参考：#896 里那位同学遇到的"抓包 RTT 正常但应用层超时"，我猜部分根因就是 half-open 没被及时识别；#90 讨论过"网络观测做到什么程度算够"，我觉得 keepalive 参数预算正是"够用"这条线上最常被默认忽略的一块。