linux下kernel关于keepalive参数解析

Posted on Edited on Views:

三个 tcp_keepalive 参数，是 Linux 内核 TCP 层用来维持 长连接健康性检测 的设置。

1. TCP Keepalive 内核参数

这些参数在 /proc/sys/net/ipv4/ 下可以查看：

参数 说明 默认值（典型） 单位
tcp_keepalive_time 空闲多少秒后开始发送 keepalive 探测包 7200 秒（2 小时）
tcp_keepalive_intvl 探测包间隔 75 秒
tcp_keepalive_probes 最大探测次数，未响应就断开 9 次

解释：

  • 空闲 7200 秒 → 如果 TCP 连接 2 小时没有任何数据，内核才开始发送 keepalive 探测包。
  • 每 75 秒发一次探测包 → 共发 9 次，如果都没响应，内核认为连接断开。
  • 最终最大空闲时间：7200 + 75*9 = 7875 秒 ≈ 2.2 小时

2. 查看当前值

1
2
3
cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes

或者使用 sysctl：

1
2
3
sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

3. 临时修改

1
2
3
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=60
sysctl -w net.ipv4.tcp_keepalive_probes=5
  • 这里设置空闲 10 分钟就开始检测，每 60 秒探测一次，最多探测 5 次。
  • 注意：这些是 TCP 层全局参数，HTTP Keep-Alive 超时（Sanic 的 KEEP_ALIVE_TIMEOUT）通常更短，一般 5~10 秒，用于短连接优化。

HTTP keep-alive vs TCP keep-alive 时间对比表

2025-09-01\_00-17-19.png

4.加快检测keepalive参数

参数 默认值 (CentOS7 / Linux 通常) 你设置的值 含义
net.ipv4.tcp_keepalive_time 7200 s (2 小时) 300 s (5 分钟) TCP 空闲多久开始发送 keepalive 探测包。也就是如果连接 5 分钟没任何数据，会开始检测对端是否可达。
net.ipv4.tcp_keepalive_intvl 75 s 60 s 每次 keepalive 探测包失败后的间隔时间，即每 60 秒再发一次探测包。
net.ipv4.tcp_keepalive_probes 9 5 最大探测次数。如果连续 5 次未收到 ACK，则认为连接不可达，内核会触发连接关闭。

5.修改后的效果

  1. 更快发现死连接 / 掉线客户端

    • 默认 2 小时才开始探测，很多长连接如果中途客户端掉线或网络异常，服务器可能 保持死连接长达 2 小时。
    • 改成 5 分钟后开始探测，能够在较短时间内发现异常连接，并释放资源。

  2. 减少 TCP 连接资源占用

    • 长时间不活动的死连接会占用 文件描述符、内存和 socket buffer。
    • 提前探测 + 少次数失败后关闭，可以及时释放资源，适合 高并发长连接场景（如 SSH 隧道、WebSocket、数据库连接池）。

  3. 对高可用或心跳场景有提升

    • SSH 隧道、VPN、WebSocket、数据库连接等，如果网络中断，系统会 更快感知并触发重连逻辑。

6.注意事项

  • 探测过于频繁可能增加网络开销
    在大量短连接或超高并发环境下，每 5 分钟/60 秒发送探测包，虽然开销不大，但如果连接数成万级别，需要关注 CPU/网络开销。

  • 应用层心跳可能更灵活
    对于业务关键连接（如 MySQL/Redis/HTTP2/WebSocket），可以在应用层加心跳，比依赖内核 TCP keepalive 更可控。

  • 老设备 / 防火墙可能丢包
    某些网络中间件会丢掉 TCP keepalive 包，如果探测次数太少或间隔太短，可能误判连接掉线。

✅ 总结：

你的配置相比默认值：

  • 原本 2 小时才开始探测 → 现在 5 分钟开始；
  • 原本每次间隔 75 秒探测 → 现在 60 秒探测一次；
  • 原本探测 9 次才断 → 现在 5 次就断。

实际效果：

  • 更快释放死连接
  • 减少资源占用
  • 提高长连接场景的可靠性和及时性

适合 高并发长连接或对掉线敏感的服务。