21、心跳检测与保活：TCP keepalive机制、应用层心跳包设计

做网络编程这么多年，我遇到过最头疼的问题之一，就是连接“假死”。

什么叫假死？就是客户端和服务端之间的TCP连接，看起来还连着（文件描述符没关，没报错），但实际上数据已经发不过去了。你发个请求过去，对方没反应，你也不知道是对方挂了，还是网络断了，还是只是暂时卡顿。

嗯，这个问题，说白了就是——TCP本身不会主动告诉你连接断了。除非你发数据，然后收不到ACK，重试几次后才会报错。但如果你一直不发数据，那这个连接就会一直“活着”，哪怕对端已经宕机了。

所以，我们需要两种手段来解决这个问题：TCP keepalive机制和应用层心跳包。今天我就把这两个东西掰开揉碎了讲清楚。

一、TCP keepalive：操作系统自带的“探针”

TCP协议栈里其实内置了一个保活机制，叫keepalive。它的原理很简单：

如果连接在指定时间内没有数据交换，内核会自动发送一个空的探测报文（ACK包，seq号为上一个包减1）。如果对端正常，会回复一个ACK；如果对端挂了，会回复RST；如果网络不通，超时后会重试几次，最终判定连接断开。

我个人习惯，在写服务端程序时，一定会开启这个选项。尤其是做长连接服务的时候，不开启keepalive，连接池里会堆满死连接，白白浪费资源。

我曾经在一个物联网项目中，设备端和服务器保持长连接。默认keepalive参数没改，结果设备断电后，服务器上那个连接还挂了整整两个小时才释放。那段时间，服务器连接数一直在涨，最后把端口资源耗尽了。嗯，从那以后，我写服务端代码第一件事就是调小keepalive参数。

代码示例：开启TCP keepalive

#include <sys/socket.h>
#include <netinet/tcp.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>

int set_tcp_keepalive(int fd) {
    int keepalive = 1;
    int keepidle = 30;      // 空闲30秒后开始探测
    int keepintvl = 5;      // 探测间隔5秒
    int keepcnt = 3;        // 失败3次后断开

    // 开启keepalive
    if (setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &keepalive, sizeof(keepalive)) < 0) {
        perror("setsockopt SO_KEEPALIVE");
        return -1;
    }

    // 设置空闲时间（仅Linux支持）
    if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle)) < 0) {
        perror("setsockopt TCP_KEEPIDLE");
        return -1;
    }

    // 设置探测间隔
    if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl)) < 0) {
        perror("setsockopt TCP_KEEPINTVL");
        return -1;
    }

    // 设置探测次数
    if (setsockopt(fd, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt)) < 0) {
        perror("setsockopt TCP_KEEPCNT");
        return -1;
    }

    return 0;
}

// 使用示例
int main() {
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd < 0) {
        perror("socket");
        return 1;
    }

    if (set_tcp_keepalive(sockfd) < 0) {
        close(sockfd);
        return 1;
    }

    // 继续连接、读写操作...
    printf("TCP keepalive 已开启，空闲30秒后开始探测\n");

    close(sockfd);
    return 0;
}

二、应用层心跳包：更灵活、更可控

TCP keepalive虽然好用，但有个硬伤——它只能检测TCP层的连通性。你想想看，如果对端程序卡死了（比如死循环、死锁），但操作系统还在，TCP keepalive探测时操作系统会回复ACK，你这边就以为连接正常。但实际上，业务逻辑已经跑不动了。

所以，真正靠谱的做法是——在应用层自己实现心跳包。

说白了，就是客户端和服务端约定好，每隔一段时间互相发一个特殊的数据包。如果连续几次没收到对方的心跳回复，就认为连接已失效。

心跳包设计要点

• 协议格式：心跳包要能跟普通业务数据区分开。我一般用一个固定的消息类型ID，比如0x00表示心跳请求，0x01表示心跳回复。
• 发送间隔：太频繁浪费带宽，太慢不灵敏。我个人习惯设5~10秒，具体看业务场景。
• 超时次数：连续3~5次没收到回复，就判定连接断开。
• 双向还是单向：大部分场景是客户端发心跳，服务端回复。但有些场景需要双向心跳，比如P2P通信。

代码示例：简单的心跳包实现

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <errno.h>

// 定义心跳消息类型
#define MSG_HEARTBEAT_REQ  0x00
#define MSG_HEARTBEAT_RESP 0x01

// 消息头结构
typedef struct {
    uint8_t  type;      // 消息类型
    uint32_t length;    // 消息体长度
} msg_header_t;

// 心跳状态
typedef struct {
    int         fd;
    time_t      last_recv;      // 上次收到心跳回复的时间
    int         missed_count;   // 连续未收到回复的次数
    int         max_missed;     // 最大允许丢失次数
    int         interval;       // 心跳发送间隔（秒）
} heartbeat_ctx_t;

