Infra

系列开篇就说过，Nginx 的所有功能都是模块提供的。前面的文章你看到了 HTTP 模块、Event 模块、Upstream 模块在各自领域的工作方式，这一篇把视角收回到模块系统本身：模块长什么样，静态模块怎么初始化，动态模块怎样通过 dlopen 加载。 重点看四件事：ngx_module_t 字段、ngx_modules.c 生成逻辑、ngx_count_modules() 的索引分配、ngx_load_module() 的加载路径，以及 commands 数组怎样驱动配置解析器。

Nginx 以事件驱动模型闻名，核心 worker 进程是一个单线程事件循环。但网络 I/O 之外还有一类阻塞操作，磁盘 I/O、gzip 压缩、SSL 握手，它们会卡住整个事件循环。这篇我们从源码角度拆解 Nginx 1.24.x 如何用线程池和异步 I/O 两条路径来解决这个矛盾。

前面我们分析了 Nginx 事件循环的核心骨架，，ngx_process_events_and_timers() 是每个 worker 进程里的主循环函数。不过之前一直留了一个坑：传给 epoll_wait 的超时时间 timer 是怎么算出来的？超时后事件怎么处理？ 这一篇就来填这个坑。Nginx 的定时器系统用红黑树管理所有事件超时，逻辑写得很紧凑，总共不到 300 行。

响应 1000 并发静态文件请求时，单进程 CPU 都花在哪？大部分在拷贝上：磁盘→内核→用户→内核→网卡。每一跳都是宝贵的内存带宽和 CPU 缓存污染。Nginx 用两类手段解决：一是 sendfile 零拷贝，完全绕过用户态；二是在必须拷贝的地方，用 ngx_buf_t / ngx_chain_t 这套设计把拷贝量压到最低，且让 buffer 在 filter 链中复用。

前几篇文章我们聊了事件驱动和内存池，这次来看连接管理。连接是 Nginx 处理所有请求的起点，从 accept 到 close 的完整生命周期都在 src/core/ngx_connection.c 和 src/event/ngx_event_accept.c 中实现。理解这套机制，就理解了 Nginx 为什么能在亿级连接下保持稳定。

Nginx 反向代理的核心是 upstream 模块。它负责从上游服务器池中选出一个 peer，建立 TCP 连接，转发请求，接收响应，然后回传给客户端。整个流程涉及连接管理、超时控制、负载均衡调度和事件驱动的 I/O 管理。