今天发表几点个人看法，关于心跳包的
最近实现基于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秒就认为是一个失败信息
是否有更好的方案？欢迎评论