C

系列开篇就说过，Nginx 的所有功能都是模块提供的。前面的文章你看到了 HTTP 模块、Event 模块、Upstream 模块在各自领域的工作方式，现在是时候把视角拉回到模块系统本身，，看看 Nginx 的模块到底长什么样，静态模块怎么初始化，动态模块又是如何通过 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 管理。

前五篇我们从整体架构走到事件驱动和配置系统，现在终于到了最核心的 HTTP 处理层。这一篇拆解 Nginx 1.24.x 的 HTTP 模块体系与请求处理全流程，，从 ngx_http_module_t 接口到 11 阶段处理引擎，从请求解析到 filter 链。HTTP 模块是 Nginx 最重要（也最大）的子系统，全部源码约 7 万行，分布在 src/http/。

Nginx 的配置系统不是简单的 INI 解析，，它是一整套声明式 DSL，ngx_conf_parse() 递归地喂给 ngx_conf_handler()，后者根据指令名匹配模块、校验上下文和参数，最后调用模块注册的 set 回调填充配置结构体。今天把这套机制拆干净。