心跳包

· 浏览次数 : 0

小编点评

**心跳机制** * 心跳机制是用于检测对端存活的一种常用方式。 * 常见的心跳包keepalive说到常见的心跳包,就说tcp keepalive机制了依然是wiki:传输控制协议(TCP)存活包为可选特性,且默认关闭。 * 协议中还有三个与存活包相关的参数:存活时长、存活间隔、存活重试次数。 * 心脏出血漏洞(ok,我还是懒得写,连接安排上)IM系统中的心跳机制主要是获取用户在线状态,以及向用户推送数据用与前面两种心跳类似,不过IM系统需要面对一个麻烦的东西 -- NAT。 * 为了确保心跳机制能正常运行,应用层在根据自身情况,去找数据库那状态。

正文

什么是心跳包(心跳机制)

先看一下wiki上的说法:

心跳包(英语:Heartbeat)在计算机科学中指一种周期性的信号,通过硬件或软件的形式来检测行为的正常与否,或者与计算机系统是否一致。[1] 通常,机器间会每隔几秒钟发送一次心跳包。 如果接收终端没有在指定时间内(通常是几个心跳包发送的时间间隔内)接收到心跳包,发送终端将会被判定发送失败。

简而言之心跳机制是用于检测对端存活的一种常用方式。

有点类似icu里面的心跳检测机(服务端),你的心脏(客户端)跳一下,他就更新一下状态,认为你还活着,你要太长时间没跳,他就认为你已经不行了,然后发出bi 的警告。

在网络中,心跳的作用是,在一种需要对端保持连接的状态中,并且存在无法通过上一次的请求判断当前的状态(虽然心跳也不能保证下一次发送成功,但是现实是,我上一次请求是12h前发的,所以你现在还在不在),心跳包可以单独检测对端的存活状态,从而防止发送无用的数据包,另外在分布式系统中,可以避免将数据发送到不可用的节点上(这是比较麻烦的,我成功地把包发到一个不可用的节点上,他给我反错误了,我怎么办,发给其他节点吗,会造成双花吗?)

当然心跳机制不会完美地解决上面的这些问题(毕竟我也不能保证这一秒你的心还在跳,下一秒你就一定还活着),在高可用的系统中还是需要设计另外的机制来防止双花。

另外值得说的一点是:我们不能在网络中发送过多的心跳包,因为在很多时候,网络也是一直有限的资源(心跳虽好,可不要贪杯o),当然也有设计感觉网络情况动态调整的心跳机制,不过那就涉及一些网络底层的东西了。

常见的心跳包

keepalive

说到常见的心跳包,就不得不说tcp keepalive机制了

依然是wiki:

传输控制协议(TCP)存活包为可选特性,且默认关闭。[1]存活包内没有数据。在以太网网络中,存活包的大小为最小长度的几帧(64字节[2])。协议中[3],还有三个与存活包相关的参数:

存活时长(英语:Keepalive time)即空闲时,两次传输存活包的持续时间。TCP存活包时长可手动配置,默认不少于2个小时。

存活间隔(英语:Keepalive interval)即未收到上个存活包时,两次连续传输存活包的时间间隔。

存活重试次数(英语:Keepalive retry)即在判断远程主机不可用前的发送存活包次数。当两个主机透过TCP/IP协议相连时,TCP存活包可用于判断连接是否可用,并按需中断。

多数支持TCP协议的主机也同时支持TCP存活包。每个主机按一定周期向其他主机发送TCP包来请求回应。若发送主机未收到特定主机的回应(ACK),则将从发送主机一侧中断连接。 若其他主机在连接关闭后发送TCP存活包,关闭连接的一方将发送RST包来表明旧连接已不可用。其他主机将关闭它一侧的连接以新建连接。

空闲的TCP连接通常会每隔45秒或60秒发送一次存活包。在未连续收到三次ACK包时,连接将中断。此行为因主机而异,如默认情况下的Windows主机将在7200000ms(2小时)后发送首个存活包,随后再以1000ms的间隔发送5个存活包。若任意存活包未收到回应,连接将被中断。

keepalive作为最基础的心跳机制,其设计已经融入tcp协议中了。

  • wireshark keepalive捉包分析

TLS的心跳机制与心脏出血漏洞

TLS心跳原理rfc 6520这里就之间放rfc的原文了,感兴趣的可以去读读看。

