Boost::Beast WebSocket SSL客户端未发送Pong响应致连接断开求助

针对你遇到的Binance行情监听客户端因Pong超时频繁断开、主动发送Pong但服务器未收到的问题，可从以下几个方向排查：

1. 确认SSL流写入缓冲是否被及时刷新 #

Boost Beast的WebSocket基于SSL流实现，小尺寸的Pong帧可能被SSL层的缓冲机制滞留，未真正发送到网络。调用async_pong后，需手动触发SSL流的缓冲刷新：

ws.async_pong({},
    [&](beast::error_code ec)
    {
        if(!ec)
        {
            // 主动刷新SSL写入缓冲
            ws.next_layer().async_flush(
                [&](beast::error_code flush_ec)
                {
                    // 处理刷新结果
                });
        }
    });

2. 检查异步读写操作的调度冲突 #

若客户端长期处于async_read的等待状态，async_pong的操作可能被IO上下文的调度优先级压制，导致延迟发送。可在收到Ping时，先取消当前的async_read任务，发送Pong后再重新发起读操作：

ws.control_callback(
    [&](beast::websocket::frame_type kind, beast::string_view payload)
    {
        if(kind == beast::websocket::frame_type::ping)
        {
            // 取消当前读操作
            ws.cancel(beast::websocket::close_code::none);
            // 发送Pong
            ws.async_pong(payload,
                [&](beast::error_code ec)
                {
                    if(!ec)
                    {
                        // 重新发起异步读
                        do_read();
                    }
                });
        }
        return true;
    });

3. 验证自动Pong功能是否正常启用 #

Beast WebSocket默认开启自动Pong，但需确保未被手动关闭。初始化时显式配置：

// 确保自动Pong功能开启
ws.set_auto_pong(true);

同时注意自定义control_callback必须返回true，否则会阻止框架自动处理Ping帧：

ws.control_callback([](beast::websocket::frame_type kind, beast::string_view) {
    // 处理Ping日志等逻辑
    return true; // 返回true允许框架自动响应Pong
});

4. 关闭TCP Nagle算法避免小帧延迟 #

Nagle算法会合并小数据包延迟发送，可能导致Pong帧超时。在WebSocket连接建立后，关闭TCP no-delay选项：

// 获取底层TCP套接字，关闭Nagle算法
beast::get_lowest_layer(ws).socket().set_option(tcp::no_delay(true));

5. 抓包验证Pong帧是否实际发出 #

使用Wireshark抓取客户端与服务器之间的SSL流量，解密后确认Pong帧是否从客户端发送。若抓不到Pong帧，问题出在客户端发送逻辑；若能抓到但服务器未接收，需排查网络链路或服务器端配置。

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