ECONNRESET 表示对端已强制终止连接，服务端 recv() 返回 -1 且 errno 为 104 时必须立即关闭 socket、清理上下文并移除 epoll 监听，不可重试或忽略。
服务端 recv() 返回 -1 且 errno == ECONNRESET 怎么办
这不是“优雅”的问题，而是必须立即处理的连接异常。Linux 下客户端主动发 RST（比如进程崩溃、close() 前强制退出、或调用 shutdown(SHUT_RDWR) 后立刻终止），服务端在下一次 recv() 时会返回 -1，并把 errno 设为 ECONNRESET。此时连接已不可用，继续读写会触发 Broken pipe 或直接失败。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每次
recv()后必须检查返回值：小于 0 时立刻检查errno，若为ECONNRESET，应立即关闭对应 socket fd，并清理该连接的所有上下文（如 session 对象、buffer 缓存、定时器） - 不要试图“重试”或“忽略”，RST 表示对端已彻底放弃连接，TCP 层已清空状态，再调用
send()会直接触发SIGPIPE（除非你屏蔽了它）或返回 -1 +errno == EPIPE - 如果你用的是 epoll，记得在清理 fd 后调用
epoll_ctl(EPOLL_CTL_DEL)移除监听，否则可能触发后续epoll_wait()返回过期事件
为什么 SO_KEEPALIVE 不能提前发现 RST 场景
SO_KEEPALIVE 的探测机制是被动的、低频的（默认 2 小时无数据才发 keepalive 包），而 RST 往往发生在连接刚断开的瞬间。它对“客户端突然掉线但没发 FIN”的场景有效，但对明确发 RST 的情况，服务端只有在下次系统调用（如 recv()、send()）时才能感知。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 别依赖
SO_KEEPALIVE来规避ECONNRESET处理逻辑——它不解决“收到 RST 后怎么收场”，只可能延后暴露时间 - 若需更快感知断连，可自建应用层心跳（例如每 30 秒
send()一个轻量 ping 包），并在超时未收到 pong 时主动 close；但注意：即使心跳包发出去了，对方 RST 仍可能在任意时刻到达，recv()还是得检查ECONNRESET - 设置
SO_KEEPALIVE参数（如TCP_KEEPIDLE）需通过setsockopt()配合TCP_*选项，仅设SO_KEEPALIVE不足以缩短探测间隔
多线程/IO 复用模型下如何安全清理 RST 连接资源
问题不在“怎么判断 RST”，而在“判断后谁来清理”。如果 recv() 发生在 worker 线程，但连接资源（如连接池对象、统计计数器）由主线程或另一模块管理，直接 delete 或 close 可能引发竞态或 use-after-free。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 采用“延迟清理 + 标记机制”：worker 线程检测到
ECONNRESET后，仅将该连接 fd 或 session id 推入一个无锁队列（如moodycamel::ConcurrentQueue），由专用 cleanup 线程批量处理 - 避免在信号处理函数里做清理——
SIGPIPE可被屏蔽，但ECONNRESET是同步错误，无需也不该用信号捕获 - 如果使用
libuv或boost.asio，它们的async_read在底层出错时会回调 error_code，其中errc::connection_reset对应ECONNRESET，此时应调用socket.close()并确保 handler 不再访问已销毁的绑定对象
为什么 send() 有时不报错，但之后的 recv() 才暴露 RST
因为 TCP 允许“半关闭”和发送缓冲区滞留。客户端发 RST 后，服务端的 send() 可能成功（数据进入本机协议栈发送队列），但下一次 recv() 会立刻失败并置 errno = ECONNRESET。这是正常行为，不是 bug。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 永远不要假设
send()成功就代表对端还活着；真正的连接健康状态只能靠recv()或心跳响应确认 - 若业务要求强可靠性（如金融指令），应在
send()后等待对端 ACK 的业务级应答，而非依赖 TCP 层状态 - 启用
TCP_NODELAY可减少 Nagle 算法导致的延迟，但它不影响 RST 的感知时机——RST 的暴露始终绑定在下一个阻塞式系统调用上
真正容易被忽略的点是：RST 不是网络丢包，也不是超时，它是对端 TCP 栈发出的明确终止信号。处理它的关键不是技巧，而是接受“连接已死”的事实，并确保所有相关资源（内存、fd、定时器、日志句柄）在同一个逻辑路径中被释放。任何绕过 errno 检查、或把 RST 当作普通错误重试的做法，都会让服务在连接风暴中泄漏资源或卡死。
