Workerman怎么保持长连接？Workerman心跳包如何实现？-Workerman-PHP中文网

Workerman通过事件驱动的非阻塞I/O模型高效维持长连接，结合客户端与服务器端双向心跳机制，定时发送心跳包并检测响应，防止NAT或防火墙导致的连接“假死”，同时通过定时清理未活跃连接、设置合理心跳间隔与超时时间、避免阻塞操作和内存泄漏，确保长连接的稳定性与可靠性。

workerman怎么保持长连接？workerman心跳包如何实现？

Workerman维持长连接的核心在于其事件驱动的非阻塞I/O模型，它能高效地管理大量并发连接而不会为每个连接创建独立进程或线程。而心跳包机制，则是在这个基础上，通过客户端和服务器端定时发送特定数据包来主动检测连接的活性，防止因网络中间设备（如NAT、防火墙）超时断开或客户端异常关闭导致连接“假死”，从而确保长连接的真正可靠性。

解决方案

要让Workerman保持长连接并有效处理心跳，我们需要在服务器端和客户端都做好相应的策略。

Workerman本身就擅长处理长连接，这得益于它的事件循环和非阻塞I/O。但光有这些还不够，网络环境复杂多变，NAT超时、防火墙策略、客户端突然断电等都可能导致TCP连接在应用层看起来还活着，实际上已经无法通信。这时候，心跳机制就显得尤为关键。

服务器端的核心实现：

立即进入“豆包AI人工智官网入口”；

立即学习“豆包AI人工智能在线问答入口”；

记录连接活跃时间： 在每个
```
onConnect
```
登录后复制
回调中，为新连接初始化一个
```
lastMessageTime
```
登录后复制
属性。每当这个连接有数据到来（
```
onMessage
```
登录后复制
回调），就更新它的
```
lastMessageTime
```
登录后复制
为当前时间。
定时检测与清理： 设置一个全局定时器（例如，每隔55秒），遍历所有当前活跃的连接。对于那些
```
lastMessageTime
```
登录后复制
距离现在已经超过某个阈值（比如60秒）的连接，就认为它们可能已经失效，服务器端可以主动关闭这些连接。
发送心跳响应（可选但推荐）： 当服务器收到客户端发来的心跳请求时，可以回发一个简单的心跳响应，告诉客户端“我还活着”。这有助于客户端判断服务器是否正常。

客户端的核心实现（以WebSocket为例）：

定时发送心跳请求： 客户端建立连接后，启动一个定时器（例如，每隔30秒），向服务器发送一个预定义的心跳包（例如，一个简单的JSON字符串
```
{"type":"ping"}
```
登录后复制
）。
接收心跳响应： 客户端也需要监听服务器的响应。如果服务器回发了心跳响应，说明连接是健康的。
超时重连机制： 客户端也应该有一个机制来检测服务器是否在规定时间内（例如，60秒）没有响应。如果长时间没有收到服务器的任何消息（包括心跳响应），就认为连接已断开，尝试进行重连。

通过这种双向的心跳机制，无论是客户端还是服务器端，都能及时发现并处理失效连接，从而维护一个稳定、可靠的长连接环境。

Workerman长连接的底层原理与常见陷阱分析

在我看来，理解Workerman的长连接，首先得从它的底层基石——事件驱动与非阻塞I/O说起。它不是为每个连接都开一个线程或进程，那样资源消耗太大了。Workerman利用的是像

Epoll

登录后复制

（Linux下）这样的多路复用技术，一个进程可以同时“监听”成千上万个连接的文件描述符。当任何一个连接有数据可读或可写时，操作系统就会通知Workerman，然后它再调度相应的回调函数去处理。这就像一个高效的前台接待员，一个人就能处理很多客人的请求，而不是每个客人来都配一个接待员。

这种模式天然就适合长连接，因为连接建立后，它就一直存在于Workerman的事件循环中，直到被显式关闭或者网络中断。它不需要频繁地建立、关闭TCP连接，大大减少了三次握手和四次挥手的开销。

但即便如此，长连接也并非没有陷阱，甚至可以说，很多性能问题和稳定性隐患都藏在这些地方：

