关于心跳包的方案探究

今天发表几点个人看法，关于心跳包的

最近实现基于websocket的通信，app客户端和服务端的websocket服务

考虑到恶劣的网络环境和其它各种意想不到的情况，为了充分检查websocket的连接状态，额外采用心跳包的方式，每隔一段时间发送讯息，检测websocket的连接状态

 

在客户端做心跳还是在服务端做心跳？心跳包的时间间隔多久合适？

经过再三分析，决定还是在客户端做心跳比较合理，因为客户端做心跳发送的数据不会很集中，服务端可以承受的住，如果在服务端做心跳，单次发送的数量会很大，服务端很占资源

客户端多久做一次心跳，这个根据服务器的性能和服务的是否健壮来决定，如果服务器很一般建议大于一分钟，如果服务器很强大，10秒20秒也是很轻松的事情

 

服务端如何清理一些死连接？

通常服务端会缓存websocket，但是由于各种意想不到的情况，总有连接已经死掉了，在正常的处理中无法清理，但是还放在容器中，所以要定时清理。间隔时间就可以设置的时间长一点了，比如一小时

服务端可以做一个心跳处理，仅仅用于处理清理，不做心跳发送，因为服务端做心跳发送，在连接很多的情况下太占资源。

如何做清理？可以在收到客户端心跳响应的时候，做个更新时间，然后服务端根据这个时间来清理间隔时间很久的连接。

 

插播一个和心跳包关系可能不是很大的问题，消息发送如何确定消息发送成功？

譬如A和B聊天，A发送了几条信息，A如何知道发送成功了？

我似乎没有想到很好的办法，首先要知道什么叫发送成功，只要A和服务端的通信是成功的，我们就可以认为就是发送成功，

因此服务端收到A发送的消息要给A做个响应，A才可以知道消息发送成功了，至于有没有发送到B，那是B和服务端之间的事情，A管不到也不需要管

那么A如何管理这些消息呢

客户端生成唯一消息ID,譬如A发送了一个消息id为ASFT23的消息，此时默认状态是未知的，客户端由于缓存的了消息，所以状态管理不是问题，这个时候客户端收到了ASFT23的响应消息，已经确定是成功的了，更新状态为成功，那么如何知道哪些不成功呢？因此客户端还是少不了心跳检测，如何检测呢？只要客户端每隔30秒或者20秒检测一次，状态是未知的并且时间超过20秒就认为是一个失败信息

 

是否有更好的方案？欢迎评论

转载于:https://www.cnblogs.com/njcxwz/p/10666159.html