c tcp通讯客户端如何判断服务器已断开，常见原因有哪些？

C语言写的TCP客户端判断服务器是否断开，核心思路就一条：不是等recv返回0才算断开，而是要看recv的返回值、errno错误码，再配合TCP Keepalive和应用层心跳机制综合判断。服务器正常关闭、网络断线、服务器断电，这三种情况的表征完全不同，代码处理方式也不一样。

recv函数返回值：第一道信号线

客户端与服务器建立TCP连接后,操作系统会维护这条连接的内核状态，服务器断开连接时，TCP协议栈会收到FIN包或RST包，客户端内核会更新连接状态，recv函数随之返回不同的结果。

加载中

【TCP面试题2】什么是长连接短连接？什么时候会收到RST包？TCP保活机制是什么？

不务正业的IT男

725518115

原视频地址

recv返回0：服务器优雅关闭

服务器进程主动调用close()或进程正常退出，内核会发送FIN包给客户端，此时客户端调用recv函数，返回值为0，表示对端已经完成了数据发送并关闭连接。

int ret = recv(sockfd, buf, sizeof(buf), 0);
if (ret == 0) {
    printf("服务器已正常关闭连接n");
    close(sockfd);
    return -1;
}

这是最理想的情况,但要注意，recv返回0只代表收到了FIN包，不代表网络链路是通的，服务器进程可以正常退出，但网线可能已经断了。

recv返回-1：看errno判断具体状况

recv返回-1时，不能笼统地认为连接断了，需要检查errno的值：

• errno == EINTR：系统调用被信号中断，连接仍然有效，继续调用recv即可
• errno == EAGAIN 或 EWOULDBLOCK：非阻塞模式下暂时没有数据可读，不表示连接断开
• errno == ECONNRESET：服务器发送了RST包，常见于服务器进程崩溃或强制关闭，连接已不可用
• errno == ETIMEDOUT：发送数据超时，长时间未收到对端ACK确认
• errno == ENOTCONN：连接尚未建立或已经被彻底断开

行业共识认为,多数情况下ECONNRESET和ETIMEDOUT可以直接判定连接不可用，其余错误码需要结合连接状态进一步判断。

int ret = recv(sockfd, buf, sizeof(buf), 0);
if (ret < 0) {
    if (errno == EINTR || errno == EAGAIN) {
        // 临时情况，继续等待
        return 0;
    }
    if (errno == ECONNRESET || errno == ETIMEDOUT) {
        printf("服务器连接异常，错误码: %dn", errno);
        close(sockfd);
        return -1;
    }
    // 其他错误码，视业务场景决定是否重试
}

TCP Keepalive参数：内核自带的保活探测

recv返回0能测出服务器优雅关闭,但服务器异常断电、拔网线、网络中间设备故障

这类场景，客户端收不到FIN包，recv会一直阻塞或反复返回EAGAIN，如果不做额外处理，客户端永远不知道连接已经失效。

开启Keepalive的完整配置

TCP协议栈自带SO_KEEPALIVE机制,开启后内核会定时发送探测报文，确认对端是否存活。

int keepalive = 1;
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive));
// 设置探测参数（Linux平台）
int keepidle = 10;      // 连接空闲10秒后开始探测
int keepintvl = 3;      // 探测间隔3秒
int keepcnt = 3;        // 连续3次无响应判定断开
setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle));
setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl));
setsockopt(sockfd, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));

Linux系统默认的tcp_keepalive_time是7200秒,即两个小时才开始第一次探测，对大多数实时性要求高的客户端来说太慢了，必须手动调短。

Keepalive的局限性

Keepalive探测依赖内核自动处理,对应用层透明，但它的探测周期依然偏长，最短也要几秒级别，且只能证明主机网络栈存活，不能证明业务进程健康，服务器网络正常但业务进程卡死，Keepalive判断结果依然是”连接正常”。

所以Keepalive适合做底层兜底,不适合做业务层面的精确判断。tcp客户端掉线检测方案对比中，Keepalive胜在零成本，输在不够精细。

应用层心跳包：最可靠的判断手段

Keepalive是内核级的探测机制,但业务上更常用的是应用层自定义心跳包，客户端定时发送一个特定格式的消息给服务器，服务器收到后回复确认，一段时间内客户端没有收到任何回复，就判定服务器已断开。

心跳包结构设计

typedef struct {
    uint32_t magic;    // 魔数，用于校验合法性，例如0x5A5A5A5A
    uint16_t type;     // 消息类型，例如1表示心跳请求，2表示心跳响应
    uint16_t len;      // 数据长度
    uint32_t seq;      // 序列号，防止乱序
    uint64_t timestamp; // 时间戳
} heartbeat_packet_t;

发送间隔建议设在5秒到15秒之间，具体根据业务场景调整，金融交易系统要求毫秒级故障感知，可以用2秒间隔；普通IoT设备为了省电，30秒或60秒心跳也常见。

超时策略怎么写

