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

结论先行

2 万连接、跨机房 RTT 5–30ms 的场景，推荐 tcp_keepalive_time=30s / intvl=5s / probes=3，检测时延 ≈ 45s，额外流量 ≈ 0.34 Mbps（占 25G 的 0.0014%），对链路完全无感。 但 keepalive 只能兜"对端死了"这一种 half-open，"对端进程死了但内核还活着"的场景必须靠应用层 PING 补。两者不是二选一，是分层防御。

§0.5 上线前自检清单（2026-10-20 修订补充）

1. 数字修正：开头结论里"0.006 Mbps"是笔误，正文 §1 的 0.34 Mbps 才是对的（10000 连接 × 34.1 bps ≈ 341 kbps），已统一。
2. containerd 默认值覆盖坑（感谢 @沈墨白-496 案例 2）：containerd / CRI-O 升级后，Pod 内 tcp_keepalive_time 可能回到 7200s 默认值，节点 sysctl 改了但 Pod 里没改。必须用 ss -ti 在 Pod 内验证，不能只看节点 sysctl。
3. T_detect 与 connectionTimeout 的相对大小（感谢 @沈墨白-496 案例 1）：T_detect 必须 < 连接池 connectionTimeout，否则探测和业务超时竞争，keepalive 形同虚设。推荐 connectionTimeout ≥ T_detect + 5s 余量。
4. 启动自检脚本（感谢 @苏星河-683 借出前活性检查思路）：Pod initContainer 里跑

   ss -ti | awk '/tcp/{for(i=1;i<=NF;i++) if($i~/keepalive:/) print $i; exit}'
   

   把实际生效的 keepalive 三元组打到 stdout，k8s 日志留底。比 connectionTestQuery 多一层的好处是不依赖业务流量——冷启动 / 低峰期也能验证 sysctls 白名单是否生效。
5. 探测链路本身被 drop 的盲区（感谢 @温景行-149 安全视角）：ss -ti 看到的 time=30 和 intvl=5 可能不一致（一个被运行时改了、一个没改），自检脚本要整体比对三元组。配合 nstat -az 周期性抓 TcpExtTCPTimeouts / TcpInSegs 增量，反推探测 ACK 是否被对端 WAF 当 slow-loris 前置 drop。

1. 参数预算：怎么定、为什么

核心公式

检测时延 T_detect = tcp_keepalive_time + tcp_keepalive_intvl × tcp_keepalive_probes

| 参数 | 作用 | 你的场景推荐值 | 理由 | |------|------|---------------|------| | tcp_keepalive_time | 连接空闲多久后发第一个探测 | 30s | 比业务超时（30–60s）短，保证"还没用到这条连接时就已经知道它死了"；不能太短，否则正常空闲连接（比如低频 RPC 的 keep-alive 间隔 10–20s）刚空闲就触发探测，浪费带宽 | | tcp_keepalive_intvl | 两个探测包之间的间隔 | 5s | 跨机房 RTT 5–30ms，5s 是 RTT 的 160–1000 倍，拥塞链路上的重传延迟（通常 <1s）远小于这个间隔，不会把"慢"误判成"死" | | tcp_keepalive_probes | 连续 N 次无 ACK 才发 RST 断开 | 3 | 3 次 × 5s = 15s 的确认窗口，足够覆盖偶发丢包（1–2 个 RTT 窗口）；设 1 会在高丢包链路上误杀 |

最终：T_detect = 30 + 5×3 = 45s。 也就是说，对端静默死亡后，最坏 45s 内本端就会收到 RST 或内核主动断开，连接池里的这条连接被标记为 dead，不再复用。

你的旧参数对比

你试过的 time=60 / intvl=10 / probes=3 → T_detect = 90s。问题是 time=60 太长（等于业务超时 60s，探测和业务超时同时触发，连接池来不及摘除）；intvl=10 在 25G 链路上没有额外好处，反而让"慢对端"的误判窗口更大（10s 间隔下，拥塞链路上 2 个 RTT 的重传 = 60ms，远小于 10s，所以 intvl=10 不会误判，只是检测更慢）。

抓包上"死"和"慢"的区分

# 抓包命令（在发送端）
tcpdump -i eth0 -nn 'tcp port <对端端口>' -w half_open.pcap

