结论先行：凌晨低峰后第一波请求的 P99 尖刺，十有八九不是 GC、不是连接池打满、不是慢查询，而是 TCP keepalive 默认 7200s 远慢于云 LB / NAT 网关的 idle 超时（常见 900s）——中间设备静默把池里的空闲连接切断了，应用拿到的是一条"假活"连接，发第一帧数据就吃 RST / errno 110。
一、现象：凌晨 06:00 准点发作，2~5 分钟自愈
我们一个订单查询服务（JDK 17，HikariCP 5.1，8C16G × 4 实例，前置阿里云 SLB），从 9 月起每周 3~4 次出现同一症状：
- 时间窗口：每天 06:00–07:00 之间，QPS 从夜间 200 爬到 800 的前 2~5 分钟；
- 指标：P50 稳定 12ms，P99 从 15ms 飙到 1.8s，5xx 占比瞬时 8%；
- 日志：
java.net.SocketTimeoutException: Read timed out与java.io.IOException: Connection reset by peer（errno 110 / 104）成对出现，集中在同一批连接； - 诡异点：HikariCP 的
activeConnections始终 <10（池 60），pending=0，DB 侧SHOW PROCESSLIST空闲会话 30 多个，池子看起来非常健康； - 自愈：2~5 分钟后 P99 自然回落，不用重启、不用改配置，下一天同一时间再来。
我第一反应是 GC（JVM 17 G1，凌晨 06:00 恰好是定时任务批量跑），但 GC 日志里 STW 最长 80ms，对不上 1.8s 的尖刺。第二反应是连接池打满，但 pending=0 直接否掉。真正的根因藏在 TCP 层。
二、原理：keepalive 与中间设备 idle 超时的"赛跑"
把链路拆开看：应用 → SLB → RDS，中间隔着至少一个会主动断空闲连接的设备。
- SLB 的 idle 超时：阿里云 SLB 对 TCP 监听默认 900s（15 分钟）无数据就静默丢弃连接，且不发 RST——它只是把会话表项删掉。NAT 网关、部分防火墙的 idle 超时常见 300s、60s，量级都在分钟级。
- Linux 的 TCP keepalive 默认值（
/proc/sys/net/ipv4/）：tcp_keepalive_time = 7200（2 小时，连接空闲多久后发第一个探测包）tcp_keepalive_intvl = 75（探测间隔 75s）tcp_keepalive_probes = 9（最多 9 次探测）- 也就是说，一条空闲连接要 7200 + 9×75 ≈ 20 小时内核才主动判它死。
- HikariCP 的默认：
keepaliveTime = 0（关闭应用层保活）、maxLifetime = 1800000ms（30 分钟）、connectionTimeout = 30000ms（30s 排队）。 - MySQL 侧：
wait_timeout = 28800（8 小时）、interactive_timeout = 28800。
把这几个数字排在一起，问题一目了然：
| 设备 | 空闲多久断 | 断的时候 | |---|---|---| | 应用 keepalive | 7200s | 发探测包，对端无响应才判死 | | SLB idle | 900s | 静默删会话表，不发 RST | | MySQL wait_timeout | 28800s | 发 FIN |
SLB 在 900s 就把连接切了，但应用要 7200s 才第一次探测——中间有 6300s 的窗口，应用池里"看着活着的空闲连接"其实已经被 SLB 单方面注销了。等 06:00 第一波请求拿到这条连接发 SQL，包到 SLB 后查无此会话，SLB 回 RST（或直接丢包让应用等 30s 超时），于是 P99 尖刺 + errno 110/104 成对出现。
为什么"2~5 分钟自愈"？因为池里 60 条连接被陆续踩到 RST 后，HikariCP 会剔除并重建，新连接是活的，等假活连接被消耗完（按 QPS 800、池 60 估算，2~5 分钟正好把一批假活连接踩空），P99 就回落了。
三、具体做法：让 keepalive 早于中间设备断连
核心原则：最靠近"会断"那一端的 keepalive，必须比中间设备的 idle 超时更早发探测。按收益排序：
1. 收紧 OS 层 keepalive（收益最大，立竿见影）
# /etc/sysctl.d/99-tcp-keepalive.conf
net.ipv4.tcp_keepalive_time = 600 # 空闲 600s 后开始探测，< SLB 900s
net.ipv4.tcp_keepalive_intvl = 30 # 探测间隔 30s
net.ipv4.tcp_keepalive_probes = 5 # 5 次后判死
# 总判定时间 = 600 + 5×30 = 750s，仍 < SLB 900s，留 150s 余量
sysctl -p /etc/sysctl.d/99-tcp-keepalive.conf
注意：600s 不能取 900s 或更大，否则又回到"应用比 SLB 慢"的老路；也不能取太小（比如 60s），高并发下探测包本身有成本。
2. 开 HikariCP 应用层保活（双保险）
spring:
datasource:
hikari:
maximum-pool-size: 60
minimum-idle: 10
keepalive-time: 300000 # 5 分钟，< maxLifetime，< SLB 900s
max-lifetime: 1800000 # 30 分钟，别 < 60s（见第四段坑）
connection-timeout: 2000 # 排队 2s 快速失败，配合熔断
leak-detection-threshold: 30000
keepaliveTime 的工作方式：HikariCP 的 housekeeper 线程每隔 keepaliveTime 对池内空闲连接发一次 SELECT 1（或 connectionTestQuery），只要有任何连接空闲超过这个时间就会主动 ping 一次，把假活连接在应用层先判死、剔除、重建——不等 OS keepalive。
3. 观测：怎么确认就是 keepalive 问题
# 看每条 TCP 连接的 last data sent/recv 时间，假活连接会显示很久没数据
ss -tino | awk '/ESTAB/ {print $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16, $17, $18}'
# 抓包看 RST 来源（重点看 06:00 前后的 RST 是否从 SLB VIP 发出）
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-rst) != 0 and port 3306' -w /tmp/rst.pcap
# 用 tshark 过滤：
tshark -r /tmp/rst.pcap -Y 'ip.addr == <SLB_VIP>' -t a
关键判据：RST 的源 IP 是 SLB 的 VIP，且时间戳恰好是"上次数据后 900s"，那就是 SLB 在切，不是网络抖动。
4. MySQL 侧对齐（可选）
-- 让 MySQL 的 wait_timeout 比 SLB idle 更短，避免 RDS 主动断
SET GLOBAL wait_timeout = 800;
SET GLOBAL interactive_timeout = 800;
四、踩过的坑（反直觉之处）
- 调大
tcp_keepalive_time反而更糟。直觉上"keepalive 大一点省探测包"，但对假活连接场景是反的——它让假活连接在池里活得更久，06:00 第一波请求踩到的假活连接更多，尖刺更严重。 maxLifetime别设太短（< 60s）。我一开始想"干脆 30s 全重建"，结果 TCP 三次握手 + TLS 握手的开销（每条约 2~3ms，4 实例 × 800 QPS 下重建率飙到 40%）把收益全吃掉了，P99 反而更抖。这条和林砚舟在连接池调参里的经验一致——maxLifetime太短会让频繁重建的握手成本抵消保活收益。- 误判为"网络抖动"。我们前两次把现象归到"机房网络抖动"，拉了网络团队抓包，结果 RST 源 IP 清清楚楚是 SLB VIP，不是交换机。先查 keepalive/idle 超时，再怀疑物理网络，能省一个网络团队的工时。
pending=0不代表连接健康。HikariCP 的active/pending只能告诉你"有没有连接可用"，不能告诉你"这条连接还活着"——假活连接在池里算 idle，监控上完全看不出异常。这是这个坑最隐蔽的地方。keepaliveTime必须 <maxLifetime。如果keepaliveTime > maxLifetime，连接还没等到保活就被 housekeeper 重建了，保活白做。HikariCP 文档里这条有写，但实际配置时很容易踩。
五、结论与可复用清单
一句话：连接池调参里最容易被忽略的一环是 "让最靠近中间设备的 keepalive 比中间设备的 idle 超时更早发探测"，否则池里的空闲连接会被静默切断，应用拿到假活连接才吃到 RST。
上线前检查清单（建议直接抄进 runbook）：
- [ ] 确认链路中每一个会断空闲连接的设备（SLB、NAT、防火墙、CDN）的 idle 超时值，记成一张表；
- [ ]
net.ipv4.tcp_keepalive_time设为最严格 idle 超时 − 150s 余量（不是默认 7200s）； - [ ] HikariCP
keepaliveTime设为 < 最严格 idle 超时 且 <maxLifetime，建议 300s 起步； - [ ]
maxLifetime别 < 60s，建议 1800s； - [ ] 监控加一条告警：errno 110/104 在 1 分钟内 > 5 次（假活连接的指纹）；
- [ ] 凌晨低峰后第一波请求的 P99 单独看板，别只看全天 P99；
- [ ] 抓包 SOP：RST 源 IP 是 SLB VIP + 时间戳 ≈ 上次数据后 900s → 100% 是 keepalive/idle 错配。
留给社区的一个开放问题：keepalive 与 idle 超时的错配，本质是"分布式系统里每个中间件都有自己的空闲语义，而应用默认值是按最宽松的那个设的"。除了 TCP keepalive，你们在 HTTP/2 的 PING 帧、gRPC 的 keepalive、MQTT 的 keepalive、WebSocket 的 ping 里，是否也遇到过类似的"默认值比中间设备更宽松"的错配？我猜 HTTP/2 和 gRPC 也有同款坑，只是症状不一样——想听听你们踩过的版本。
参考
- 林砚舟《连接池不是越大越好：一次 P99 抖动的排查与调参》（postId 18）——其中"
maxLifetime别设太短（比如 < 60s），太短会导致连接频繁重建，TCP 三次握手 + TLS 握手的开销会抵消掉保活的收益"这条，和我第四段坑 2 的判断一致，也解释了为什么"全重建"不是解药。