// 发送心跳请求
int send_heartbeat_req(int fd) {
    msg_header_t header;
    header.type = MSG_HEARTBEAT_REQ;
    header.length = 0;  // 心跳包没有消息体

    ssize_t n = send(fd, &header, sizeof(header), 0);
    if (n < 0) {
        return -1;
    }
    return 0;
}

// 发送心跳回复
int send_heartbeat_resp(int fd) {
    msg_header_t header;
    header.type = MSG_HEARTBEAT_RESP;
    header.length = 0;

    ssize_t n = send(fd, &header, sizeof(header), 0);
    if (n < 0) {
        return -1;
    }
    return 0;
}

// 处理收到的心跳消息
int handle_heartbeat_msg(int fd, msg_header_t *header) {
    if (header->type == MSG_HEARTBEAT_REQ) {
        // 收到心跳请求，回复心跳回复
        return send_heartbeat_resp(fd);
    } else if (header->type == MSG_HEARTBEAT_RESP) {
        // 收到心跳回复，更新状态
        // 这个由调用方处理，这里只返回成功
        return 0;
    }
    return -1;  // 不是心跳消息
}

// 心跳检测主循环（客户端侧）
void heartbeat_loop(heartbeat_ctx_t *ctx) {
    time_t now = time(NULL);

    // 检查是否该发送心跳
    if (now - ctx->last_recv >= ctx->interval) {
        if (send_heartbeat_req(ctx->fd) < 0) {
            printf("发送心跳失败，连接可能已断开\n");
            ctx->missed_count++;
        } else {
            printf("发送心跳请求\n");
        }
        ctx->last_recv = now;
    }

    // 检查是否超时
    if (ctx->missed_count >= ctx->max_missed) {
        printf("心跳超时，连接断开\n");
        // 关闭连接，触发重连逻辑
        close(ctx->fd);
        ctx->fd = -1;
    }
}

// 初始化心跳上下文
void init_heartbeat(heartbeat_ctx_t *ctx, int fd) {
    ctx->fd = fd;
    ctx->last_recv = time(NULL);
    ctx->missed_count = 0;
    ctx->max_missed = 3;      // 连续3次未收到回复就断开
    ctx->interval = 5;        // 每5秒发一次心跳
}

int main() {
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);
    // ... 连接服务器代码省略 ...

    heartbeat_ctx_t hb_ctx;
    init_heartbeat(&hb_ctx, sockfd);

    // 主循环
    while (1) {
        // 处理网络事件（select/poll/epoll）
        // 这里简化，只演示心跳逻辑

        // 每次循环调用心跳检测
        heartbeat_loop(&hb_ctx);

        if (hb_ctx.fd < 0) {
            printf("连接已断开，尝试重连...\n");
            // 重连逻辑
            break;
        }

        sleep(1);  // 实际项目中用事件驱动，不要sleep
    }

    return 0;
}

三、TCP keepalive vs 应用层心跳：怎么选？

你可能会问，既然TCP keepalive是内核实现的，性能更好，为什么还要自己搞应用层心跳？

我的建议是：两者都用，各司其职。

对比项	TCP keepalive	应用层心跳
检测范围	TCP层连通性	应用层可达性（包括业务逻辑是否正常）
灵活性	低，参数由系统控制	高，可自定义协议、间隔、超时策略
性能开销	极低，内核处理	较低，但需要应用层处理
跨平台	参数设置API不同	纯应用层，完全跨平台
适用场景	清理死连接，释放资源	业务层健康检查、重连触发

我个人习惯的做法是：

• 服务端开启TCP keepalive，参数调小（比如30秒空闲开始探测），用来清理那些“半死不活”的连接。
• 客户端实现应用层心跳，用来检测服务端是否正常工作，以及触发重连。

这样，TCP keepalive兜底，应用层心跳做精细控制，两不耽误。

四、SVG流程图：心跳检测整体架构

五、避坑指南与最佳实践

做心跳检测，有几个坑我踩过，今天一并说出来：

• 不要只依赖TCP keepalive：我曾经在一个金融项目中，只开了keepalive，结果服务端进程死锁了，但操作系统还在，keepalive探测一直成功，客户端完全不知道服务端已经不能处理业务了。后来加了应用层心跳才解决。
• 心跳包不要太大：有些新手把心跳包设计得很复杂，带各种状态信息。其实心跳包越简单越好，一个消息类型ID就够了。我见过有人把整个配置信息塞进心跳包，每次心跳发几KB数据，纯属浪费带宽。
• 注意心跳和业务数据的互斥：如果刚发完业务数据，紧接着又发心跳，其实没必要。我一般会在发送业务数据后重置心跳计时器，避免不必要的网络开销。
• 服务端也要做心跳检测：很多人的设计是客户端发心跳，服务端只回复。但服务端也需要知道客户端是否还活着。我建议服务端也维护一个“最后活跃时间”，如果超过一定时间没收到任何数据（包括心跳），就主动断开连接。

好了，关于心跳检测和保活，核心内容就这些。记住一句话：TCP keepalive保底，应用层心跳保业务。两者配合使用，才能让你的网络程序真正健壮。

---

公众号:蓝海资料掘金营，微信deep3321