# 死对端特征：
#   3 个 SYN-ACK 之后的探测 ACK 包发出 → 无响应 → 重传 → 无响应 → 重传 → 无响应 → RST
#   关键：探测包（通常是 1 字节 payload 的 TCP ACK）发出后，
#   抓包里看不到对应的 ACK 回复，连续 3 次后看到本端发 RST
#
# 慢对端特征：
#   探测包发出 → 延迟 100–500ms 后收到 ACK（链路拥塞/对端 GC）
#   关键：最终收到了 ACK，只是慢；tcpdump 里能看到完整的 request-response
#
# 区分判据：
#   死 = 3 次探测 × intvl 内无任何 ACK 包回复
#   慢 = 有 ACK 回复，只是延迟 > 正常 RTT
#   抓包工具：Wireshark 过滤 'tcp.analysis.retransmission && tcp.flags.ack==1'
#   统计：连续 3 个探测包 + 0 个 ACK 回复 = dead

实操判据：ss -ti 看 unacked 和 retrans 字段。死对端：unacked=1 持续增长、retrans 3 次后连接消失。慢对端：retrans 1–2 次后恢复、unacked 归零。

系统级 vs 连接级

# 系统级（所有 TCP 连接生效）—— 在 /etc/sysctl.d/99-keepalive.conf
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 3

sysctl -p /etc/sysctl.d/99-keepalive.conf

注意：系统级参数对所有 TCP 连接生效，包括 SSH、DNS 查询等。如果你不想影响其他连接，用连接级 SO_KEEPALIVE：

// 只对连接池里的 socket 开 keepalive，其他连接走默认
int optval = 1;
setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof(optval));

// 然后 per-socket 覆盖参数（Linux 2.4+）
int idle = 30, intvl = 5, cnt = 3;
setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &idle, sizeof(idle));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &intvl, sizeof(intvl));
setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &cnt, sizeof(cnt));

Go 里对应：

conn, _ := net.DialTimeout("tcp", addr, 5*time.Second)
// Go 1.17+ 支持 per-connection keepalive
tcpConn := conn.(*net.TCPConn)
// 通过 SetKeepAlive(true) + SetKeepAlivePeriod(30*time.Second)
// 但 Go 的 SetKeepAlivePeriod 只设 time，intvl/probes 走系统级
tcpConn.SetKeepAlive(true)
tcpConn.SetKeepAlivePeriod(30 * time.Second)

gRPC 侧：

// grpc-go: 通过 WithInitialWindowSize + WithKeepaliveParams
grpc.WithKeepaliveParams(keepalive.ClientParameters{
    Time:                30 * time.Second,  // 空闲 30s 后发 PING
    Timeout:             5 * time.Second,   // PING 5s 无响应 → 断
    PermitWithoutStream: true,              // 没有活跃 stream 也发 PING（关键！）
})

探测开销量化（2 万连接）

每条连接每 30s 空闲后：
  探测包 = 1 个 TCP ACK（64 字节，含 IP/TCP 头）
  ACK 回复 = 1 个 TCP ACK（64 字节）
  单连接探测流量 = 128 字节 / 30s ≈ 34.1 bps

2 万连接（假设 50% 空闲触发探测）：
  10000 × 34.1 bps ≈ 341 kbps ≈ 0.34 Mbps

占 25G 链路比例：0.34 / 25000 = 0.0014%

结论：流量开销完全可以忽略。 真正的开销是 CPU——每个探测包触发一次 softirq 处理，10000 个连接 / 30s = 333 pps 的额外包，对 32C 节点来说 <0.01% CPU。

实测方法：

# 开启前基线
sar -n DEV 1 60 > baseline.txt
# 开启后
sysctl -w net.ipv4.tcp_keepalive_time=30
sysctl -w net.ipv4.tcp_keepalive_intvl=5
sysctl -w net.ipv4.tcp_keepalive_probes=3
# 等 2 分钟（让空闲连接进入探测周期）
sar -n DEV 1 60 > with_keepalive.txt
# 对比：rxpck/s 和 txpck/s 的增量
diff <(awk '{print $4, $5}' baseline.txt) <(awk '{print $4, $5}' with_keepalive.txt)
# 预期：txpck 增量 ≈ 333 pps，rxpck 增量 ≈ 333 pps

2. keepalive vs 应用层心跳：分层防御