简单来讲TLS心跳拓展主要解决的是在tls链路中,判断对方存活需要进行一次tls协商(这是比较费时),这个心跳拓展的主要目的是通过一个简单的心跳过程来保留tls链路的存活,在之前是使用tcp的keepalive来做的,但tcp的keepalive只能保证tcp链路的可用性。

看完这篇rfc,有两个比较有意思的点

对于每个心跳包,我们需要给他一个payload,而服务端返回的时候需要原封不动的返回这个payload。这么做我猜测是外来解决网络超时的问题,防止我受到之前的包

不需要时时刻刻的发送心跳包,感觉rfc的定义,我们只需要在网络空闲的时候发送心跳包,而在链路中有请求的情况下则不需要发送请求包。

IM系统中的心跳机制

IM系统(通讯系统)中的心跳机制主要是获取用户在线状态,以及向用户推送数据用

与前面两种心跳类似,不过IM系统需要面对一个麻烦的东西 -- NAT(当然TLS的心跳也有考虑NAT的因素)。对于IM系统,本质是是一个C/S架构的系统,而大部分的C都是没有独立IP的,与server通讯,全靠NAT分配的临时IP与端口,而NAT的反配权又不是C端掌控的,实际上是运营商在控制NAT的分配与释放。同时IM系统中一般C的数量会是S数量的几千-几万倍,维护心跳状态将会耗费大量的资源,不过值得庆幸的是,IM实际上是一种弱可用的系统,服务端不需要对客户端的心跳做出反应,也不需要向客户端发送心跳包,有点类似于UDP,客服端发出去就不管了。当然IM的心跳机制还是颇为复杂的,而他的复杂也不是我想要了解的信息,所以这里只给出一片作者认为还可以的博客

应用层上的心跳包

上面谈到的心跳机制基本上都是网络层面的心跳机制,更多的是确认一个链路是否还可用。当然我们可以把这个链路再抽象一下,比如在一个对等网络中,你连接了某个数据库的资源,我连接了另一个数据库的资源,而我们需要保证相互之间 到数据库的链路是连通的。那么这就不是简单的tcp keepalive这种模式能解决的问题了。我们没法在网络传输模块完成整个心跳过程,网络层甚至不知道数据库是什么,所以这个请求必须上抛到应用层,而应用层在根据自身情况,去找数据库那状态(这里有个情况,为什么不让数据库也跳起来,主要是浪费资源,心跳是检测活性,如果没有client,实际上也用不到数据库的活性,对于心跳包中负责的请求,应该被动的等待需要的时候在去操作,而不是在这一边主动那自己的状态,推上去)。

当然这还会有一些问题我们包心跳的逻辑全部放在应用层,是不是对心跳是不很友好,这回导致应用层的逻辑与网络层的逻辑耦合在一起,本来应该网络层做的心跳,可所有的逻辑都在应用层,网络层就像完全没有心跳这回事。

心跳方案的设计

说这么多,最后我们还是回到现实,最近我有一开发任务,为我们的分布式系统添加一个心跳检测机制。

简单描述一下我们的系统:

一个分布式的系统,每个peer会连接一个或多个资源,一个资源会被多个peer连接,当peer受到请求后会随即的把请求发送到他知道能处理这个请求的peer中。peer之间使用json_rpc通行(用rpc协议是这个过程实际上就是一个远程调用)。

比如我是a,我知道b,c,d能处理 x的请求,我会随即的把请求发到b,c,d某个peer中(或者发送到第一个peer)。

现在遇到的一个问题是,如果b,c,d中间有人挂机了,a是不知道的,而a还会随即的把请求发到一个节点里面。

我现在的设计方案是,在rpc模块实现心跳的逻辑,包括自动发送心跳包,判断返回结果是否正常,对于多次心跳异常的节点进行处理,(对方节点死了也要周期性的那,用于复活),也就是心跳的主要逻辑在rpc中实现(网络模块),它用于控制心跳的评论等等,然后在rpc中抽象出两个接口,HeartbeatHandler,HeartbeatClient

  • HeartbeatHandler 接口表示心跳服务端处理的接口

  • HeartbeatClient 接口表示心跳客户端的接口: 客户端接口只需要提供两个方法,一个属如果构造心跳请求的接口,一个属如何处理心跳结果的接口

