Linux下TCP KEEPALIVE未按预期工作：960秒连接状态异常排查

核心结论 #

你看到的960秒连接保持时长并非来自TCP keepalive机制，而是TCP重传超时的总时长——因为你的服务器一直在主动发送数据，导致keepalive根本没被触发。

具体原因拆解 #

1. TCP keepalive的触发条件
   TCP keepalive仅在连接处于完全空闲状态（无任何数据收发）时才会工作：内核会在tcp_keepalive_time指定的空闲时长后，发起keepalive探测包。但你的场景中，服务器持续向客户端发送数据，每次发送都会刷新TCP的空闲计时器，keepalive的计时永远无法到期，自然不会启动探测流程。

2. 960秒的来源
   当客户端断网后，服务器发送的数据无法得到ACK响应，TCP会进入重传流程：

• Linux内核默认通过tcp_retries2参数控制重传次数（默认值为15）；
• 每次重传的间隔（RTO）会按指数退避算法递增（比如1s→2s→4s→8s…）；
• 经过15次重传尝试后，总时长刚好约为960秒，此时内核才会判定连接失效，将状态从ESTABLISHED改为CLOSED。

3. 修改tcp_keepalive_time无效的原因
   该参数仅作用于空闲连接的keepalive触发时机，而你的场景中连接始终有数据发送，处于非空闲状态，因此该参数完全不起作用。

验证与优化方案 #

• 验证keepalive机制：停止服务器主动发送数据，让连接进入空闲状态，此时修改tcp_keepalive_time后，连接会在设定的时长后触发keepalive探测，超时后断开。
• 缩短断网检测时长（针对持续发送场景）：
  • 全局修改：降低tcp_retries2参数值（注意会影响所有TCP连接），执行命令：

    sudo sysctl -w net.ipv4.tcp_retries2=5
    

  • 单连接配置（推荐）：通过setsockopt为当前连接设置TCP_USER_TIMEOUT参数，指定未收到ACK时的总超时时间（单位毫秒），示例代码：

    int timeout = 30000; // 设置为30秒
    if (setsockopt(cfd, SOL_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout)) < 0) {
        perror("ERROR: setsocketopt(), TCP_USER_TIMEOUT");
        exit(0);
    }
    

    该参数生效后，无论连接是否有数据发送，只要在指定时长内未收到ACK，内核就会终止连接。

内容的提问来源于stack exchange，提问作者DarkSoda