关于心跳机制设计,我的一点想法

举报
看,未来 发表于 2021/12/24 21:00:23 2021/12/24
【摘要】 @[toc] 想法忘了写哈,两年前的旧思想,今天放出来。1、不要迷信TCP的保活机制,应用层不会知道的。2、为什么一定要服务端向客户端发心跳包?两年前老师让我们这么写的时候我就提出了疑问,最后我毅然决然的选择了客户端向服务端发心跳。心跳机制对于服务器的意义是什么呢?在我的认知里,是服务器需要知道这个客户端是否还在线。如果客户端不在线了,就要做相应的资源回收或者标记工作。那客户端呢?客户端心跳...

@[toc]

想法

忘了写哈,两年前的旧思想,今天放出来。

1、不要迷信TCP的保活机制,应用层不会知道的。

2、为什么一定要服务端向客户端发心跳包?两年前老师让我们这么写的时候我就提出了疑问,最后我毅然决然的选择了客户端向服务端发心跳。心跳机制对于服务器的意义是什么呢?在我的认知里,是服务器需要知道这个客户端是否还在线。如果客户端不在线了,就要做相应的资源回收或者标记工作。

那客户端呢?客户端心跳发不过去就知道自己挂了嘛,该重连就重连,不重连就关机呗。

我当时为什么会产生那样的想法?如果是服务端向客户端发心跳包,客户端收到心跳之后需要向服务端回一个心跳包,一来一回服务端需要处理两次包。而客户端向服务端发心跳就不同了,首先不需要去记录那么多的时间戳,统一一个时间戳,轮询一遍过去(本来就要轮询)看哪个客户端的心跳包没到,就清理掉即可。

心跳保活我觉得不是那么核心的业务,如果是长连接服务,一万台客户端动不动就掉线个一百台成何体统?
将资源消耗压下去,和日志等非核心业务挤一条线程嘛。

附:

长连接断开的原因

在长连接的情况下,双方的所有通信 都建立在1条长连接上(1次TCP连接);所以,长连接 需要 持续保持双方连接 才可使得双方持续通信

可是,长连接会存在断开的情况,而 断开原因 主要是:

长连接所在进程被杀死
NAT超时
网络状态发生变化
其他不可抗因素(网络状态差、DHCP的租期等等 )
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。