阻塞操作是长连接的死敌： 这是我见过的最常见的错误。在
```
onMessage
```
登录后复制
或任何回调函数中，如果你执行了一个耗时且阻塞的操作（比如一个复杂的数据库查询没有异步化，或者一个远程API调用等待时间过长），那么整个Workerman进程都会被卡住，导致所有其他连接的请求都无法得到及时响应。这就像那个高效的接待员突然被一个客人缠住，其他所有客人都得等着。解决方法很简单：耗时操作必须异步化，或者交给独立的Worker进程处理。
内存泄漏： 长连接意味着一个连接可能会长时间存在。如果在
```
onConnect
```
登录后复制
或
```
onMessage
```
登录后复制
中，你为每个连接都创建了大量的对象，并且没有及时释放，那么随着连接数的增加，内存占用会越来越高，最终可能导致进程崩溃。Workerman本身是PHP写的，PHP的内存管理机制虽然有垃圾回收，但如果循环引用或者全局变量管理不当，仍然容易出问题。
文件描述符限制： 操作系统对单个进程能打开的文件描述符数量是有限制的（
```
ulimit -n
```
登录后复制
）。一个TCP连接就会占用一个文件描述符。如果你的Workerman进程需要处理成千上万个连接，而这个限制不够高，那么新的连接就无法建立。这不是Workerman的锅，是系统配置问题，但经常被忽视。
NAT超时与“假死”连接： 即使你的心跳机制做得很好，也要知道，很多网络中间设备（路由器、防火墙）为了节省资源，会对长时间没有数据传输的TCP连接进行强制关闭。这种关闭是悄无声息的，服务器和客户端可能都不知道连接已经断了。心跳包就是为了解决这个问题，但心跳间隔设置不当，或者心跳包本身被拦截，仍然可能导致连接“假死”。服务器端定期清理长时间未活跃的连接是必须的。

这些陷阱，很多时候不是Workerman本身的问题，而是我们在使用它时对底层机制理解不够深入，或者没有充分考虑到复杂的网络环境和编程习惯造成的。

Workerman心跳包的客户端与服务器端实现策略详解

心跳包的实现，在我看来，核心在于“双向确认”和“超时处理”。它不仅仅是服务器发给客户端，或者客户端发给服务器，而是两者都需要有发送和接收心跳的能力，并且能够根据超时情况做出判断。

服务器端实现策略：

Workerman服务器端的心跳逻辑通常是这样的：

记录连接活动时间：

豆包MarsCode

豆包旗下AI编程助手，支持DeepSeek最新模型

120

查看详情

use Workerman\Worker;
use Workerman\Timer;

$worker = new Worker('websocket://0.0.0.0:2346');
// 设置每个连接的属性，记录最后一次活跃时间
$worker->onConnect = function($connection) {
    $connection->lastMessageTime = time();
};

// 当收到任何消息时，更新活跃时间
$worker->onMessage = function($connection, $data) {
    $connection->lastMessageTime = time();
    // ... 处理业务逻辑 ...
    // 如果是心跳请求，可以回复一个心跳响应
    if ($data === '{"type":"ping"}') {
        $connection->send('{"type":"pong"}');
    }
};

登录后复制

定时器检测与清理： 这是服务器端主动清理“假死”连接的关键。

// 在Worker启动后设置一个定时器
$worker->onWorkerStart = function($worker) {
    // 每55秒检测一次所有连接
    Timer::add(55, function() use ($worker) {
        $now = time();
        foreach ($worker->connections as $connection) {
            // 如果连接超过60秒没有收到任何消息，就认为它已经断开
            if ($now - $connection->lastMessageTime > 60) {
                echo "Connection " . $connection->id . " timed out, closing.\n";
                $connection->close();
            }
        }
    });
};

登录后复制

这里我把心跳检测的间隔设为55秒，超时时间设为60秒。这样，如果客户端的心跳周期是30秒，那么即使有一次心跳丢失，服务器也不会立即关闭连接，给了一定的容错空间。

客户端实现策略（以JavaScript WebSocket为例）：

客户端的心跳逻辑，通常会涉及到定时发送、接收响应和断线重连。

let ws = null;
let pingTimer = null;
let pongTimer = null;
const heartbeatInterval = 30 * 1000; // 30秒发送一次心跳
const heartbeatTimeout = 60 * 1000; // 60秒内没收到消息就认为断线

function connectWebSocket() {
    ws = new WebSocket("ws://localhost:2346");

    ws.onopen = function() {
        console.log("WebSocket connected.");
        startHeartbeat(); // 连接成功后启动心跳
    };

    ws.onmessage = function(event) {
        console.log("Received: " + event.data);
        resetPongTimer(); // 收到任何消息都重置pong计时器
        const msg = JSON.parse(event.data);
        if (msg.type === "pong") {
            // 这是服务器的心跳响应，不需要额外处理，resetPongTimer已经做了
        }
        // ... 处理其他业务消息 ...
    };

    ws.onclose = function() {
        console.log("WebSocket disconnected. Reconnecting in 5 seconds...");
        stopHeartbeat(); // 连接关闭，停止心跳
        setTimeout(connectWebSocket, 5000); // 尝试重连
    };

    ws.onerror = function(error) {
        console.error("WebSocket error: " + error);
        ws.close(); // 发生错误也尝试关闭并重连
    };
}

