这是一个创建于 811 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前使用 ws 或者 node-websocket 的库。假如作为一个 websocket client ，业务需求本身是定时推送消息的，是不是没必要维护心跳（及时重连）了，因为我觉得心跳更多是保持活跃防止关闭连接的，而 close 事件已经承担了检测连接状态的功能。 假如只是监听 close 事件来维护重连，会有什么比较大隐患吗，比如连接已经关闭了但是 close 事件不触发（？）
 | 1 orangie 2023 年 11 月 16 日 有没有一种可能，就是，心跳机制会根据上次发包的时间来决定，业务发包够频繁就不会发心跳，而不是傻傻地固定时间发送。另外，使用 close 事件在关闭后重连的后果是反复新建立连接，这个过程 TCP 握手、TLS 握手、重新分配资源，怎么想怎么不划算。 |
 | 2 IvanLi127 2023 年 11 月 16 日 via Android 我印象中，如果没数据交换，状态有可能是不确定的，你想及时确认状态的话，就得有心跳包。如果 client 是浏览器的话，你还得看他怎么实现的，如果不想翻车，还是好好跳吧。 |
 | 3 chenluo0429 2023 年 11 月 16 日 via Android 如果你对实时性要求高一些就不行。主动关闭和客户端可感知的网络异常是会有 close 的，但是中间网络链路上的异常，客户端是没法感知的 |
 | 4 tool2d 2023 年 11 月 16 日 别的不知道，浏览器的 close 事件很稳。 |
 | 5 WashFreshFresh 2023 年 11 月 16 日 心跳是为了维持连接，不是检测连接，等到 close 的时候你只能再重新连接了。 |
 | 6 cF06myaQ57WHKMBv 2023 年 11 月 16 日 添加应用心跳是为了业务及时检测网络通路的状态，像 1 楼说的，当业务数据交互频繁的时候，可以不发送心跳。如果没有心跳包，完全依赖 websocket or tcp 自带心跳机制，比如 tcp 的 KeepAlive 机制，有时候链路的状态不能完全反应网络是否可用。 举两个场景吧 1 、两个设备已经建立的 TCP 连接，但是链路上没有数据发送，某一时刻网线断了，但是 TCP 的超时心跳还没有触发（ TCP 默认的心跳时间会比较长，而且还有重试机制），这时候再把网线连上，这种情况下，两个设备上的应用应该是没有感知的 2 、如果服务端的应用因为某些原因，没有响应，比如 cpu 使用率飙升到 100%，这时候网络状态是好的，但是业务无响应，这个时候客户端该怎么办 |
Select Language