关于心跳机制设计,我的一点想法
【摘要】 @[toc] 想法忘了写哈,两年前的旧思想,今天放出来。1、不要迷信TCP的保活机制,应用层不会知道的。2、为什么一定要服务端向客户端发心跳包?两年前老师让我们这么写的时候我就提出了疑问,最后我毅然决然的选择了客户端向服务端发心跳。心跳机制对于服务器的意义是什么呢?在我的认知里,是服务器需要知道这个客户端是否还在线。如果客户端不在线了,就要做相应的资源回收或者标记工作。那客户端呢?客户端心跳...
@[toc]
想法
忘了写哈,两年前的旧思想,今天放出来。
1、不要迷信TCP的保活机制,应用层不会知道的。
2、为什么一定要服务端向客户端发心跳包?两年前老师让我们这么写的时候我就提出了疑问,最后我毅然决然的选择了客户端向服务端发心跳。心跳机制对于服务器的意义是什么呢?在我的认知里,是服务器需要知道这个客户端是否还在线。如果客户端不在线了,就要做相应的资源回收或者标记工作。
那客户端呢?客户端心跳发不过去就知道自己挂了嘛,该重连就重连,不重连就关机呗。
我当时为什么会产生那样的想法?如果是服务端向客户端发心跳包,客户端收到心跳之后需要向服务端回一个心跳包,一来一回服务端需要处理两次包。而客户端向服务端发心跳就不同了,首先不需要去记录那么多的时间戳,统一一个时间戳,轮询一遍过去(本来就要轮询)看哪个客户端的心跳包没到,就清理掉即可。
心跳保活我觉得不是那么核心的业务,如果是长连接服务,一万台客户端动不动就掉线个一百台成何体统?
将资源消耗压下去,和日志等非核心业务挤一条线程嘛。
附:
长连接断开的原因
在长连接的情况下,双方的所有通信 都建立在1条长连接上(1次TCP连接);所以,长连接 需要 持续保持双方连接 才可使得双方持续通信
可是,长连接会存在断开的情况,而 断开原因 主要是:
长连接所在进程被杀死
NAT超时
网络状态发生变化
其他不可抗因素(网络状态差、DHCP的租期等等 )
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱:
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论(0)