Boost Beast WebSocket客户端发送关闭帧后未触发control_callback接收服务器响应关闭帧的问题排查

我来帮你捋清楚这个问题，这其实是Boost Beast WebSocket的预期行为，咱们一步步拆解原因和正确的处理方式：

为什么control_callback没被触发？ #

根据WebSocket协议规范，关闭连接需要双向交互：客户端发关闭帧，服务器必须回一个关闭帧，之后连接才算正式关闭。但Boost Beast的websocket::stream组件在处理async_close操作时，会自动在内部处理服务器返回的响应关闭帧，不会把这个帧推送到你设置的control_callback里。

Beast的设计逻辑是：这种响应帧属于WebSocket关闭握手的内部协议步骤，不需要用户手动干预，所以不会触发你的回调。你的control_callback只会对两种情况做出反应：

• 服务器主动发起的关闭帧（比如服务器因自身业务或异常主动断开连接）
• 其他类型的控制帧（比如ping/pong帧）

正确确认关闭握手完成的方式 #

要验证关闭握手是否成功完成，你应该盯着async_close的完成处理函数，而不是依赖control_callback。当async_close的handler被调用且没有错误时，就说明服务器的响应关闭帧已经被Beast接收并处理，整个关闭流程走完了。

比如你可以给你的客户端代码补充关闭完成的处理逻辑：

// 发起关闭请求
ws_.async_close(websocket::close_code::normal,
    beast::bind_front_handler(
        &session::on_close,
        shared_from_this()));

// 关闭完成的回调函数
void on_close(beast::error_code ec) {
    if(ec) {
        fail(ec, "close");
        return;
    }
    // 走到这里就说明关闭握手已经完成，服务器的响应帧已被处理
    std::cout << "关闭握手完成，服务器已回复关闭帧" << std::endl;
}

额外的代码检查点 #

你也可以排查下代码里有没有这些可能干扰异步流程的问题：

• 有没有在调用async_close后，提前销毁了session对象（比如shared_ptr意外被释放），导致后续的handler和callback都无法触发
• 有没有在SSL/WebSocket握手完成后，让io_context提前停止运行，导致异步操作没机会完成

快速验证方法 #

你可以在新增的on_close handler里加日志，当这个函数被调用时，就证明服务器的响应关闭帧已经被Beast内部处理好了，完全不需要等control_callback的触发。

内容来源于stack exchange