function startHeartbeat() {
    // 启动ping定时器
    pingTimer = setInterval(() => {
        if (ws && ws.readyState === WebSocket.OPEN) {
            ws.send(JSON.stringify({ type: "ping" }));
            console.log("Sent ping.");
            // 每次发送ping后，启动或重置pong计时器，确保在指定时间内收到响应
            resetPongTimer();
        }
    }, heartbeatInterval);

    // 第一次连接成功后，也立即启动pong计时器
    resetPongTimer();
}

function resetPongTimer() {
    clearTimeout(pongTimer);
    pongTimer = setTimeout(() => {
        console.warn("No message received from server for too long. Closing connection.");
        if (ws && ws.readyState === WebSocket.OPEN) {
            ws.close(); // 超时未收到消息，主动关闭连接，触发onclose进行重连
        }
    }, heartbeatTimeout);
}

function stopHeartbeat() {
    clearInterval(pingTimer);
    clearTimeout(pongTimer);
    pingTimer = null;
    pongTimer = null;
}

// 首次连接
connectWebSocket();

登录后复制

这里的客户端代码，核心是两个定时器：

pingTimer

登录后复制

负责定时发送心跳请求，

pongTimer

登录后复制

则负责检测服务器是否在规定时间内有响应（任何消息都算响应，不仅仅是

pong

登录后复制

）。一旦

pongTimer

登录后复制

超时，就说明连接可能已经失效，客户端会主动关闭连接，并触发重连机制。这种双向的、带有超时检测的心跳机制，能够极大地提升长连接的健壮性。

优化Workerman长连接与心跳机制的性能与稳定性考量

在实际生产环境中，仅仅实现心跳机制是不够的，我们还需要深入考虑其性能和稳定性。我个人觉得，这不仅仅是代码层面的优化，更多的是一种系统设计的哲学。

心跳间隔与超时时间的权衡：
- 心跳间隔过短： 会增加网络流量和服务器负载，尤其是连接数巨大的时候。比如，10万个连接每秒都发心跳，那流量和CPU压力都会很大。
- 心跳间隔过长： 发现连接失效的延迟会增加，用户体验可能受损。
- 我的建议： 一般来说，30秒到60秒是一个比较合理的客户端心跳间隔。服务器端的检测周期可以略长于客户端的心跳间隔，给网络抖动留出余量。例如，客户端30秒发一次ping，服务器60秒没收到任何数据就关闭。
- 超时时间： 客户端的
```
pong
```
  登录后复制
  超时时间应该略长于心跳间隔，例如，心跳间隔30秒，超时时间设为60秒，这样能容忍一次心跳包的丢失。
心跳数据包的大小与内容：
- 心跳包应该尽可能小，只包含必要的信息。一个简单的
```
{"type":"ping"}
```
  登录后复制
  和
```
{"type":"pong"}
```
  登录后复制
  就足够了。不要在心跳包里夹带业务数据，那样会增加不必要的开销。
- 协议选择：WebSocket通常用文本帧或二进制帧发送心跳。如果用TCP，就自定义一个极简的协议头。
异常处理与重连策略：
- 客户端重连： 客户端在检测到连接断开或心跳超时后，必须有重连机制。而且，这个重连应该采用指数退避策略（例如，第一次1秒，第二次2秒，第三次4秒...），避免在网络故障时对服务器造成洪水般的重连请求。
- 服务器端日志： 记录连接断开、心跳超时等事件，这对于问题排查至关重要。
内存优化：
- Workerman是PHP进程，PHP的内存管理相对复杂。在处理大量长连接时，要特别注意避免内存泄漏。
- 检查
```
onConnect
```
  登录后复制
  和
```
onMessage
```
  登录后复制
  回调中是否有创建大量对象但未及时释放的情况。
- 对于每个连接的自定义属性，只存储必要的数据，避免存储过大的对象。
安全性考量：
- 心跳包本身通常不需要加密或签名，因为它们不包含敏感数据。但如果你的协议设计得比较复杂，或者需要防止DDoS攻击，可能需要考虑。
- 防止心跳包被滥用：例如，一个恶意客户端可以频繁发送心跳包来消耗服务器资源。服务器端应该有机制来限制单个连接的请求频率，或者在发现异常时直接关闭连接。
集群部署下的长连接管理：
- 当Workerman部署在多台服务器或者多个Worker进程时，负载均衡器（如Nginx、HAProxy）的选择很重要。L4层的负载均衡（TCP透传）通常对长连接更友好，因为它不会中断TCP会话。L7层的负载均衡（如HTTP代理）则需要配置为支持WebSocket或TCP透传，否则可能会导致长连接无法建立或频繁断开。
- 在多进程Workerman中，每个Worker进程独立管理自己的连接。心跳机制在每个Worker内部独立运行即可。