当socket服务器中断客户端连接时，无论原因是服务端主动断开还是网络异常掉线，核心处理逻辑只有一条：服务端先区分“对方主动关”和“被动掉线”，再决定是清理资源还是走重连流程；客户端则必须依赖心跳和超时机制，不能傻等TCP通知。
socket服务器连接中断后，先分清主动关闭还是被动掉线
处理中断的第一步不是急着close,而是搞清楚断开的性质，很多初级程序员一看到recv返回0就随手close，结果把业务事务和连接上下文一起丢掉，留下悬空指针和未回滚的数据。
正常关闭的特征
- 客户端主动调用close,或者发送FIN包。
- 服务端调用recv或read时返回0。
- 此时服务端仍然可以往客户端发送数据,因为TCP是双向通道，客户端可能只关了写方向。
异常掉线的特征
- 客户端崩溃、断电、网线被拔，服务端收不到FIN。
- 如果中间路由器发来ICMP错误,服务端recv会返回-1，errno为ECONNRESET。
- 如果只是长时间没数据,可能返回-1且errno为ETIMEDOUT，或者一直阻塞。
判断代码模板
n = recv(fd, buf, sizeof(buf), 0);
if (n == 0) {
// 客户端主动关闭，走业务清理流程
} else if (n < 0) {
if (errno == EAGAIN || errno == EWOULDBLOCK) {
// 非阻塞下没有数据，正常
} else if (errno == ECONNRESET) {
// 对端异常重置，按掉线处理
} else {
// 其他网络错误，同样按掉线处理
}
}
服务端主动断开客户端的正确姿势
服务端因为超时、违规或运维需求主动断开连接，和被动处理掉线完全是两码事，主动断开要尽量让客户端“死得明白”，同时不能让自己留下TIME_WAIT堆积。
主动断开前先发原因码
如果业务允许,先向客户端发送一个自定义结构体，包含断开原因码和说明字段，认证过期”或“系统维护”，然后单独flush一次发送缓冲，最后再close，这样做的好处是客户端能区分“被踢”和“网络故障”，避免无脑重连导致风暴。
shutdown和close的选择
- shutdown(fd, SHUT_WR)只关闭发送方向，接收方向仍然打开，可以继续读客户端最后传过来的数据。
- close会立即释放fd,如果接收缓冲里还有未读数据，TCP会发送RST，可能导致客户端收到ECONNRESET而不是正常EOF。
- 如果不想让客户端误会,应该先shutdown(SHUT_RD)告诉对方自己不再接收数据，再close。
设置SO_LINGER避免TIME_WAIT堆积
行业共识认为,频繁主动断开连接时，如果不调整LINGER行为，服务端会产生大量TIME_WAIT socket，占用本地端口和内存，设置linger为0可以让close立即发送RST，跳过TIME_WAIT，但代价是可能丢失未发送的数据。
struct linger so_linger; so_linger.l_onoff = 1; so_linger.l_linger = 0; setsockopt(fd, SOL_SOCKET, SO_LINGER, &so_linger, sizeof(so_linger)); close(fd);
如果业务不能丢数据,就不要用0，而是设置一个较长的linger值，让close在超时前尝试把缓冲数据发完。
socket客户端掉线检测：靠心跳，别靠TCP keepalive
TCP本身的keepalive默认间隔是2小时,对绝大多数在线应用来说等于没有，所以应用层必须有心跳机制，否则服务端根本不知道客户端已经掉线，客户端也不知道服务器是否还活着。
心跳包怎么设计
- 频率：10到30秒一次，根据业务容忍度调整，比如游戏要求秒级感知，可以3秒发一次。
- 超时次数：连续3次没收到心跳，判定连接已死，固定长度的结构体，包含魔数、序列号、时间戳，不要带业务数据，避免解析复杂。
心跳与业务请求复用
如果业务本身每秒都有请求,可以不用单独发心跳，直接用业务数据充当活跃证明，只有长时间空闲的连接才需要专门心跳。
客户端如何应对服务器中断
- 读操作返回0,说明服务器主动关闭，此时进入“重连等待”状态，不要立刻重连。
- 心跳超时,说明网络可能断了，同样进入退避重试。
- 重连成功后,客户端要重新登录或恢复会话，不能直接当新连接处理。
socket客户端掉线重连方案：指数退避是标准答案
客户端发现服务器中断后,最忌讳的是每秒重连一次，把服务器打崩，最稳妥的做法是采用指数退避重试。
退避策略示例
- 第一次重连等待1秒。
- 第二次等待2秒。
- 第三次等待4秒,持续翻倍。
- 设置上限30秒或60秒,之后保持固定频率重试。
- 连续重试超过10次,则通知上层用户或记录日志，而不是无限循环。
重连后的状态同步
重连成功不代表万事大吉,客户端必须和服务端做一次“对账”，比如重新发送登录凭证、恢复订阅频道、拉取断线期间的消息，这一步如果省略，会出现客户端以为自己在线上，其实服务端已经把他完全删除的情况。
linux下socket服务器判断客户端掉线的实操流程
在linux环境用epoll处理socket时,判断掉线和清理资源有固定的步骤，少一步都可能内存泄漏或fd泄漏。
epoll事件触发后的处理顺序
- 调用recv读取数据,判断返回值。
- 如果返回0或ECONNRESET,进入断开处理流程。
- 先从epoll中删除该fd,调用epoll_ctl(fd, EPOLL_CTL_DEL, …)。
- 将连接对应的业务上下文标记为“结束”，触发事务回滚或消息补偿。
- 关闭fd,并将该连接对应的指针置空。
- 记录断线日志,包含时间、IP、端口、最后活跃时间、断开原因。
不要忽略EPOLLERR和EPOLLHUP
epoll事件中如果遇到EPOLLERR或EPOLLHUP,即使recv没有返回0，也要按掉线处理，否则会一直触发事件空转，占用CPU。
批量断开的处理
如果服务器同时断开大量连接,比如网线被交换机整体拔掉，短时间内会涌入大量清理操作，这时不要在每个事件回调里做数据库重连等重操作，而应该把清理任务丢进异步队列，由后台线程慢慢消化，同时限制单次处理断开连接的数量，避免事件循环被拖慢。
socket服务器中断客户端相关问答
问题1：服务端直接close，客户端能立刻感知到吗？
不能立刻感知,如果网络正常，客户端会收到FIN，recv返回0；如果网络异常，FIN可能丢失，客户端只能通过心跳超时才感知到，所以不能依赖close通知，客户端必须设置读超时或心跳检测。
问题2：shutdown和close同时用会怎样？
shutdown只改变TCP连接状态,不释放fd；close才是真正释放fd，事务中如果先shutdown(SHUT_WR)，再close，是安全的，因为close会关闭所有方向，但如果只close不shutdown，接收缓冲未读的数据会导致RST，对端可能收到异常，正确做法是先shutdown再close，确保发送队列里的数据有机会被处理。
问题3：服务器主动踢掉客户端后，客户端重连马上成功，但又被踢掉，循环怎么办？
客户端需要检查服务端返回的断开原因码,如果原因码是“认证失败”或“版本过低”，继续重连没有意义，此时应该停止自动重连，提示用户重新登录或升级版本，只有原因码为“系统维护”“临时踢出”等可恢复原因，才使用退避重试策略。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795730.html
