如何用Composer引入Ratchet轻松解决WebSocket长连接问题？

本文共计1044个文字，预计阅读时间需要5分钟。

WebSocket长连接问题并非引入一个库就能搞定的事，Ratchet只帮你把底层连接跑起来，真正决定连接是否稳定的是你对重连、心跳、错误分类和资源清理的处理方式。

为什么 Ratchet 连上就断（EOF / connection closed）

Ratchet 的 WebSocketComponent 或自定义 WampServer 默认不会为你维持连接生命周期。一旦消息处理函数返回，Goroutine（或 PHP 的事件循环）可能退出，导致底层 socket 被关闭——这在 PHP-FPM 环境下尤其明显，因为请求生命周期结束即释放资源。

常见现象：Connection closed before receiving a handshake response、EOF、刚发一条消息就报 Connection is closed。

• 确保你的 onOpen 后启动了持续监听循环（如 $conn->send() 后不 return，而是进入 while (true) + $conn->recv()）
• 不要在 onMessage 里做耗时同步操作（比如 file_get_contents），会阻塞事件循环
• PHP 的 set_time_limit(0) 和 ignore_user_abort(true) 必须显式调用，否则 CLI 进程可能被系统 kill

心跳必须由你自己实现，Ratchet 不自动发 ping

Ratchet 没有内置心跳帧（ping/pong）发送逻辑，浏览器 WebSocket API 也不暴露 sendPing() 方法，所以你得用业务消息模拟。关键不是“有没有心跳”，而是“心跳能否穿透所有中间件”。

典型配置陷阱：

• Nginx 默认 proxy_read_timeout 60，心跳间隔必须 ≤55 秒，推荐设为 45
• IBM Cloud ALB 或 AWS ELB 默认空闲超时 60 秒，同样要求心跳间隔
• 别只在服务端发 ping：客户端也得定时 ws.send('{"type":"ping"}')，并监听响应，否则单向心跳无法发现客户端已失联

重连不能只靠 setTimeout，要区分断开原因

前端用 WebSocket 原生对象时，onclose 事件的 event.code 和 event.reason 极其有限。Ratchet 后端主动 close 时可传 code（如 4001 表示认证失败），但网络闪断、NAT 超时等场景只会触发 1006（abnormal closure）。

实操建议：

• 在 onclose 里检查 ws.readyState === 0（CONNECTING）或 === 3（CLOSED），排除主动调用 ws.close() 的情况
• 首次连接失败（onerror + onclose 连续触发）立即重试；连续 3 次失败后退避，用 Math.min(1000 * 2 ** attempt, 30000)
• 服务端在 onClose 中记录 $conn->getCloseCode()，1001（going away）和 1005（no status）要区别对待——前者可重连，后者大概率是客户端崩溃

Composer 引入 Ratchet 只是第一步，别忽略 Swoole 或 ReactPHP 替代方案

composer require cboden/ratchet 装的是基于 PHP 的 event-loop 实现，它依赖 ext-libevent 或 ext-event，而这两个扩展在 macOS 或 Docker Alpine 上编译麻烦，且性能弱于现代替代品。

如果你的项目允许技术选型调整：

• 高并发场景优先考虑 swoole_websocket_server：原生协程、毫秒级心跳、自动 ping/pong 帧支持，onHandshake 阶段就能拒绝非法 Origin
• 需要与 Laravel 深度集成？laravel-websockets（基于 Pusher 协议）比裸 Ratchet 更省心，自带 dashboard 和 auth hook
• 纯 CLI 后台服务？reactphp/websocket 的流式接口更符合现代 PHP 编程习惯，错误传播更清晰

真正容易被忽略的点是：Ratchet 的连接数增长会直接反映在 PHP 进程内存占用上，没有连接池、没有自动 GC，一个长连接 ≈ 几 MB 内存。上线前务必用 ab 或 wrk 做连接压测，而不是只测功能通不通。