Nginx高效处理数万并发连接的核心在于非阻塞I/O与内存池机制的协同设计：前者通过epoll/kqueue实现单worker管理多连接，后者通过请求级内存池复用与整池重置消除malloc/free开销。
Nginx 之所以能高效处理数万并发连接，核心在于它将非阻塞 I/O 模型与内存池（memory pool）机制深度结合，从系统调用和内存管理两个层面压低单连接开销。这不是简单叠加，而是协同设计：非阻塞 IO 避免线程/进程阻塞等待，内存池则避免高频 malloc/free 带来的锁竞争与碎片。
非阻塞 IO 让连接“不占线程”
传统阻塞模式下，每个连接需独占一个线程或进程，等待 read/write 完成时 CPU 空转；Nginx 使用 epoll（Linux）或 kqueue（BSD）等事件驱动接口，把所有活跃连接注册到内核事件表中。内核只在数据就绪、连接建立或对端关闭时通知 Nginx，worker 进程可轮询处理多个连接，无需为每个连接分配栈空间或调度资源。
- 一个 worker 进程默认可管理数万连接，实际瓶颈常在内存与文件描述符限制，而非 CPU 调度
- 连接处于“空闲等待”状态时不消耗 CPU，也不阻塞其他请求处理
- 需配合 multi_accept off 或 on 合理控制单次 accept 数量，防止饥饿
内存池让每次分配“零成本”
Nginx 不在处理每个请求时调用 malloc/free，而是在请求生命周期开始时，从预分配的内存池中划出一块连续区域；所有临时变量、header 缓冲、字符串拷贝都复用这块内存；请求结束时，整块池直接重置（reset），而非逐个释放——没有 free 开销，也无碎片风险。
- 每个 HTTP 请求对应一个独立内存池（ngx_pool_t*），生命周期与 request 绑定
- 池内分配使用小块内存（如 header buffer 默认 4k），支持快速 palloc（对齐分配）和 pcalloc（清零分配）
- 大对象（如响应体）可单独用 ngx_alloc（mmap/malloc），但不纳入池管理，避免池膨胀
连接与请求内存分离，精准控制粒度
Nginx 将连接（ngx_connection_t）和请求（ngx_http_request_t）内存严格分层：连接结构体长期存在（直到 TCP 断开），仅保存 socket、地址、读写事件等轻量字段；而完整 HTTP 解析、变量、重写逻辑所需的内存，全部挂载在请求级内存池下——连接空闲时，请求池已销毁，内存立即回收。
- 启用 keepalive 时，一个连接可承载多个请求，每个请求都有自己的池，互不干扰
- client_header_timeout 和 client_body_timeout 控制请求级池的存活上限，防慢速攻击耗尽内存
- 可通过 large_client_header_buffers 调整头部缓冲区大小，避免因 header 过大触发额外内存分配
调优建议：从配置看内存实效
内存占用不是越小越好，而要匹配业务特征。以下配置直接影响每连接平均内存消耗：
- worker_connections：设为 ulimit -n 的 70%~80%，留余量给日志、临时文件等
- client_header_buffer_size 和 large_client_header_buffers：多数场景 1k + 4×4k 足够，避免为兼容异常请求盲目放大
- client_body_buffer_size：若不代理大文件上传，保持默认 8k 即可；否则考虑用 client_max_body_size 限流 + 后端流式处理
- 关闭不用模块（如 --without-http_rewrite_module），减少请求池中未使用字段的隐式开销
