基于http-kit的WebSocket连接：是否需由服务器向客户端发送Ping？

首先，先直接回答你的核心疑问：服务器是否需要主动发送Ping，取决于你的具体场景需求，不是必须的，但在某些情况下会很有用：

• 如果你的客户端已经稳定发送Ping，并且服务器能可靠接收到这些Ping，那么服务器其实可以依赖客户端的心跳来跟踪连接状态——只要检测到某个通道长时间没有Ping（或任何消息），就判定连接失效并关闭它。这种方式更轻量，不需要服务器额外发起Ping请求。
• 但如果你的场景存在以下情况，服务器主动发Ping会更稳妥：
  • 客户端可能因为崩溃、网络异常等原因突然停止发送Ping，服务器无法及时感知；
  • 中间有防火墙、负载均衡设备，会自动断开长时间无流量的连接，服务器主动发Ping可以维持连接活性；
  • 你需要更主动地确认客户端是否在线，而不是被动等待客户端的消息。

接下来聊聊你提到的「函数式风格下实现状态跟踪繁琐」的问题——在Clojure里，我们可以用**原子（Atom）**来封装状态，结合不可变数据结构来实现优雅的连接跟踪，完全符合函数式编程的理念：

示例实现：基于Atom的连接活跃状态跟踪 #

;; 用原子维护通道到最后活跃时间的映射，状态被安全封装
(def active-channels (atom {}))

(defn ws-handler [request]
  (http-kit/with-channel request channel
    ;; 连接建立时，初始化通道的活跃时间
    (swap! active-channels assoc channel (System/currentTimeMillis))

    ;; 处理客户端Ping：更新活跃时间并回复Pong
    (http-kit/on channel :ping (fn [ping-data]
                                 (swap! active-channels assoc channel (System/currentTimeMillis))
                                 (http-kit/send! channel (http-kit/pong ping-data))))

    ;; 处理普通消息：同样更新活跃时间
    (http-kit/on channel :message (fn [msg]
                                    (swap! active-channels assoc channel (System/currentTimeMillis))
                                    ;; 这里写你的消息处理逻辑
                                    ))

    ;; 连接关闭时，从原子中移除通道记录
    (http-kit/on channel :close (fn [_]
                                  (swap! active-channels dissoc channel)))))

;; 启动定时清理任务：定期检查并关闭超时的死连接
(defn start-connection-cleaner [timeout-ms]
  (future
    (loop []
      (Thread/sleep 5000) ;; 每5秒执行一次检查
      (let [now (System/currentTimeMillis)
            ;; 筛选出超过超时时间的死连接
            dead-channels (filter (fn [[_ last-active]]
                                    (> (- now last-active) timeout-ms))
                                  @active-channels)]
        ;; 关闭死连接并更新状态
        (doseq [[channel _] dead-channels]
          (when (http-kit/open? channel)
            (http-kit/close channel)
            (swap! active-channels dissoc channel)))
        (recur)))))

;; 启动清理任务，设置超时为30秒
(start-connection-cleaner 30000)

为什么这个实现符合函数式风格？ #

• 状态被封装在active-channels原子中，所有状态更新都通过swap!完成——swap!会基于当前状态生成新的不可变Map，避免了直接修改可变状态；
• 定时任务只是读取原子的当前值，并进行纯函数式的筛选和处理，没有不必要的副作用（关闭通道属于必要的IO操作）；
• 整个逻辑没有全局可变变量，状态变化是可追踪、可测试的。

如果之后你需要服务器主动发送Ping，也可以基于这个原子来扩展：比如定时给所有活跃通道发送Ping，同时记录发送Ping的时间，之后如果在指定时间内没收到Pong，就判定连接失效。

总结下来，你当前的客户端Ping方案完全可行，服务器端不需要额外发Ping也能有效跟踪连接状态；而用Atom封装状态的方式，能让你在函数式风格下优雅实现连接超时管理，不用纠结复杂的状态修改逻辑。

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