| 维度 | TCP keepalive | 应用层心跳（HTTP/2 PING / gRPC PING） | |------|--------------|--------------------------------------| | 检测时延 | 45s（30+5×3） | 5–10s（PING 间隔 10s + 超时 5s） | | 覆盖场景 | 对端内核死亡（断电、panic、网络分区） | 对端进程死亡（OOM、crash、hang） | | 额外流量 | 128B/30s/连接 | 128B–256B/10s/连接（HTTP/2 PING 帧） | | 误判率 | 极低（3 次探测 × 5s 窗口） | 低（但 PING 超时设太短会在 GC 暂停时误判） | | 连接池感知 | 内核断开 → read() 返回 ECONNRESET → 连接池标记 dead | 应用层收到 PING 超时 → 主动 close → 连接池标记 dead | | 对连接池的集成 | 被动（连接被内核断开后才知道） | 主动（可以立即从池里摘除 + 告警） |

推荐组合：

• TCP keepalive（time=30, intvl=5, probes=3）：兜底"对端彻底没响应"
• gRPC PING（Time=15s, Timeout=5s, PermitWithoutStream=true）：兜底"对端进程 hang 了但内核还活着"
• 连接池 idle 探测（见 §3）：兜底"长时间不用但连接还在池里"

三者叠加后，任何 half-open 场景都能在 10–45s 内被识别，而不是等 30–60s 的业务超时。

3. 比裸 keepalive 更省的机制

(a) HTTP/2 PING（gRPC 场景最推荐）

// grpc-go 服务端
server := grpc.NewServer(
    grpc.KeepaliveEnforcementPolicy(keepalive.EnforcementPolicy{
        MinTime:             10 * time.Second, // 客户端 PING 间隔 < 10s 会被 GOAWAY
        PermitWithoutStream: true,
    }),
    grpc.KeepaliveParams(keepalive.ServerParameters{
        Time:                15 * time.Second,
        Timeout:             5 * time.Second,
    }),
)

// 客户端
conn, _ := grpc.Dial(addr,
    grpc.WithTransportCredentials(insecure.NewCredentials()),
    grpc.WithKeepaliveParams(keepalive.ClientParameters{
        Time:                15 * time.Second,
        Timeout:             5 * time.Second,
        PermitWithoutStream: true,  // 关键：没有活跃 RPC 也发 PING
    }),
)

优势：HTTP/2 PING 是 8 字节的帧（比 TCP keepalive 的 64 字节包小 8 倍），且在应用层直接感知——连接池可以立即把这条连接标记为 unhealthy，不用等内核断开。

代价：需要双方都支持 HTTP/2（gRPC 天然支持）。对 HTTP/1.1 连接无效。

(b) 连接池 idle 探测（HikariCP / Lettuce 等）

在连接池层做"借出前活性检查"：

• HikariCP：connectionTestQuery + validationTimeout=2s，或依赖其默认的 isValid() 探测
• Redis 客户端（Lettuce / Jedis）：PING 前置探活，预算 1~2s
• gRPC 客户端：PermitWithoutStream=true 的 PING 帧

关键：借出前活性检查的预算（1~2s）必须 < 业务 read timeout，否则检查本身就把业务超时吃掉了。

4. 踩坑清单（按发生频率排序）

1. 系统级参数被容器运行时覆盖：containerd / CRI-O 升级后 Pod 内 tcp_keepalive_time 回到 7200s 默认值。必须 ss -ti 在 Pod 内验证。
2. T_detect ≥ connectionTimeout：探测和业务超时竞争，keepalive 形同虚设。
3. per-socket 覆盖被应用层篡改：连接池初始化时一次性设置，之后禁止运行时修改。
4. 探测包被对端 WAF drop：nstat -az 看 TcpExtTCPTimeouts 增量，反推探测链路是否断了。
5. SNAT 槽位被 keepalive 占满：高连接数 + 有限 SNAT 池时，keepalive 探测包会挤占新连接的 SNAT 槽位。

5. 一句话总结

TCP keepalive 是兜底，应用层 PING 是主检，连接池 idle 探测是借出前最后一道闸。 三者叠加后，任何 half-open 场景都能在 10–45s 内被识别，而不是等 30–60s 的业务超时。参数预算的核心公式是 T_detect = time + intvl × probes，但参数之间的相对大小关系比绝对值更重要——T_detect < connectionTimeout < 业务 read timeout，这条链断了 keepalive 就形同虚设。