Workerman支持哪些协议？Workerman协议使用方法？-Workerman-PHP中文网

Workerman的核心是高性能PHP异步通信框架，支持HTTP、WebSocket、TCP、UDP及自定义协议，通过事件驱动和协议类分离设计实现灵活扩展，开发者可自定义input、decode、encode方法处理粘包、分包与数据编解码，适用于高并发实时通信场景。

workerman支持哪些协议？workerman协议使用方法？

Workerman的核心魅力在于它不仅仅是一个简单的Web服务器，而是一个高性能的PHP异步通信框架，这意味着它天生就对各种网络协议有着极强的适应性和支持能力。从最常见的HTTP和WebSocket，到更底层的TCP和UDP，甚至是完全自定义的应用层协议，Workerman都能游刃有余地处理。它提供了一个构建网络服务的通用基础，让你能够根据自己的需求，灵活地选择或定义通信方式。

Workerman支持的协议类型非常广泛，这其实是它设计哲学决定的。它不是一个被特定协议绑死的框架，而是一个协议无关的底层网络库。

HTTP协议： 这是我们最熟悉的Web协议，Workerman通过内置的
```
Http
```
登录后复制
协议类，可以非常方便地处理HTTP请求和响应。你完全可以用它来搭建高性能的API服务、Web应用，甚至是一个简单的静态文件服务器。它的优势在于轻量和高效，避免了传统PHP-FPM模式的进程开销。
WebSocket协议： 对于需要实时双向通信的应用，WebSocket是首选。Workerman内置了对WebSocket协议的完美支持，配合
```
GatewayWorker
```
登录后复制
等组件，可以轻松实现聊天室、实时数据推送、在线游戏等功能。说实话，我个人觉得Workerman在WebSocket这块的表现力，是它最亮眼的地方之一。
TCP协议（原始Socket）： 这是所有网络通信的基础。Workerman可以直接监听TCP端口，处理原始的TCP数据流。这意味着你可以基于TCP构建任何你想要的通信协议，无论是私有协议还是其他标准协议（如MQTT、Redis协议等）。它提供了
```
onConnect
```
登录后复制
、
```
onMessage
```
登录后复制
、
```
onClose
```
登录后复制
等事件回调，让你能完全掌控连接的生命周期和数据处理。
UDP协议： 与TCP不同，UDP是无连接的协议，适用于对实时性要求高但允许少量丢包的场景，比如游戏、音视频传输等。Workerman同样支持UDP通信，你可以用它来构建高性能的UDP服务。
自定义协议： 这才是Workerman真正强大的地方。它提供了一套非常灵活的机制，允许你定义自己的应用层协议。你只需要实现
```
decode
```
登录后复制
、
```
encode
```
登录后复制
和
```
input
```
登录后复制
这三个方法，告诉Workerman如何解析收到的数据包，如何将数据打包发送，以及如何判断一个完整的数据包是否已经到达。这种能力让Workerman几乎可以适配所有你能想象到的网络通信场景。

Workerman协议的使用方法，核心在于

Worker

登录后复制

类实例的

protocol

登录后复制

属性。当你创建一个

Worker

登录后复制

实例时，可以通过设置这个属性来指定它将使用的协议。例如，

new Worker('http://0.0.0.0:8080');

登录后复制

就明确告诉Workerman这个Worker将处理HTTP协议。如果是自定义协议，你需要先定义好你的协议类，然后像这样使用：

new Worker('MyCustomProtocol://0.0.0.0:1234');

登录后复制

。对于原始TCP/UDP，你直接写

tcp://0.0.0.0:1234

登录后复制

或

udp://0.0.0.0:1234

登录后复制

即可，Workerman会把收到的数据作为原始字节流传递给你。

为什么Workerman对协议的支持如此灵活？

在我看来，Workerman之所以能在协议支持上表现出惊人的灵活性，主要得益于它底层的设计哲学。它并非一开始就为了某个特定协议而生，而是从构建高性能网络通信框架的角度出发。

首先，Workerman的核心是一个事件驱动、非阻塞I/O的PHP Socket服务器。这意味着它直接操作操作系统提供的Socket接口，对数据流的读取和写入拥有绝对的控制权。它不依赖Apache或Nginx这样的外部Web服务器，而是自己监听端口，管理连接。这种底层控制能力是它能够支持各种协议的基础。

其次，Workerman将网络通信的“骨架”与应用层协议的“肉体”清晰地分离开来。

Worker

登录后复制

类负责管理连接、事件循环、I/O复用等通用网络任务，而具体的协议解析和封装逻辑则由独立的协议类（Protocol Class）来处理。当你指定一个协议，比如

Http

登录后复制

或

WebSocket

登录后复制

，Workerman内部就会加载对应的协议类，并调用其

decode

登录后复制

、

encode

登录后复制

、

input

登录后复制

等方法来处理数据。

这种设计模式使得Workerman具有极强的可扩展性。如果你需要支持一个新的协议，你不需要修改Workerman的核心代码，只需要按照其规定的接口（即实现

protocol

登录后复制

接口的三个方法）编写一个新的协议类即可。这就像给Workerman提供了一套“插件”机制，让它能够“理解”并“说出”各种不同的网络语言。对我而言，这种设计思想简直是工程上的优雅体现，它让开发者能够专注于业务逻辑，而不用深陷于复杂的网络协议细节。

如何在Workerman中实现一个自定义协议？

实现一个自定义协议是Workerman高级用法中非常强大的一环，它能让你构建出高度优化、满足特定需求的通信机制。我来详细说说这块怎么玩。

核心在于你需要创建一个PHP类，并确保它能被Workerman识别为协议处理器。这个类通常需要实现三个静态方法：

input

登录后复制

、

decode

登录后复制

和

encode

登录后复制

。

```
input($recv_buffer)
```
登录后复制
：这个方法是协议的“嗅探器”。当Workerman从Socket接收到数据时，会把当前已接收到的所有数据（
```
$recv_buffer
```
登录后复制
）传递给这个方法。
```
input
```
登录后复制
方法的任务是判断这堆数据里是否包含了一个完整的数据包。
- 如果数据不足以构成一个完整包，它应该返回
```
0
```
  登录后复制
  ，告诉Workerman“我还没收到完整的数据，请继续等待”。
- 如果数据包含一个完整包，它应该返回这个完整包的长度。Workerman会根据这个长度来截取数据，并传递给
```
decode
```
  登录后复制
  方法。
- 如果数据有问题，无法解析，可以返回
```
false
```
  登录后复制
  或者抛出异常。
- 一个关键点： 这个方法必须是静态的。
```
decode($recv_buffer)
```
登录后复制
：当
```
input
```
登录后复制
方法告诉Workerman已经收到一个完整的数据包后，Workerman会将这个完整的数据包（由
```
input
```
登录后复制
方法返回的长度截取后的数据）传递给
```
decode
```
登录后复制
方法。
```
decode
```
登录后复制
方法的职责是将这个原始的数据包解析成PHP应用程序能够理解的数据结构，比如一个数组、一个对象或一个字符串。

讯飞听见会议
科大讯飞推出的AI智能会议系统

19

查看详情
- 这个方法也必须是静态的。
```
encode($data)
```
登录后复制
：这个方法是协议的“打包器”。当你的应用程序需要向客户端发送数据时，你会调用
```
Connection
```
登录后复制
对象的
```
send
```
登录后复制
方法，并传入你想要发送的PHP数据（比如一个数组）。
```
encode
```
登录后复制
方法会接收这个PHP数据，并将其按照你的协议规则，编码成原始的字节流（字符串），然后Workerman会将这个字节流发送给客户端。
- 这个方法也必须是静态的。

一个简单的自定义协议示例（伪代码）：

假设我们想实现一个简单的文本协议，每个消息都以换行符

登录后复制

结束。

<?php
namespace Protocols;

