Swoole Unix Socket 本地通信面试要点总结
时间：2026-06-26 06:45
本地进程间通信优先用UnixSocket，绕过内核协议栈，QPS高15%～20%，延迟低一半。SwooleHttpServer支持（端口传0），SwooleServer不支持。客户端用stream_socket_client连接，启动前清理残留socket文件。onConnect中无法获取真实IP，需用client_id标识。
在本地进程间通信场景下，应优先选择Unix Socket（例如unix:///tmp/swoole.sock）。这是因为Unix Socket直接绕过内核网络协议栈，无需进行IP与端口校验，同时支持文件系统权限控制。实际测试表明，使用Unix Socket可将QPS提升15%至20%，并将延迟降低一半。而TCP协议（如127.0.0.1:9501）仅适用于跨容器通信或调试需求。
首先，我们需要明确一个核心结论：在进行本地进程间通信时，应优先采用 Unix Socket（路径如 `unix:///tmp/swoole.sock`）。这并非是因为它听起来更高级，而是因为Unix Socket能够直接绕过内核网络协议栈，省去IP和端口校验环节，同时提供完全可控的文件系统权限。实际性能测试数据显示，相比TCP，Unix Socket的QPS可提升15%到20%，延迟降低约一半。而TCP（例如 `127.0.0.1:9501`）仅在需要跨容器通信或调试场景下使用。请务必打破“本地通信就使用loopback”的惯性思维。
这里有一个常见的陷阱：当启动 `SwooleHttpServer` 时，如果写成 `new SwooleHttpServer('unix:///tmp/app.sock', 0)`，请务必注意端口号必须为 `0`，否则Swoole会抛出 `Invalid port` 错误。然而，`SwooleServer`（原生TCP模式）并不识别 `unix://` 前缀，混用会导致程序直接崩溃，没有任何缓冲余地。
整理一下关键点：
* `SwooleHttpServer` 和 `SwooleWebSocketServer` 均支持 Unix Socket：构造时，host 参数传递文件路径，port 参数固定为 `0`。
* `SwooleServer`（原始服务器类）不支持 Unix Socket。强行传入将导致 `Segmentation fault`，请勿尝试。
* 路径权限需要正确设置：可以执行 `chmod 777 /tmp/swoole.sock` 或者使用 `chown www-data:www-data` 指定运行用户，否则worker启动时会因 `Permission denied` 而卡住。
客户端连接Unix Socket的三种方式与常见陷阱
PHP客户端连接Unix Socket最可靠的方法是使用 `stream_socket_client()`。不要依赖 `curl` 或 `file_get_contents()`，因为它们默认仅支持HTTP协议，解析Unix Socket路径时会失败，并抛出令人困惑的 `Protocol not supported` 错误。
来看一个正确示例：
$client = stream_socket_client('unix:///tmp/swoole.sock', $errno, $errstr, 3);
if (!$client) {
throw new RuntimeException("connect failed: {$errstr}");
}
fwrite($client, "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n");
echo fread($client, 8192);
fclose($client);
以下是几个需要特别注意的关键细节：
* 路径前缀必须为 `unix://`，两个斜杠不可缺失。缺少任何一个斜杠，PHP会将其当作本地文件处理，导致 `No such file or directory` 错误。
* `curl` 也可用于连接Unix Socket，但需添加 `--unix-socket /tmp/swoole.sock` 参数。同时，服务端必须返回标准的HTTP响应头，否则curl会处理失败。
* 如果使用 `SwooleClient`，则必须将类型设置为 `SWOOLE_SOCK_UNIX_STREAM`，避免习惯性地写成 `SWOOLE_SOCK_TCP`，类型错误将导致整个连接无效。
为什么onConnect回调中无法获取客户端真实地址
由于Unix Socket本质上是本地通信，不存在IP地址的概念。因此，在 `onConnect` 回调中调用 `$server->getClientInfo($fd)` 时，返回的数组中的 `remote_ip` 和 `remote_port` 将分别为空字符串和 `0`。这并不是程序缺陷，而是设计使然——底层根本没有存储这些信息的打算。
那么如何区分多个客户端？常见的做法是让客户端在建立连接时发送一个唯一标识，例如JWT token或 `client_id`。此外，也可以使用 `getpeername()` 提取socket文件路径的inode，但该方法不够稳定，不推荐使用。
几个实战经验：
* 不要在 `onConnect` 回调中进行IP白名单校验，该逻辑应前置到客户端身份协商阶段。
* 在 `onReceive` 回调中收到的首个数据包，应强制要求包含 `client_id` 字段。服务端接收到后将其存储到 `$server->connections[$fd]` 中，以便后续随时调用。
* 如果仍需追踪来源，可在客户端连接之前使用 `posix_getpid()` 记录日志，然后与服务端的 `$fd` 进行关联分析。尽管方法略显笨拙，但切实可行。
重启服务时遭遇Address already in use如何解决
Unix Socket文件不会随进程退出而自动删除。残留的 `/tmp/swoole.sock` 文件会导致新进程执行bind操作时失败，并报出 `Address already in use` 错误。请注意，这并非端口被占用，而是文件锁残留所致，二者本质不同。
解决方案也不复杂：
* 在启动前添加清理代码：`if (file_exists('/tmp/swoole.sock')) { unlink('/tmp/swoole.sock'); }`。
* 更稳妥的做法是将 `unlink` 操作放在 `onStart` 回调中执行，以避免多worker之间的竞态条件。同时，将 `reusable` 设置为 `false`，防止多个master进程同时删除同一文件。
* 排查问题时，不要使用 `lsof -U | grep swoole`，因为Unix Socket不走netstat和lsof的socket表。正确的做法是直接检查文件是否存在：`ls -l /tmp/swoole.sock`。
真正棘手的情况在于热更新场景：旧worker尚未完全退出，新master却急于执行bind操作。此时仅靠 `unlink` 已不足够，需要结合 `max_request` 配置与优雅重启的信号机制，合理控制进程生命周期，才能避免服务崩溃。
