心跳

最新推荐文章于 2024-09-15 17:06:41 发布

lwj~

最新推荐文章于 2024-09-15 17:06:41 发布

阅读量232

点赞数

分类专栏：网络编程

本文链接：https://blog.csdn.net/qq_41754573/article/details/103447653

版权

网络编程专栏收录该内容

29 篇文章 1 订阅

订阅专栏

保持对连接有效性的检测

TCP Keep-Alive 选项

TCP的keepalive是侧重在保持客户端和服务端的连接，一方会不定期发送心跳包给另一方，当一方端掉的时候，没有断掉的定时发送几次心跳包，如果间隔发送几次，对方都返回的是RST，而不是ACK，那么就释放当前链接。设想一下，如果tcp层没有keepalive的机制，一旦一方断开连接却没有发送FIN给另外一方的话，那么另外一方会一直以为这个连接还是存活的，几天，几月。那么这对服务器资源的影响是很大的。

原理

TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡。
上述的可定义变量，分别被称为保活时间、保活时间间隔和保活探测次数。在 Linux 系统中，这些变量分别对应 sysctl 变量

net.ipv4.tcp_keepalive_time、默认设置是 7200 秒（2 小时）、
net.ipv4.tcp_keepalive_intvl、 75 秒
net.ipv4.tcp_keepalve_probes， 9 次探测。

如果开启了 TCP 保活，需要考虑以下几种情况：

第一种，当 TCP 保活的探测报文发送给对端, 对端会正常响应，这样 TCP 保活时间会被重置。
第二种，对端程序崩溃并重启。对端会产生一个 RST 报文，这样很快就会发现 TCP 连接已经被重置。
第三种，是对端程序崩溃，或其他原因导致报文不可达，连续几次达到保活探测次数后，TCP 会报告该 TCP 连接已经死亡。

TCP 保活机制默认是关闭的，当我们选择打开时，可以分别在连接的两个方向上开启，也可以单独在一个方向上开启。如果开启服务器端到客户端的检测，就可以在客户端非正常断连的情况下清除在服务器端保留的“脏数据”；而开启客户端到服务器端的检测，就可以在服务器无响应的情况下，重新发起连接。

1.应用层探活

为什么这么做？

eepalive只能检测连接是否存活，不能检测连接是否可用。例如，某一方发生了死锁，无法在连接上进行任何读写操作，但是操作系统仍然可以响应网络层keepalive包。
TCP keepalive 机制依赖于操作系统的实现,灵活性不够，默认关闭，且默认的 keepalive 心跳时间是两个小时, 时间较长。
代理(如socks proxy)、或者负载均衡器，会让tcp keep-alive失效
基于此，我们往往需要加上应用层的心跳。

解决：通过在应用程序中模拟 TCP Keep-Alive 机制，来完成在应用层的连接探活。

设计一个 PING-PONG 的机制，需要保活的一方，比如客户端，在保活时间达到后，发起对连接的 PING 操作，如果服务器端对 PING 操作有回应，则重新设置保活时间，否则对探测次数进行计数，如果最终探测次数达到了保活探测次数预先设置的值之后，则认为连接已经无效。
第一个是需要使用定时器，这可以通过使用 I/O 复用自身的机制来实现；第二个是需要设计一个 PING-PONG 的协议。

2.消息格式设计

我们的程序是客户端来发起保活，为此定义了一个消息对象。这个消息对象是一个结构体，前 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