class MyTextProtocol
{
    // 判断数据包长度
    public static function input($recv_buffer)
    {
        // 查找换行符
        $pos = strpos($recv_buffer, "
");
        // 如果没有换行符，说明数据包不完整
        if ($pos === false) {
            return 0;
        }
        // 返回数据包长度（包括换行符）
        return $pos + 1;
    }

    // 解码数据包
    public static function decode($recv_buffer)
    {
        // 去掉换行符，返回实际内容
        return trim($recv_buffer);
    }

    // 编码数据包
    public static function encode($data)
    {
        // 确保数据是字符串，并在末尾加上换行符
        return $data . "
";
    }
}

登录后复制

如何使用：

<?php
require_once __DIR__ . '/vendor/autoload.php'; // 假设你使用了composer
require_once __DIR__ . '/Protocols/MyTextProtocol.php'; // 引入你的协议文件

use WorkermanWorker;

$worker = new Worker('Protocols\MyTextProtocol://0.0.0.0:1234');

$worker->onMessage = function($connection, $data) {
    echo "Received: " . $data . "
";
    // 响应客户端
    $connection->send("Hello, " . $data);
};

Worker::runAll();

登录后复制

实现自定义协议时，最大的挑战往往在于处理数据的边界问题（粘包、分包）、二进制数据的打包与解包（

pack

登录后复制

unpack

登录后复制

函数会是你的好帮手），以及协议的错误处理。设计一个健壮的自定义协议，需要你对网络传输和数据结构有清晰的理解。一旦你掌握了它，Workerman的潜力将为你完全释放。

Workerman协议使用中常见的误区与优化建议

在使用Workerman处理各种协议时，我发现有些误区是新手常犯的，同时也有一些经验性的优化建议，分享出来希望能帮大家少走弯路。

常见的误区：

Workerman只能用来做HTTP/WebSocket服务： 这是最普遍的误解。很多人看到Workerman的例子都是关于Web的，就以为它仅限于此。实际上，Workerman的强大之处在于它的通用性。我曾用它来做过私有的游戏服务器通信协议、物联网设备的数据收集服务，甚至是一个自定义的RPC框架。它能处理任何基于TCP/UDP的协议，只要你愿意去定义它。
自定义协议比HTTP/WebSocket更复杂，不值得尝试： 确实，自定义协议需要你花时间去设计和实现
```
input
```
登录后复制
、
```
decode
```
登录后复制
、
```
encode
```
登录后复制
方法，这比直接用HTTP库要多一些工作量。但对于一些对性能、延迟和数据包大小有严格要求的场景（比如高并发的游戏服务器、金融数据推送），自定义二进制协议的效率远高于基于文本的HTTP或WebSocket。它能大幅减少数据传输量和解析开销，带来显著的性能提升。不要因为“看起来复杂”就轻易放弃它。
协议设计时，忽略了粘包/分包问题： 这是网络编程的老大难问题。TCP是流式传输，不保证每次
```
recv
```
登录后复制
都能拿到一个完整的应用层数据包，甚至可能一次
```
recv
```
登录后复制
拿到多个小包拼接在一起（粘包），或者一个大包被拆分成多次
```
recv
```
登录后复制
（分包）。如果你在自定义协议的
```
input
```
登录后复制
方法中没有正确处理包的边界，就可能导致数据解析错误。务必在协议中加入包头长度字段或者明确的包结束符。

优化建议：

选择合适的协议：
- HTTP/WebSocket： 适合Web应用、前后端通信、API服务，易于调试和理解。
- 自定义文本协议： 适合内部服务间通信，对性能有一定要求但又希望易于调试的场景。记得加分隔符或长度头。
- 自定义二进制协议： 追求极致性能和带宽，对数据包大小敏感的场景。虽然开发调试略麻烦，但效率最高。使用
```
pack
```
  登录后复制
  /
```
unpack
```
  登录后复制
  处理二进制数据。
精简协议数据： 无论是哪种协议，尽量减少不必要的数据传输。对于自定义协议，如果可能，使用二进制格式而不是文本，可以大大减少数据量。例如，用一个字节表示状态码，而不是
```
"success"
```
登录后复制
或
```
"error"
```
登录后复制
字符串。
心跳机制（Keep-Alive）： 对于长连接协议（如WebSocket、自定义TCP协议），客户端和服务器之间最好有心跳机制。这不仅能保持连接活跃，防止NAT超时断开，还能帮助快速发现死连接，及时清理资源。心跳包的数据量应该非常小。
错误处理与日志： 任何协议在传输过程中都可能遇到错误，比如数据损坏、解析失败。在你的协议类中，尤其是在
```
decode
```
登录后复制
方法里，要考虑这些异常情况，并记录详细的日志，便于问题排查。
协议版本管理： 当你的应用迭代时，协议也可能需要升级。在协议设计之初，就应该考虑如何进行版本管理，比如在协议头中包含版本号，这样新旧客户端和服务端可以兼容或者优雅地拒绝不兼容的连接。