-
Notifications
You must be signed in to change notification settings - Fork 342
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[功能建议] 心跳包机制 #738
Comments
对于Http它也是有必要的,如果Http不轮询接收消息,只是作为一个API,那么它就有可能长时间不使用API,如果客户端已经关闭了或因为网络意外断开,服务端怎么知道它已经关闭?那么服务端怎么知道它是否需要释放资源,靠时间?靠时间的话如果客户端正常的,只是因为它长时间没有使用,你给它关闭了?所以心跳包是很有必要的,不是说只针对ws,同样的http也是需要的,对服务端资源管理也是有用的 |
这里做个假设:Http的API会话建立好了,但由于某种原因,比如:被进程被强制关闭了又或者网络出现问题。最后没来得及主动通知服务端进行释放,那么服务端对这个会话怎么检查会话的有效性与资源回收? 这里的假设只是针对于http适配器,不是http+ws模式。 |
这些情况可能比较极端,但是会有概率出现的。 像进程强制关闭(kill),就很容易出现。 |
靠心跳和靠时间维持无状态的HTTP保持会话,没有任何区别 |
假设一种情况,程序一直没有请求API的需求,所以它长时间没有与服务端进行通讯,期间由于服务端检查到长时间没有活动然后把会话释放掉了。心跳包它不是请求API只是定时上报我还存在。服务端收到后,知道客户端还没有端开,更新刷新一下上次交互的时间。 |
好处
心跳包的存在使得客户端和服务端可以有效的相互感知连接的建立情况。
对服务端而言,它可以对长时间没有心跳交互的客户端进行断开释放资源。
对客户端而言,它可以检查连接是否有效,避免服务端已经断开了还无法感知到,因为有一种情况,就是服务端网络出现故障,打个比方:服务端连接的wifi突然断开,服务端是不会向客户端发送关闭的请求的,因为你网络已经意外断开了,也发送不出去,所以导致客户端一直以为还处于连接状态。
The text was updated successfully, but these errors were encountered: