Fiber WebSocket服务与浏览器JS客户端是否需手动发送Ping消息？

核心问题答疑 #

1. WebSocket是否存在默认ping/pong交互？为什么Chrome开发者工具看不到相关帧？ #

• WebSocket 协议（RFC 6455）本身定义了Ping（opcode 0x9）、Pong（opcode 0xA）控制帧，但浏览器原生WebSocket API、绝大多数服务端WebSocket实现都不会默认自动发起周期性ping/pong交互，仅在少数场景（如部分代理层探活、服务端默认超时断连逻辑）下可能触发单次控制帧，不存在持续的默认心跳逻辑。
• Chrome开发者工具的Network面板无法观测到Ping/Pong帧是正常现象：Chrome DevTools从设计上就不会展示协议层控制帧（Ping/Pong、Close控制帧），仅展示业务层传输的文本/二进制数据帧，即便你手动发送了标准Ping帧，这里也不会显示，不要用DevTools的帧列表判断Ping/Pong是否生效。

2. 是否需要自行实现ping/pong交互逻辑？ #

• 生产环境长连接必须自行实现心跳机制，核心原因有两点：
  • 公网环境下存在NAT表超时、运营商连接回收、防火墙静默断连、客户端异常断网/杀进程等场景，这类场景下TCP四次挥手无法正常完成，服务端和客户端都无法第一时间感知连接失效，会产生大量死连接占用系统资源。
  • 浏览器和服务端的WebSocket默认实现均无内置周期性探活逻辑，无法覆盖上述死连接场景。

3. 自定义心跳实现的细节问题 #

（1）Ping消息由哪一端发起更合理？

• 优先由服务端发起Ping，这是工业界通用实践：
  • 服务端对连接资源敏感度更高，由服务端统一控制心跳周期，可以灵活根据集群负载调整心跳频率，避免客户端随意发送心跳打满服务端资源。
  • 浏览器端原生WebSocket没有提供直接发送标准Ping帧的API：JS层调用ws.send()只能发送文本/二进制数据帧（opcode 0x1/0x2），无法发送opcode为0x9的标准Ping帧，客户端如果要发心跳只能用自定义格式的业务层消息，无法复用协议原生能力。

（2）阻塞读场景下Ping处理器如何配置？

• 不需要为处理Ping/Pong单独创建channel或改造阻塞读逻辑，直接使用默认处理器即可，无需自定义调用conn.SetPingHandler()：
  • Fiber WebSocket底层封装的gorilla/websocket库中，ReadJSON()/ReadMessage()等阻塞读方法在收到Ping帧时，会自动调用默认Ping处理器回复Pong帧，该逻辑在读循环内部自动完成，不会阻塞业务消息读取，也不需要额外编写处理逻辑。
  • 你之前猜测“Ping必须由客户端发往服务端”是错误的：服务端向客户端发送Ping帧时，Chrome等浏览器的WebSocket内核会自动回复Pong帧，不需要编写任何JS代码处理，该逻辑在浏览器内核层面实现，JS层无感知。

现有服务端Ping逻辑的问题与优化方案 #

你当前编写的Ping协程逻辑存在几个明显缺陷，优化点如下：

1. 缺少连接退出判断，会引发goroutine泄漏
   当前for循环没有连接关闭的判断逻辑，即便客户端已经断开连接，协程也会永久运行，长时间运行会泄漏大量goroutine。需要增加连接关闭信号监听，一旦连接断开立刻停止ticker并退出协程。
2. 缺少Pong超时校验，探活逻辑无效
   当前逻辑仅定时发送Ping，但没有处理Pong超时场景：发送Ping后如果连续2-3个周期未收到客户端回复的Pong，需要主动关闭连接清理死连接，否则发送Ping就失去了探活意义。可以配合SetPongHandler在每次收到Pong时刷新连接读超时。
3. 无意义的启动等待
   初始化ticker后不需要额外Sleep一个周期再启动逻辑，等待ticker的第一个时间信号即可。
4. 不需要为读消息单独创建channel
   只需要在读循环所在goroutine提前配置好读超时、Pong处理器即可，ReadJSON()阻塞过程中收到Ping/Pong会自动处理，不会影响心跳逻辑。

优化后的参考实现 #

const (
    pingPeriod = 30 * time.Second // 心跳发送周期
    pongWait   = 60 * time.Second // Pong超时时间，略大于2个心跳周期
    writeWait  = 5 * time.Second  // 写操作超时时间
)

// 连接建立后先配置基础参数
// 设置Pong处理器：收到Pong时自动刷新读超时
conn.SetPongHandler(func(string) error {
    conn.SetReadDeadline(time.Now().Add(pongWait))
    return nil
})
// 设置初始读超时
conn.SetReadDeadline(time.Now().Add(pongWait))

// 启动Ping发送协程
go func() {
    ticker := time.NewTicker(pingPeriod)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            // 发送Ping控制帧，设置写超时
            if err := conn.WriteControl(websocket.PingMessage, []byte{}, time.Now().Add(writeWait)); err != nil {
                // 发送失败说明连接已断开，主动关闭连接后退出
                conn.Close()
                return
            }
        case <-conn.Done(): // 监听连接关闭信号
            return
        }
    }
}()

// 主读循环，保持原有阻塞读逻辑即可
for {
    var bizMsg YourBusinessMessageType
    if err := conn.ReadJSON(&bizMsg); err != nil {
        // 读超时/连接异常时主动关闭连接，退出循环
        conn.Close()
        break
    }
    // 正常处理业务消息
}

验证提示：如果需要确认Ping/Pong是否正常工作，可以通过Wireshark抓对应端口的Loopback网卡流量，或者在服务端Pong处理器中打日志、观测死连接清理效果即可，不要依赖Chrome开发者工具的帧列表做判断。

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