心跳超时不能只做一次判断,网络偶尔丢包会造成误判，通常采用连续超时计数方式：

• 连续3次发送心跳未收到响应,判定连接断开
• 累计超时时间 = 心跳间隔 × 连续失败次数，10秒心跳 + 3次失败 = 30秒发现断开
• 一旦收到任何数据（包括非心跳业务数据），重置超时计数

int timeout_count = 0;
const int MAX_TIMEOUT = 3;
while (1) {
    // 发送心跳包
    send_heartbeat(sockfd);
    // 等待响应，超时时间为心跳间隔
    int ret = wait_response(sockfd, HEARTBEAT_INTERVAL);
    if (ret == 0) {
        timeout_count++;
        if (timeout_count >= MAX_TIMEOUT) {
            printf("连续%d次心跳超时，判定服务器已断开n", MAX_TIMEOUT);
            handle_disconnect();
            break;
        }
    } else {
        timeout_count = 0;
    }
}

心跳与业务数据的协调

服务器断开的判断不必完全依赖心跳包,客户端收到业务数据的实时消息，也说明连接是通的，此时应当重置超时计数，反过来，如果心跳响应正常但业务响应异常，说明服务器进程卡死或陷入死循环，这超出了TCP断开的范畴，属于应用层面的故障监测。

服务器异常断电场景怎么处理

服务器突然断电或机房网络故障,既不会有FIN包，也不会有RST包，客户端内核看到的连接状态依然是ESTABLISHED，但实际链路已经断了，此时客户端发送数据会触发TCP重传，直到重传超时才返回ETIMEDOUT。

数据发送失败触发的断开感知

TCP重传机制在底层默默工作,发送数据后收不到ACK，内核会在超时后重传，重传次数耗尽后通知应用层发送失败，这个周期由内核参数tcp_retries2控制，默认情况下可能需要十几分钟才能感知到断线，显然不能接受。

非阻塞模式与多路复用

使用非阻塞socket配合select、poll或epoll，能更及时地感知异常，当连接断开时，select或poll会返回该socket文件描述符的可读事件，此时调用recv读取数据，返回0或-1，即完成判断。

struct pollfd fds[1];
fds[0].fd = sockfd;
fds[0].events = POLLIN | POLLERR | POLLHUP;
int ret = poll(fds, 1, timeout_ms);
if (ret > 0) {
    if (fds[0].revents & (POLLERR | POLLHUP)) {
        // 连接异常或挂断
        handle_disconnect();
    }
    if (fds[0].revents & POLLIN) {
        int n = recv(sockfd, buf, sizeof(buf), 0);
        if (n <= 0) {
            handle_disconnect();
        }
    }
}

poll的返回能覆盖对方关闭、网络错误、连接挂断等多种异常场景，实际项目中，多路复用加应用层心跳是配置中最稳的组合，前者负责及时触发事件，后者负责确认业务层面的健康程度。

把判断逻辑封装成可复用的检测模块

无论用哪种方案,这些逻辑都不应该散落在业务代码里，建议封装一个连接状态检测工具函数，统一处理recv返回值、Keepalive参数构造、心跳定时器以及超时后的清理动作，比如做一款C语言实现的tcp客户端代码，拆成conn_init、conn_send、conn_recv、conn_check_alive几个函数，调用方只需要在主循环里调用check_alive，就能周期性获得连接状态，这样也方便在后期把非阻塞IO和心跳间隔调整成配置参数，无需改动业务层。

客户端重连与资源回收

确定服务器断开后,客户端需要做的事情不止是打印一句日志，要立即关闭旧的socket文件描述符，释放所有与该连接关联的内存缓冲区，然后按策略执行重连，遇到服务器短时间内重启的情况，重试次数要设置上限，避免无限循环消耗CPU。

void handle_disconnect() {
    printf("连接断开，执行清理流程n");
    close(sockfd);
    free(recv_buf);
    free(send_buf);
    reconnect_with_backoff(); // 指数退避重连
}

tcp客户端怎么判断服务器已断开：常见疑问解答

客户端阻塞在recv上，服务器断了会怎么样

阻塞模式下服务器断电,客户端recv会一直阻塞下去，永远不返回，必须配合select或poll设置超时时间，或者改用非阻塞模式加心跳，否则套接字永远不会感知对端丢失。

虚连接是什么意思，为什么客户端无法感知

所谓虚连接就是客户端和服务器的IP、端口都还在，但中间的交换机路由器已经故障或断电，连接双方都不知道对方不可达，TCP连接依然显示为ESTABLISHED，只有发送数据并等待ACK超时，或者通过Keepalive探测，才能识别出这条连接是虚的。

心跳包和Keepalive同时开启会不会冲突

不会冲突,Keepalive是内核级探测，心跳是应用层逻辑，两者独立运行，各司其职，Keepalive解决了系统内核层面的半开连接识别，心跳解决了业务层面的故障感知，双管齐下是最稳妥的方案。