使用RxJS对接WebSocket是否还需要额外实现心跳机制？

问题1：RxJS是否已经内置了保活相关逻辑？ #

你确实遗漏了核心逻辑：RxJS提供的closeObserver仅仅是对原生WebSocket onclose回调的观察者模式封装，没有做任何额外的保活、断连检测处理。它只能捕获到双向正常通知的关闭事件，比如服务端主动发关闭帧、你主动调用close方法、TCP连接正常挥手断开的场景，不存在内置的保活逻辑。

你提到的本地测试能正常触发关闭事件，是因为你模拟的都是符合TCP正常断开流程的错误，才会产生RxJS已经处理了断连检测的错觉。

问题2：为什么还需要实现ping-pong心跳机制？ #

你现有方案覆盖的都是正常关闭场景，生产环境存在大量closeObserver完全感知不到的静默断连场景，必须用心跳机制解决：

• 半开连接场景：用户突然断网、移动网络切换、路由器掉电、中间路由节点故障时，TCP连接没有经过正常的挥手流程，浏览器和服务端都以为连接还活着，此时你发任何消息都不会得到响应，closeObserver也永远不会触发，直到你主动检测到异常。
• 空闲连接被回收：公网环境的NAT网关、反向代理、防火墙几乎都有空闲连接超时回收机制，比如常见的Nginx反向代理默认60s就会清理没有数据传输的WebSocket连接，这种清理同样不会通知两端，直接造成静默断连。
• 服务端异常卡死：如果服务端进程挂死、OOM被杀死但内核没有正常关闭连接，此时TCP连接看似正常但服务端不会响应任何请求，closeObserver同样不会触发。

心跳的实现逻辑可以完美兼容你现有方案：你只需要定期向服务端发送ping帧，只要超出约定时间没有收到pong响应，主动调用WebSocket的close方法，就能触发你已经写好的closeObserver重连逻辑，用RxJS配合interval、timeout操作符实现也非常简单，不需要额外改造现有架构。

内容的提问来源于stack exchange，提问作者Jeppe Christensen