SO_KEEPALIVE对NAT/防火墙静默断连无效，因其默认2小时才发首探针，而网关通常60–300秒即清除会话表；需应用层心跳：发1字节有效载荷、非阻塞socket、独立IO调度、显式超时判定、双向主动清理。
为什么SO_KEEPALIVE对NAT/防火墙静默断连无效
系统级 SO_KEEPALIVE 默认 2 小时才发第一个探测包，且探测间隔不可控；而多数家用路由器、企业级 NAT 网关或云负载均衡器（如 AWS ALB、阿里云 SLB）会在连接空闲 60–300 秒后直接删掉转发表项——此时 TCP 栈仍认为连接“活着”，send() 不报错，recv() 也阻塞等待，直到业务超时才发现异常。这不是丢包，是中间设备单方面“失忆”。
心跳包必须带有效载荷且独立于业务 IO 调度
常见错误是用 send(fd, nullptr, 0, 0) 或 send(fd, "", 0, 0) 发空包：这在 Linux 上返回 0，但不触发任何 TCP 数据帧，网关收不到，自然不会刷新会话表。必须发送至少 1 字节明确内容：
-
char hb = 0x01;或const char* hb = "P";，用send(fd, &hb, 1, MSG_NOSIGNAL) - socket 必须设为非阻塞：
fcntl(fd, F_SETFL, O_NONBLOCK)，否则send()可能卡死（尤其在拥塞或对端崩溃时） - 心跳的
send()和等待recv()响应不能混在业务读循环里——否则业务数据一来，心跳超时逻辑就漏判。要用select()或epoll_wait()统一监听可读事件，收到数据先检查是否是"PONG"，再处理业务包
超时判定要区分“没响应”和“连接已断”
只等 recv() 返回 0（对端关闭）或 -1 是不够的。中间设备静默断连时，你发完心跳后调 recv()，很可能得到 EAGAIN 或 EWOULDBLOCK（无数据），而不是错误。所以必须配合显式超时：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用
setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv))设置接收超时，比如 5 秒 - 连续 3 次心跳发出后，在超时窗口内未收到匹配的
"PONG"响应（注意校验序列号或时间戳，防重放），才判定假死 - 若
recv()返回 -1 且errno == ECONNRESET或EPIPE，说明对方已发 FIN/RST，立刻清理，无需等满 3 次
服务端也要主动踢掉长期无心跳的客户端
客户端靠心跳保活，服务端不能被动等——否则大量僵尸连接堆积，耗尽文件描述符。服务端需为每个连接维护一个最后心跳时间戳：
立即学习“C++免费学习笔记（深入）”；
- 每次收到合法
"PING"包，更新该连接的last_heartbeat_time - 另起一个轻量定时器（如每 10 秒扫一次），对每个连接计算
now - last_heartbeat_time - 若差值 > 90 秒（建议设为客户端心跳间隔 × 3），则
shutdown(fd, SHUT_RDWR)后close(fd)，并从连接池中移除 - 别忘了清空关联的 session 缓存、定时器对象、重连状态标记——这些漏掉会导致内存泄漏或下次重连失败
真正难的不是发包，是在业务流量起伏时准确区分“暂时没数据”和“连接已断”。心跳计时器必须和业务收发完全解耦，且所有超时判断都基于单调时钟（std::chrono::steady_clock），否则系统时间被 NTP 调整一次，整个保活逻辑就乱套。
