很多人认为,TCP协议有KeepAlive机制,为何基于它的通讯链接仍然需要在应用层实现额外的心跳保活呢?本文将从移动端IM的角度告诉你,即使使用的是TCP协议,应用层的心跳保活仍旧必不可少。
成都创新互联公司是一家专业提供镇远企业网站建设,专注与成都网站制作、成都网站建设、外贸营销网站建设、H5建站、小程序制作等业务。10年已为镇远众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。
在使用TCP长连接的IM服务设计中,往往都会涉及到心跳。心跳一般是指客户端每隔一定时间向服务端发送自定义指令,以判断双方是否存活,因其按照一定间隔发送,类似于心跳,故称为心跳指令。
TCP是一个基于连接的协议,其连接状态是由一个状态机进行维护,连接完毕(三次握手)后,双方都会处于established状态,这之后的状态并不会主动进行变化。也就是说,即使上层不进行任何调用,一直使TCP连接空闲,那么它仍然是保持连接的状态。这个时候就需要一种机制来检测TCP连接的状态,KeepAlive就是背负这个使命出现的。
那么问题来了,KeepAlive是用来检测TCP连接状态的,那为什么还需要心跳呢?这里就需要考虑一种情况了,假如某台服务器因为某些原因导致负载超高,CPU100%,无法响应任何业务需求,但是使用TCP探针仍旧能够确定连接状态,这就是典型的连接活着但业务提供方已死的状态,对客户端而言,这时最好的选择就是断线后重新连接其他服务器,而不是一直认为当前服务器是可用状态,一直向当前服务器发送些必然后失败的请求。
从上面我们可以知道,KeepAlive并不适合检测双方存活的场景,这种场景还得依赖于应用层的心跳。应用层的心跳有着更大的灵活性,可以控制检测时机、间隔和处理流程,甚至可以在心跳包上附带额外信息。从这个角度而言,应用层的心跳的确是最佳实践。
TCP KeepAlive用于检测连接的死活,而心跳机制则附带一个额外的功能:检测通讯双方的存活状态。
从上面我们可以得出结论,目前而言,应用层心跳的确是检测连接有效性,双方是否存活的最佳实践,那么剩下的问题就是怎么实现。
最简单粗暴的方法是定时心跳,如每隔30秒心跳一次,15秒内没有收到心跳包则认为当前连接已失效,断开连接并进行重连。这种做法最直接,实现也简单。唯一的问题就是耗电和耗流量。以一个协议包 5 个字节计算,一天收发 2880 个心跳包,一个月就是 5 x 2 x 2880 x 30 = 0.8 M 的流量,如果手机上多装几个 IM 软件,每个月光心跳就好几兆流量没了,更不用说频繁的心跳带来的电量损耗。
既然频繁心跳会带来耗电和耗流量的弊端,改进的方向自然就是减少心跳频率,但也不能过于影响连接检测的实时性。基于这个需求,一般可以将心跳间隔根据程序状态进行调整,当程序在后台时(这里主要指安卓),尽量拉长心跳间隔,5分钟、甚至10分钟都可以。
而当App在前台时则按照原来规则操作。连接可靠性的判断也可以放宽,避免一次心跳超时就认为连接无效的情况,使用错误积累,只在心跳超时n次后才判定当前连接不可用。
没用过环信,用的是容能云,云通讯PaaS服务平台。
服务功能涵盖:IM即时通讯、实时音视频、短信服务、企业通讯+办公、流量服务、红包服务、营销活动、用户托管、反垃圾、大数据分析、云服务器、内容分发网络CDN、内容分发网络CDN、云数据库RDS等等。
开发文档和接口接入调试感觉还是比较简单快速的!
环信的即时通讯云最适合你的,Android、iOS、Web三大平台都支持。实现极其简单,只需要3步。
第一步:在环信官网注册获得使用码。
第二步:在环信官网下载SDK集成,加几行代码到App中,调试并修改UI等配置。
第三步:将拥有IM功能的App上线,就ok了! 加入IM就是这么简单。
环信的聊天功能是独立出来的,开发者可以直接集成环信的聊天UI ,集成之后可以直接使用它的所有功能,语音,,表情,共享位置等,快的3天能集成,慢的一个星期左右
都差不多,业内认可的基本上融云,环信这些。真正做起来的目前只有融云了。
网站题目:ios环信即时通讯开发的简单介绍
URL标题:https://www.cdcxhl.com/article44/dsehdee.html
成都网站建设公司_创新互联,为您提供网站内链、做网站、网页设计公司、静态网站、品牌网站设计、ChatGPT
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联