心跳机制详解

应用场景:

在长连接下,有可能很长一段时间都没有数据往来。理论上说,这个连接是一直保持连接的,但是实际情况中,如果中间节点出现什么故障是难以知道的。更要命的是,有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这个时候,就需要我们的心跳包了,用于维持长连接,保活

什么是心跳机制?

就是每隔几分钟发送一个固定信息给服务端,服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。

发包方:可以是客户也可以是服务端,看哪边实现方便合理。

心跳包之所以叫心跳包是因为:它像心跳一样每隔固定时间发一次,以此来告诉服务器,这个客户端还活着。事实上这是为了保持长连接,至于这个包的内容,是没有什么特别规定的,不过一般都是很小的包,或者只包含包头的一个空包。心跳包主要也就是用于长连接的保活和断线处理。一般的应用下,判定时间在30-40秒比较不错。如果实在要求高,那就在6-9秒。

心跳包的发送,通常有两种技术:

1.应用层自己实现的心跳包

由应用程序自己发送心跳包来检测连接是否正常,服务器每隔一定时间向客户端发送一个短小的数据包,然后启动一个线程,在线程中不断检测客户端的回应, 如果在一定时间内没有收到客户端的回应,即认为客户端已经掉线;同样,如果客户端在一定时间内没有收到服务器的心跳包,则认为连接不可用。

2.使用SO_KEEPALIVE套接字选项

在TCP的机制里面,本身是存在有心跳包的机制的,也就是TCP的选项. 不论是服务端还是客户端,一方开启KeepAlive功能后,就会自动在规定时间内向对方发送心跳包, 而另一方在收到心跳包后就会自动回复,以告诉对方我仍然在线。因为开启KeepAlive功能需要消耗额外的宽带和流量,所以TCP协议层默认并不开启默认的KeepAlive超时需要7,200,000 MilliSeconds, 即2小时,探测次数为5次。对于很多服务端应用程序来说,2小时的空闲时间太长。因此,我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数

开启KeepAlive选项后会导致的三种情况:

1、对方接收一切正常:以期望的ACK响应,2小时后,TCP将发出另一个探测分节

2、对方已崩溃且已重新启动:以RST响应。套接口的待处理错误被置为ECONNRESET,套接口本身则被关闭。

3、对方无任何响应:套接口的待处理错误被置为ETIMEOUT,套接口本身则被关闭.

有关SO_KEEPALIVE的三个参数:

1.tcp_keepalive_intvl,保活探测消息的发送频率。默认值为75s。

发送频率tcp_keepalive_intvl乘以发送次数tcp_keepalive_probes,就得到了从开始探测直到放弃探测确定连接断开的时间,大约为11min。

2.tcp_keepalive_probes,TCP发送保活探测消息以确定连接是否已断开的次数。默认值为9(次)。

3.tcp_keepalive_time,在TCP保活打开的情况下,最后一次数据交换到TCP发送第一个保活探测消息的时间,即允许的持续空闲时间。默认值为7200s(2h)。

总结:

一个服务器通常会连接多个客户端,因此由用户在应用层自己实现心跳包,代码较多 且稍显复杂。用TCP/IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。心跳包在按流量计费的环境下增加了费用.但TCP得在连接闲置2小时后才发送一个保持存活探测段,所以通常的方法是将保持存活参数改小,但这些参数按照内核去维护,而不是按照每个套接字维护,因此改动它们会影响所有开启该选项的套接字。

下面我们通过一个实例来展示心跳机制。

结构,一个客户程序,和一个服务程序。

步骤:

服务器:

1.经过socket、bind、listen、后用accept获取一个客户的连接请求,为了简单直观,这里服务器程序只接收一个connect请求,我们用clifd来获取唯一的一个连接。

2.为clifd修改KeepAlive的相关参数,并开启KeepAlive套接字选项,这里我们把间隔时间设为了5秒,闲置时间设置了5秒,探测次数设置为5次。

3.将clifd加入select监听的描述符号集

客户:很简单,只是连接上去,并停留在while死循环。

方式:

服务程序放到阿里云服务器上,我们执行服务程序并将输出结果重定向到一个日志文件,目的是为了将我们本地网络连接断开后,超过了keepalive闲置时间+重复发包探测的时间后,重新打开本地的网络连接,并登录服务器,通过该日志文件的内容来查看程序的打印结果。

客户:

#include <iostream>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <strings.h>
#include <stdio.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#include <unistd.h>
using namespace std;

