Webman跨应用RPC通信压低延迟的核心是禁用文本协议、避免重复建连、绕过HTTP中间层、控制服务端监听范围；采用tinywan/rpc二进制模式+连接池+内网直连，P95延迟可稳定在8–12ms。
Webman 跨应用 RPC 通信要压低延迟，核心不是换协议，而是砍掉所有非必要开销：禁用文本协议、避免重复建连、绕过 HTTP 中间层、控制服务端监听范围。直接用 tinywan/rpc 的二进制模式 + 连接池 + 内网直连，P95 延迟可稳定在 8–12ms（千兆内网，单次小包调用）。
为什么不用 text:// 协议而必须切 binary://
text:// 是 JSON 明文 + 换行符分隔，每次调用都要走 json_encode/json_decode，PHP 字符串解析开销大，且无法压缩字段名。binary:// 使用自定义二进制帧头 + 序列化后的紧凑结构，实测同等请求体体积减少 65%，反序列化耗时下降约 40%。
-
listen_text_address改为listen_binary_address，例如'listen_binary_address' => 'binary://0.0.0.0:9512' - 客户端必须改用
Tinywan\Client构造时传binary协议：new Client('binary://10.0.1.5:9512') - 服务类方法返回值不能含资源句柄、闭包或不可序列化对象，否则 binary 编码会静默失败
连接池怎么配才不卡住请求
默认每次 Client 实例都新建 socket 连接，高并发下会快速打满本地端口并触发 TIME_WAIT，延迟毛刺明显。必须复用连接，但 tinywan/rpc 不自带连接池，得自己兜底。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 用
Swoole\Coroutine\Channel管理预创建的Client实例，容量建议设为服务端 CPU 核数 × 2 - 每次调用前从 channel 获取 client，用完立即
push回去，不要unset或close - client 实例需设置超时：
$client->setTimeout(3.0)，避免某次网络抖动拖垮整条链路 - 不要在
onWorkerStart里一次性 new 所有 client——Swoole worker 进程是 fork 出来的，每个进程要独立建池
多机部署时地址写错的三个典型表现
服务端监听 127.0.0.1、客户端连错端口、防火墙拦截，这三类错误在日志里几乎不报具体原因，只体现为 fgets() 阻塞或返回空字符串。
- 服务端启动后，用
netstat -tuln | grep :9512确认监听的是*:9512或具体内网 IP，不是127.0.0.1:9512 - 客户端地址必须带协议和端口：
binary://10.0.1.5:9512，写成10.0.1.5或binary://10.0.1.5都会 silently fail - 跨主机务必关掉 SELinux（
setenforce 0）并检查iptables -L -n | grep 9512，很多生产环境默认 DROP 所有非 80/443 入向
延迟突然升高时优先查哪三件事
不是代码逻辑问题，90% 是基础设施层抖动。别急着改服务类，先盯住这三项：
- 用
ping -c 5 10.0.1.5和mtr --report 10.0.1.5看内网丢包和跳数，交换机微突发会导致 TCP 重传 - 检查服务端机器的
ss -s输出，若memory行显示used接近limit，说明 socket 缓冲区被打满 - 确认客户端所在机器没开
tcp_tw_reuse（sysctl net.ipv4.tcp_tw_reuse），短连接密集场景下这个参数不启用会导致端口耗尽