在server 启动时,将一个HeartbeatHandler的接口注册到server中,在client实例化的时候设置HeartbeatClient 并开启心跳,而心跳的流程控制还在网络模块中。

在我的这个业务中,HeartbeatHandler接口在收到心跳请求会,回去找当前节点连接的资源获取状态,让后返回资源是否可用的结果给clinet

client根据结果来刷新自己的路由表,确保下次请求发送到一个状态最健康的节点上。

 

**WRAN 以上文章只是出自我的初步调研,若有疏漏,还请同好们多多指正**

与心跳包相似的内容:

心跳包

什么是心跳包(心跳机制) 先看一下wiki上的说法: 心跳包(英语:Heartbeat)在计算机科学中指一种周期性的信号,通过硬件或软件的形式来检测行为的正常与否,或者与计算机系统是否一致。[1] 通常,机器间会每隔几秒钟发送一次心跳包。 如果接收终端没有在指定时间内(通常是几个心跳包发送的时间间隔

CS后门源码特征分析与IDS入侵检测

CS后门源码特征分析与IDS入侵检测考核作业 上线x64 getshell 抓心跳包,对特征字符解密Uqd3 用java的checksum8算法得到93,说明是x64的木马 public class EchoTest { public static long checksum8(String tex

React闭包陷阱

# React闭包陷阱 `React Hooks`是`React 16.8`引入的一个新特性,其出现让`React`的函数组件也能够拥有状态和生命周期方法,其优势在于可以让我们在不编写类组件的情况下,更细粒度地复用状态逻辑和副作用代码,但是同时也带来了额外的心智负担,闭包陷阱就是其中之一。 ## 闭

ChatGPT 是如何产生心智的?

一、前言 - ChatGPT真的产生心智了吗? 来自斯坦福大学的最新研究结论,一经发出就造成了学术圈的轰动,“原本认为是人类独有的心智理论(Theory of Mind,ToM),已经出现在ChatGPT背后的AI模型上”。所谓心智理论,就是理解他人或自己心理状态的能力,包括同理心、情绪、意图等。这

跑得更快!华为云GaussDB以出色的性能守护“ERP的心脏”

摘要:GaussDB已经全面支撑起MetaERP,在包括库存服务在内的9大核心模块中稳定运行,端到端业务效率得到10倍提升。 本文分享自华为云社区《跑得更快!华为云GaussDB以出色的性能守护“ERP的心脏”》,作者:GaussDB 数据库。 ERP作为华为企业经营最核心的系统,伴随着华为20多年

使用spark-sql处理Doris大表关联

背景 最近项目上有一个需求,需要将两张表(A表和B表)的数据进行关联并回写入其中一张表(A表),两张表都是分区表,但是关联条件不包括分区字段。 分析过程 方案一 最朴素的想法,直接关联执行,全表关联,一条SQL搞定全部逻辑。想法越简单,执行越困难。由于数据量大,服务器规模较小,尽管各台服务器内存和C

antd pro 使用心得

最近用 antd pro 开发了一些 web 小工具。 antd pro 不仅仅是升级版的 antd 组件,更重要的是提供了全套的前端解决方案,包括前端工程的编译打包,路由配置,数据管理,样式和资源的引用,和后端的交互方式。 甚至对于网站的国际化也有支持。 本篇是近期使用antd pro 时,用到的

[转帖]Linux 监测服务心跳、服务重启策略

文章目录 前言背景一、curl服务可用验证二、服务探测脚本三、配置系统定时任务四、Linux特殊字符转义总结 前言 请各大网友尊重本人原创知识分享,谨记本人博客:南国以南i、 提示:以下是本篇文章正文内容,下面案例可供参考 背景 当服务假死情况下,导致服务不可用,一时间定位不到服务假死原因,可以采用

[转帖]网络编程之长连接 、短连接、心跳机制与断线重连

https://cloud.tencent.com/developer/article/1953996?areaSource=104001.94&traceId=7WZNP412yK3vh7ebw4th0 概述 可承遇到,不知什么原因,一个夜晚,机房中,大片的远程调用连接断开。 第二天早上,用户访问

java netty 实现 websocket 服务端和客户端双向通信 实现心跳和断线重连 完整示例

java netty 实现 websocket 服务端和客户端双向通信 实现心跳和断线重连 完整示例 maven依赖 io.netty netty-all 4.1.97