int main()
{
	int skfd;
	if ((skfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
		perror("");
		exit(-1);
	}	

	struct sockaddr_in saddr;
	bzero(&saddr, sizeof(saddr));
	saddr.sin_family = AF_INET;
	saddr.sin_port = htons(9999);
	saddr.sin_addr.s_addr = inet_addr("115.29.109.198");

	if (connect(skfd, (struct sockaddr*)&saddr, sizeof(saddr)) < 0) {
		perror("");
		exit(-1);
	}

	cout << "连接成功" << endl;
	while(1);
	return 0;
}

服务器

#include <iostream>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <strings.h>
#include <stdio.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <errno.h>
#include <unistd.h>
#include <sys/select.h>
#include <netinet/tcp.h>
using namespace std;

#define LISTENNUM 5

int main()
{
	int skfd;
    if ((skfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
    	perror("");
        exit(-1);
    }

    struct sockaddr_in saddr;
    bzero(&saddr, sizeof(saddr));
    saddr.sin_family = AF_INET;
    saddr.sin_port = htons(9999);
    saddr.sin_addr.s_addr = inet_addr("115.29.109.198");

    if (bind(skfd, (struct sockaddr*)&saddr, sizeof(saddr)) < 0) {
    	perror("");
        exit(-1);
    }

    if (listen(skfd, LISTENNUM) < 0) {
    	perror("");
        exit(-1);
    }

    int clifd;
    if ((clifd = accept(skfd, NULL, NULL)) < 0) {
    	perror("");
        exit(-1);
    }
    cout << "有新连接" << endl;

    //setsockopt
    int tcp_keepalive_intvl = 5;   //保活探测消息的发送频率。默认值为75s
    int tcp_keepalive_probes = 5;  //TCP发送保活探测消息以确定连接是否已断开的次数。默认值为9次
    int tcp_keepalive_time = 5;    //允许的持续空闲时间。默认值为7200s(2h)
    int tcp_keepalive_on = 1;

    if (setsockopt(clifd, SOL_TCP, TCP_KEEPINTVL,
        &tcp_keepalive_intvl, sizeof(tcp_keepalive_intvl)) < 0) {
        perror("");
        exit(-1);
    }

    if (setsockopt(clifd, SOL_TCP, TCP_KEEPCNT,
    	&tcp_keepalive_probes, sizeof(tcp_keepalive_probes)) < 0) {
        perror("");
        exit(-1);
    }

    if (setsockopt(clifd, SOL_TCP, TCP_KEEPIDLE,
        &tcp_keepalive_time, sizeof(tcp_keepalive_time)) < 0) {
    	perror("");
        exit(-1);
    }

	if (setsockopt(clifd, SOL_SOCKET, SO_KEEPALIVE,
        &tcp_keepalive_on, sizeof(tcp_keepalive_on))) {
        perror("");
        exit(-1);
    }

    char buf[1025];
    int r;
    int maxfd;
    fd_set rset;
    FD_ZERO(&rset);
    sleep(5);
    while (1) {
    	FD_SET(clifd, &rset);
        maxfd = clifd + 1;
        if (select(maxfd, &rset, NULL, NULL, NULL) < 0) {
        	perror("");
            exit(-1);
        }

        if (FD_ISSET(clifd, &rset)) {
        	r = read(clifd, buf, sizeof(buf));
            if (r == 0) {
            	cout << "接收到FIN" << endl;
                close(clifd);
                break;
            }
            else if (r == -1) {
            	if (errno == EINTR) {
                	cout << "errno: EINTR" << endl;
                    continue;
                }

               	if (errno == ECONNRESET) {
                	cout << "errno: ECONNRESET" << endl;
                    cout << "对端已崩溃且已重新启动" << endl;
                    close(clifd);
                    break;
                }

                if (errno == ETIMEDOUT) {
                	cout << "errno: ETIMEDOUT" << endl;
                   	cout << "对端主机崩溃" << endl;
                    close(clifd);
                    break;
                }

                if (errno == EHOSTUNREACH) {
                	cout << "errno: EHOSTUNREACH" << endl;
                    cout << "对端主机不可达" << endl;
                   	close(clifd);
                    break;
                }
            }
        }
    }

    close(skfd);
	return 0;
}

执行服务程序并重定向到日志文件server.log,执行客户程序,之后将网络连接断开

一段时间后(大于KeepAlive空闲时间+重复探测时间),重新打开网络连接,用ssh登录服务器,查看server.log文件.发现打印了ETIMEDOUT

,验证了在客户网络断开后,到达空闲时间时,服务器由于开启了KeepAlive选项,会向客户端发送探测包,几次还没收到客户端的回应,那么select将返回套接字可读的条件,并且read返回-1.设置相关错误,

而与之相反的情况是如果不开启KeelAlive选项,那么即使客户端网络断开超过了整个的空闲和探测时间,服务端的select也不会返回可读的条件,即应用程序无法得到通知。

心跳机制详解

时间: 2024-10-29 04:38:49

心跳机制详解的相关文章

Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇)

1 背景 还记得前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>中关于透过源码继续进阶实例验证模块中存在的点击Button却触发了LinearLayout的事件疑惑吗?当时说了,在那一篇咱们只讨论View的触摸事件派发机制,这个疑惑留在了这一篇解释,也就是ViewGroup的事件派发机制. PS:阅读本篇前建议先查看前一篇<Android触摸屏事件派发机制详解与源码分析一(View篇)>,这一篇承接上一篇. 关于View与ViewGroup的区别在前一篇的A

【Hibernate步步为营】--锁机制详解

上篇文章详细讨论了hql的各种查询方法,在讨论过程中写了代码示例,hql的查询方法类似于sql,查询的方法比较简单,有sql基础的开发人员在使用hql时就会变得相当的简单.Hibernate在操作数据库的同时也提供了对数据库操作的限制方法,这种方法被称为锁机制,Hibernate提供的锁分为两种一种是乐观锁,另外一种是悲观锁.通过使用锁能够控制数据库的并发性操作,限制用户对数据库的并发性的操作. 一.锁简介 锁能控制数据库的并发操作,通过使用锁来控制数据库的并发操作,Hibernate提供了两种

浏览器缓存机制详解

对于浏览器缓存,相信很多开发者对它真的是又爱又恨.一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了"错误"的东西,而在开发过程中千方百计地想把缓存禁掉.那么浏览器缓存究竟是个什么样的神奇玩意呢? 什么是浏览器缓存: 简单来说,浏览器缓存就是把一个已经请求过的Web资源(如html页面,图片,js,数据等)拷贝一份副本储存在浏览器中.缓存会根据进来的请求保存输出内容的副本.当下一个请求来到的时候,如果是相同的URL,缓存会根据缓存机制决定是直接使用副本响应访问请求,还是

Android触摸屏事件派发机制详解与源码分析

请看下面三篇博客,思路还是蛮清晰的,不过还是没写自定义控件系列哥们的思路清晰: Android触摸屏事件派发机制详解与源码分析一(View篇) http://blog.csdn.net/yanbober/article/details/45887547 Android触摸屏事件派发机制详解与源码分析二(ViewGroup篇) http://blog.csdn.net/yanbober/article/details/45912661 Android触摸屏事件派发机制详解与源码分析三(Activi

SpringMVC视图机制详解[附带源码分析]

目录 前言 重要接口和类介绍 源码分析 编码自定义的ViewResolver 总结 参考资料 前言 SpringMVC是目前主流的Web MVC框架之一. 如果有同学对它不熟悉,那么请参考它的入门blog:http://www.cnblogs.com/fangjian0423/p/springMVC-introduction.html 本文将分析SpringMVC的视图这部分内容,让读者了解SpringMVC视图的设计原理. 重要接口和类介绍 1. View接口 视图基础接口,它的各种实现类是无

Shiro的Filter机制详解---源码分析

Shiro的Filter机制详解 首先从spring-shiro.xml的filter配置说起,先回答两个问题: 1, 为什么相同url规则,后面定义的会覆盖前面定义的(执行的时候只执行最后一个). 2, 为什么两个url规则都可以匹配同一个url,只执行第一个呢. 下面分别从这两个问题入手,最终阅读源码得到解答. 问题一解答 相同url但定义在不同的行,后面覆盖前面 如 /usr/login.do=test3 /usr/login.do=test1,test2 不会执行test3的filter

Android ViewGroup触摸屏事件派发机制详解与源码分析

PS一句:最终还是选择CSDN来整理发表这几年的知识点,该文章平行迁移到CSDN.因为CSDN也支持MarkDown语法了,牛逼啊! [工匠若水 http://blog.csdn.net/yanbober] 该篇承接上一篇<Android View触摸屏事件派发机制详解与源码分析>,阅读本篇之前建议先阅读. 1 背景 还记得前一篇<Android View触摸屏事件派发机制详解与源码分析>中关于透过源码继续进阶实例验证模块中存在的点击Button却触发了LinearLayout的事

Android Touch事件传递机制详解 上

尊重原创:http://blog.csdn.net/yuanzeyao/article/details/37961997 最近总是遇到关于Android Touch事件的问题,如:滑动冲突的问题,以前也花时间学习过Android Touch事件的传递机制,可以每次用起来的时候总是忘记了,索性自己总结一下写篇文章避免以后忘记了,其实网上关于Touch事件的传递的文章真的很多,但是很少有系统性的,都是写了一个简单的demo运行了一下,对于我们了解Android Touch事件基本上没有任何帮助. 今

Hibernate延迟加载机制详解

摘自 http://blog.chinaunix.net/uid-20577907-id-3129234.html 1 延迟加载: 延迟加载机制是为了避免一些无谓的性能开销而提出来的,所谓延迟加载就是当在真正需要数据的时候,才真正执行数据加载操作. 在Hibernate中提供了对实体对象的延迟加载以及对集合的延迟加载,另外在Hibernate3中还提供了对属性的延迟加载.下面我们就分别介绍这些种类的延迟加载的细节. A.实体对象的延迟加载: 如果想对实体对象使用延迟加载,必须要在实体的映射配置文