nginx高并发核心在于少量worker进程+非阻塞i/o+事件驱动模型，通过epoll/kqueue高效监听海量socket就绪状态，recv/send立即返回避免阻塞，事件循环调度连接全生命周期，并辅以超时控制、sendfile优化及系统级调优。
Nginx 的高并发读写能力，核心不在“多开进程”，而在于用少量 worker 进程 + 非阻塞 I/O + 事件驱动模型，把每个 socket 当成一个待响应的状态机来调度。它不等数据，只看就绪；不占线程，只轮事件。
用 epoll/kqueue 管理海量连接，不靠轮询空耗 CPU
Linux 默认启用 epoll，FreeBSD/macOS 用 kqueue，它们能高效监听成千上万个 socket 的读写就绪状态。关键点是：
- socket 必须设为非阻塞模式：recv()/send() 立即返回，无数据时返回 EAGAIN/EWOULDBLOCK，Nginx 就转去处理其他就绪事件
- 事件循环统一调度整个连接生命周期：TCP 握手完成 → 触发 accept；客户端慢发 header → 每次 read 返回 EAGAIN 后继续监听 EPOLLIN；后端响应就绪 → 触发 EPOLLOUT 续发数据
- 避免传统轮询（如 select/poll）的 O(n) 扫描开销，epoll 是 O(1) 就绪事件通知
合理配置超时与缓冲，防慢连接拖垮资源
非阻塞本身不能无限兜底，必须配合策略性限制：
- client_header_timeout / client_body_timeout：分别控制请求头、请求体上传的最大等待时间（如 10s），超时断连，防 Slowloris 类攻击
- send_timeout：向客户端发送响应时，两次 write 之间的最大间隔（如 30s），避免因接收方太慢长期占用连接
- keepalive_timeout：空闲长连接保持时间（建议 15–60s），及时释放不再活跃的 fd
- buffer 大小按需设：client_header_buffer_size 通常 1k 足够；client_body_buffer_size 对 API 接口设 8k，对文件上传可调至 16–64k；过大反而增加延迟和内存压力
静态小文件读取：绕过用户态，直通内核缓存
高频小文件（CSS/JS/图标）不是靠“更快读磁盘”，而是减少拷贝与系统调用：
- 启用 sendfile on：让内核直接从 page cache 复制到 socket 缓冲区，跳过用户空间，省两次 copy + 两次上下文切换
- 搭配 tcp_nopush on：使 sendfile 数据尽可能填满 TCP 报文段，减少包数量
- 启用 open_file_cache：缓存 stat()/open() 结果（如 max=10000 inactive=60s），大幅降低元数据系统调用频率
- 关闭不必要的 access_log：尤其在 CDN 边缘或纯静态服务中，避免每次请求都触发日志写入
系统与 Nginx 协同调优，打通全链路瓶颈
Nginx 再高效，也受限于操作系统层资源：
- 调大系统文件描述符上限：ulimit -n 65535，并在 nginx.conf 中配 worker_rlimit_nofile 65535
- 确保 worker_connections × worker_processes ≤ ulimit -n，否则 epoll 监听失败
- worker 进程绑定 CPU 核：worker_cpu_affinity auto（1.19.10+）或手动指定，减少跨核缓存失效
- 确认使用 epoll：nginx -V 2>&1 | grep epoll，确保编译时含 --with-epoll_module
