Linux网络编程 - 连接无效：使用 Keep-Alive 还是 应用心跳检测？
从一个例子开始
有一个基于 NATS 消息系统的项目，多个消息的提供者 （pub）和订阅者（sub）都连到 NATS 消息系统，通过这个系统来完成消息的投递和订阅处理。突然有一天，线上报了一个故障，一个流程不能正常处理。经排查，发现消息正确地投递到了 NATS 服务端，但是消息订阅者没有收到该消息，也没能做出处理，导致流程没能进行下去。通过观察消息订阅者后发现，消息订阅者到 NATS 服务端的连接虽然显示是“正常”的，但实际上，这个连接已经是无效的了。
为什么呢？这是因为 NATS 服务器崩溃过，NATS 服务器和消息订阅者之间的连接中断 FIN 包，由于异常情况，没能够正常到达消息订阅者，这样造成的结果就是消息订阅者一直维护着一个“过时的”连接，不会收到 NATS 服务器发送来的消息。
这个故障的根本原因在于，作为 NATS 服务器的客户端，消息订阅者没有及时对连接的有效性进行检测，这样就造成了问题。
TCP Keep-Alive 选项
很多刚接触 TCP 编程的人会惊讶地发现，在没有数据读写的“静默”的连接上，是没有办法发现 TCP 连接是有效还是无效的。比如客户端突然崩溃，服务器端可能在几天内都维护着一个无用的 TCP 连接。前面提到的例子就是这样的一个场景。
那么有没有办法开启类似的“轮询”机制，让 TCP 告诉我们，连接是不是“活着”的呢？这就是 TCP 保持活跃机制所要解决的问题。实际上，TCP 有一个保持活跃的机制叫做 Keep-Alive。
这个机制的原理是这样的：定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
上述的可定义变量，分别被称为保活时间、保活时间间隔和保活探测次数。在 Linux 系统中，这些变量分别对应 sysctl 变量net.ipv4.tcp_keepalive_time、net.ipv4.tcp_keepalive_intvl、 net.ipv4.tcp_keepalve_probes，默认设置是 7200 秒（2 小时）、75 秒和 9 次探测。
如果开启了 TCP 保活，需要考虑以下几种情况：
第一种，对端程序是正常工作的。探测报文正常交互，tcp保活机时间被重置，等待下一个保活时间的到来。
第二种，对端程序崩溃并重启。当 TCP 保活的探测报文发送给对端后，对端是可以响应的，但由于没有该连接的有效信息，会产生一个 RST 报文，这样很快就会发现 TCP 连接已经被重置。
第三种，对端程序崩溃，或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后，石沉大海，没有响应，连续几次，达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。
TCP 保活机制默认是关闭的，当我们选择打开时，可以分别在连接的两个方向上开启，也可以单独在一个方向上开启。如果开启服务器端到客户端的检测，就可以在客户端非正常断连的情况下清除在服务器端保留的“脏数据”；而开启客户端到服务器端的检测，就可以在服务器无响应的情况下，重新发起连接。
为什么 TCP 不提供一个频率很好的保活机制呢？我的理解是早期的网络带宽非常有限，如果提供一个频率很高的保活机制，对有限的带宽是一个比较严重的浪费。
应用层保活
如果使用 TCP 自身的 keep-Alive 机制，在 Linux 系统中，最少需要经过 2 小时 11 分 15 秒才可以发现一个“死亡”连接。这个时间是怎么计算出来的呢？其实是通过 2 小时，加上 75 秒乘以 9 的总和。实际上，对很多对时延要求敏感的系统中，这个时间间隔是不可接受的。
所以，必须在应用程序这一层来寻找更好的解决方案。我们可以通过在应用程序中模拟 TCP Keep-Alive 机制，来完成在应用层的连接探活。比如，我们可以设计一个 PING-PONG 的机制，需要保活的一方，比如客户端，在保活时间达到后，发起对连接的 PING 操作，如果服务器端对 PING 操作有回应，则重新设置保活时间，否则对探测次数进行计数，如果最终探测次数达到了保活探测次数预先设置的值之后，则认为连接已经无效。
这里有两个比较关键的点：第一个是需要使用定时器，这可以通过使用 I/O 复用自身的机制来实现；第二个是需要设计一个 PING-PONG 的协议。下面尝试完成这样的设计。
消息格式设计
我们的程序是客户端来发起保活，为此定义了一个消息对象。这个消息对象是一个结构体，前 4 个字节标识了消息类型，为了简单，这里设计了MSG_PING、MSG_PONG、MSG_TYPE 1和MSG_TYPE 2四种消息类型。
typedef struct {
u_int32_t type;
char data[1024];
} messageObject;
#define MSG_PING 1
#define MSG_PONG 2
#define MSG_TYPE1 11
#define MSG_TYPE2 21客户端程序设计
客户端完全模拟 TCP Keep-Alive 的机制，在保活时间达到后，探活次数增加 1，同时向服务器端发送 PING 格式的消息，此后以预设的保活时间间隔，不断地向服务器端发送 PING 格式的消息。如果能收到服务器端的应答，则结束保活，将保活时间置为 0。这里我们使用 select I/O 复用函数自带的定时器，select 函数将在后面详细介绍。
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MESSAGE_SIZE 10240000
#define MAXLINE 4096
#define KEEP_ALIVE_TIME 10
#define KEEP_ALIVE_INTERVAL 3
#define KEEP_ALIVE_PROBETIMES 3
typedef struct {
u_int32_t type;
char data[1024];
} messageObject;
#define MSG_PING 1
#define MSG_PONG 2
#define MSG_TYPE1 11
#define MSG_TYPE2 21
int main()
{
int sockfd;
int connect_rt;
struct sockaddr_in serv_addr;
sockfd = socket(PF_INET, SOCK_STREAM, 0);
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(7878);
inet_pton(AF_INET, "192.168.133.131", &serv_addr.sin_addr);
connect_rt = connect(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr));
if (connect_rt < 0)
{
fprintf(stderr, "Connect failed !\n");
exit(0);
}
char recv_line[MAXLINE + 1];
int n;
fd_set readmask;
fd_set allreads;
FD_ZERO(&allreads);
FD_SET(sockfd, &allreads); // add sockfd to addreads
struct timeval tv;
int heartbeats = 0;
tv.tv_sec = KEEP_ALIVE_TIME;
tv.tv_usec = 0;
messageObject messageObject;
for(;;)
{
readmask = allreads;
/*
调用 select 函数，感知 I/O 事件。这里的 I/O 事件，除了套接字上的读操作之外，前面设置的超时事件。当 KEEP_ALIVE_TIME 这段时间到达之后，select 函数会返回 0.
*/
if(select(sockfd + 1, &readmask, NULL, NULL, &tv) == 0){
if(++heartbeats > KEEP_ALIVE_PROBETIMES){
printf("connection dead\n");
exit(0);
}
printf("sending heartbeat #%d\n", heartbeats);
messageObject.type = htonl(MSG_PING);
/*
客户端已经在 KEEP_ALIVE_TIME 这段时间内没有收到任何对当前连接的反馈，
于是发起 PING 消息，尝试问服务器端：”喂，你还活着吗？“这里我们通过传送一个类型为 MSG_PING 的消息对象来完成 PING 操作，之后我们会看到服务器端程序如何响应这个 PING 操作
*/
if(send(sockfd, (char*)&messageObject, sizeof(messageObject), 0) < 0)
printf("send failure\n");
tv.tv_sec = KEEP_ALIVE_INTERVAL;
continue;
}
/*
客户端在接收到服务器端程序之后的处理。为了简单，这里就没有再进行报文格式的转换和分析。在实际的工作中，这里其实是需要对报文进行解析后处理的，只有是 PONG 类型的回应，我们才认为是 PING 探活的结果。这里认为既然收到服务器端的报文，那么连接就是正常的，所以会对探活计数器和探活时间都置零，等待下一次探活时间的来临
*/
if(FD_ISSET(sockfd, &readmask))
{
n = read(sockfd, recv_line, MAXLINE);
if(n < 0)
{
fprintf(stderr, "read error\n");
exit(0);
}
else if(n == 0)
{
fprintf(stderr, "server terminated\n");
exit(0);
}
recv_line[n] = 0;
printf("received heartbeat, make heartbeats to 0 \n");
heartbeats = 0;
tv.tv_sec = KEEP_ALIVE_TIME;
}
}
return 0;
} 服务端程序设计
服务器端的程序接受一个参数，这个参数设置的比较大，可以模拟连接没有响应的情况。服务器端程序在接收到客户端发送来的各种消息后，进行处理，其中如果发现是 PING 类型的消息，在休眠一段时间后回复一个 PONG 消息，告诉客户端：”嗯，我还活着。“当然，如果这个休眠时间很长的话，那么客户端就无法快速知道服务器端是否存活，这是我们模拟连接无响应的一个手段而已，实际情况下，应该是系统崩溃，或者网络异常。
#include /* basic system data types */
#include /* basic socket definitions */
#include /* sockaddr_in{} and other Internet defns */
#include /* inet(3) functions */
#include
#include
#include
#include
#include
#include
#include /* for convenience */
static int count;
typedef struct {
u_int32_t type;
char data[1024];
} messageObject;
#define MSG_PING 1
#define MSG_PONG 2
#define MSG_TYPE1 11
#define MSG_TYPE2 21
int main(int argc, char **argv)
{
if (argc != 2) {
fprintf(stderr, "usage: tcpsever \n");
return 0;
}
int sleepingTime = atoi(argv[1]);
int listenfd, connfd;
socklen_t cli_addr_len;
struct sockaddr_in serv_addr, cli_addr;
listenfd = socket(PF_INET, SOCK_STREAM, 0);
bzero(&serv_addr, sizeof(serv_addr));
bzero(&cli_addr, sizeof(cli_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(7878);
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
bind(listenfd, (struct sockaddr*) &serv_addr, sizeof(serv_addr));
listen(listenfd, SOMAXCONN);
connfd = accept(listenfd, (struct sockaddr* )&cli_addr, &cli_addr_len);
messageObject message;
count = 0;
for(;;)
{
int n = read(connfd, (char*) &message, sizeof(messageObject));
if(n < 0)
{
printf("error read\n");
exit(0);
}
else if(n == 0)
{
printf("client closed\n");
exit(0);
}
printf("received %d bytes\n", n);
count ++;
switch (ntohl(message.type)){
case MSG_TYPE1:
printf("process MSG_TYPE1 \n");
break;
case MSG_TYPE2:
printf("process MSG_TYPE2 \n");
break;
case MSG_PING:
{
messageObject pong_message;
pong_message.type = MSG_PONG;
sleep(sleepingTime);
if(send(connfd, (char *) &pong_message, sizeof(pong_message), 0) < 0){
fprintf(stderr, "send failure\n");
exit(0);
}
break;
}
default:
fprintf(stderr, "unknown message type (%d)\n", ntohl(message.type));
exit(0);
}
}
return 0;
} 实验
第一次实验，服务器端休眠时间为 60 秒。
我们看到，客户端在发送了三次心跳检测报文 PING 报文后，判断出连接无效，直接退出了。之所以造成这样的结果，是因为在这段时间内没有接收到来自服务器端的任何 PONG 报文。当然，实际工作的程序，可能需要不一样的处理，比如重新发起连接。
$./tcpclient
sending heartbeat #1
sending heartbeat #2
sending heartbeat #3
connection dead$./tcpserver 60
received 1028 bytes
received 1028 bytes第二次实验，我们让服务器端休眠时间为 5 秒。
我们看到，由于这一次服务器端在心跳检测过程中，及时地进行了响应，客户端一直都会认为连接是正常的。
$./tcpclient
sending heartbeat #1
sending heartbeat #2
received heartbeat, make heartbeats to 0
received heartbeat, make heartbeats to 0
sending heartbeat #1
sending heartbeat #2
received heartbeat, make heartbeats to 0
received heartbeat, make heartbeats to 0
$./tcpserver 5
received 1028 bytes
received 1028 bytes
received 1028 bytes
received 1028 bytes注意，客户端的定时器设定为每10秒钟进行一次select返回0，此时进行探测包发送。而服务器端延迟5秒进行应答，为什么客户端每次都能发送两个包后才清零？不应该是只进行一个包的发送，服务器端延迟5秒就给出应答，然后清零吗？
当客户端10秒钟select超时时间到达，第一次进入heartbeat，发送报文给服务器端，同时客户端把下一次select超时时间设置为3秒(KEEP_ALIVE_INTERVAL)；
由于服务器端是5秒之后才回复，3秒之后，第二次heartbeat时间到，客户端发送第二个heartbeat。5秒之后，第一次的heartbeat回复到，客户端把超时时间又重新设置为10秒。再过5秒之后，第二次的heartbeat回复到，客户端把超时时间再次设置为10秒。
如此反复。
通过今天的文章，我们能看到虽然 TCP 没有提供系统的保活能力，让应用程序可以方便地感知连接的存活，但是，我们可以在应用程序里灵活地建立这种机制。一般来说，这种机制的建立依赖于系统定时器，以及恰当的应用层报文协议。比如，使用心跳包就是这样一种保持 Keep Alive 的机制。
温故而知新 ！