mod_buffer不能减少网络小包发送次数，因其仅缓存响应体而不合并tcp包，真实发包由内核tcp栈、后端响应节奏及enablesendfile/setoutputfilter组合决定。
mod_buffer 并不能真正减少网络小包发送次数。
它只是缓存响应体，不干预 TCP 发包行为
mod_buffer 的作用是把响应内容暂存在内存或磁盘中，再按块刷出；但它不合并 TCP 段，也不影响内核的 Nagle 算法或 TCP_NODELAY 设置。真实发包节奏由以下因素决定：
- Linux 内核 TCP 栈对 write() 调用的处理方式
- 后端应用生成响应的节奏（例如 PHP 是否调用 flush()）
- 是否禁用 sendfile（EnableSendfile off）并配合 SetOutputFilter BUFFER
- 其他 filter 的优先级（如 mod_deflate 在前，buffer 就被跳过）
启用后常见问题与误判
很多情况下启用 mod_buffer 反而让性能变差，典型表现包括：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 日志出现 [buffer:warn] buffer overflow, discarding data：说明 BufferSize 太小，大响应直接被丢弃
- curl -v 仍看到 Transfer-Encoding: chunked：代表缓冲未生效，常因 filter 链顺序不对
- 抓包发现 PSH 标志频繁出现：说明应用层仍在主动 flush，mod_buffer 无法拦截
- 首字节延迟明显增加：因为必须攒够 BufferMin 才发，牺牲了响应及时性
真正有效的替代方案
若目标是减少小包、提升吞吐，应绕过 mod_buffer，从更底层或外围入手：
- 在后端代码中控制输出节奏，避免频繁 flush（如 PHP 关闭 implicit_flush、Python 使用 sys.stdout.buffer.write 后统一 flush）
- 前置部署 Nginx，并启用 tcp_nodelay off + tcp_cork on（注意二者互斥，cork 优先级更高），可合并响应头与正文为单个 TCP 段
- 反向代理场景下，关闭 Apache 的 sendfile 并启用 proxy_buffering，由 Nginx 统一做响应缓冲与合并
- 对静态文件服务，确保有明确 Content-Length 且禁用 chunked，配合 output_buffers 提升缓冲效率
缓冲机制本身依赖 filter 链、响应生成方式和 socket 缓冲区状态，非常脆弱。稳定控制发包，得从前端输出逻辑和代理层两头卡住，而不是指望 Apache 中间层做不可靠攒包。
