nginx 采用单线程事件循环，依赖内核通知（epoll/kqueue）实现高效i/o；每个 worker 进程独享事件循环与连接管理，所有网络操作和超时任务统一由红黑树调度。
Nginx 的 Event Loop 不是靠多线程轮询或主动探测，而是用单线程+内核通知的方式，把网络 I/O 事件调度得又快又省资源。核心在于“被动等待、批量搬运、同步执行”——内核说哪个 socket 就绪了，它就处理哪个；不浪费 CPU 空转，也不卡住整个流程。
每个 worker 独享一个独立事件循环
master 进程 fork 出多个 worker，每个 worker 是一个独立进程，内部只跑一个 Event Loop。它不共享连接、不共享事件队列，彼此完全隔离：
- 监听 socket（如 port 80）在每个 worker 启动时，单独注册进各自的 epoll 实例
- 新 accept 到的客户端连接，只加入当前 worker 的事件监控范围
- worker_connections 配置限制的是单个 worker 能管多少连接，不是全局总数
依赖内核机制，只响应就绪通知
Nginx 不自己去检查 socket 是否可读/可写，而是让操作系统来“敲门”：
- Linux 下默认用 epoll（启用 EPOLLET 边缘触发），一次注册长期有效，只在状态变化时通知
- FreeBSD/macOS 用 kqueue，支持更细粒度的事件过滤
- select/poll 仅作兜底，性能差，基本不会被选中（可通过 nginx -V | grep -o 'epoll\|kqueue' 确认）
- 所有网络操作（accept/read/write/close）都被包装成事件，统一由 event loop 分发
事件分发走轻量映射与状态机驱动
收到内核返回的就绪 fd 列表后，Nginx 并不直接调业务逻辑，而是快速完成“翻译→定位→调用”三步：
- 从 epoll_event 提取 fd，查连接池映射表，找到对应的 ngx_connection_t 对象
- 根据事件类型（EPOLLIN/EPOLLOUT/EPOLLERR）触发对应 handler：
– 监听 fd 就绪 → 执行 ngx_event_accept
– 客户端 fd 可读 → 调 ngx_http_process_request_line 或后续读 body 的 handler
– 可写 → 触发 ngx_http_writer 发送响应 - handler 执行完，再决定是否重新注册事件（比如读完 header 后，再注册 body 读事件）
超时与定时任务也统一纳入调度
连接空闲超时、请求头读取超时等，并非另起线程或信号，而是和 I/O 事件一起管理：
- 所有超时时间存进红黑树，O(log n) 插入/删除，O(1) 查最近到期项
- 每次 event loop 迭代前，先检查红黑树里有没有超时事件，有则触发清理或关闭连接
- client_header_timeout、keepalive_timeout 等指令，最终都转化为红黑树节点自动注册
