socket_buffer_size不会导致网络层丢包，仅限制swoole服务端每个tcp连接的内存发送缓冲区大小；超限后send()失败、返回false或触发onerror，属应用层“假丢包”，非真实网络丢包。
socket_buffer_size 不会直接导致网络层丢包
它只影响 Swoole Server 端的内存缓冲区，和网卡、驱动、IP 层这些真正“丢包”的环节无关。所谓“丢包”错误如 swFactoryProcess_finish:send failed,session#1 output buffer has been overflowed，本质是 Swoole 主动拒绝继续写入——因为 socket_buffer_size 限制已满，不是数据在路上被丢，而是根本没发出去。
它真正引发的是应用层“假丢包”或连接中断
当客户端接收慢（比如弱网、高延迟、处理卡顿），而服务端持续调用 $server->send()，数据就会堆积在 Swoole 的发送缓冲区内。一旦超过 socket_buffer_size 阈值：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Server 立即停止向该连接写入，
send()返回 false 或触发onError - 连接不会自动断开，但后续
send()全部失败，业务逻辑若无重试/降级，就表现为“消息发不出去” - 若客户端长期不读、服务端又不断尝试 send，最终可能触发
ECONNRESET（对端关闭 socket 后再写）
和系统级 TCP 缓冲区（net.ipv4.tcp_wmem）的关系
socket_buffer_size 是 Swoole 自己维护的一层内存缓冲，位于 PHP 层和内核 socket 之间；而 net.ipv4.tcp_wmem 是内核 TCP 栈的发送窗口缓冲区。两者是串联关系：
- Swoole 缓冲区满 → 不再调用
send()→ 内核缓冲区不会被填满 - 若 Swoole 缓冲区设得过大（如 128MB），而客户端极慢，所有待发数据全堆在 PHP 进程内存里 → RSS 暴涨 → OOM 杀进程（见 Swoole 5.x 红皮书案例）
- 调大
net.ipv4.tcp_wmem并不能缓解 Swoole 缓冲区溢出，因为 Swoole 在调用系统send()前就自己拦下了
UDP 场景下 socket_buffer_size 完全无效
Swoole 的 socket_buffer_size 仅作用于 TCP/UnixSocket 类型连接。UDP 是无连接、无缓冲区语义的协议：
- UDP socket 没有发送缓冲区概念，
sendto()成功返回只表示数据交给了内核协议栈（链路层 output queue） - Swoole 不会对 UDP 连接做
socket_buffer_size限制，配置项会被忽略 - UDP 真正的“丢包”发生在：接收缓冲区满（
net.core.rmem_max）、网卡 Ring Buffer 溢出、或 IP 分片丢失 —— 和这个配置毫无关系
socket_buffer_size 是按每个连接单独计算的，10 万并发 × 2MB 就是 200GB 内存占用。很多团队调高它只为“扛住突发流量”，却忘了它不解决下游消费能力问题，反而把压力从网络转移到了内存。
