nginx异步事件驱动模型处理长连接的核心是单worker进程+非阻塞i/o+epoll事件通知，连接空闲时注册于epoll中挂起等待，不耗cpu、不轮询、不新建连接；超时由红黑树统一管理，keepalive_timeout和keepalive_requests控制待命时长与请求数上限，连接全程绑定单个worker，复用预分配的ngx_connection_t结构体与slab内存池。
长连接在事件循环里怎么“挂起”
当客户端发起 HTTP/1.1 请求并带上 Connection: keep-alive，且服务端也启用 keepalive，Nginx 不会在响应完就断开 TCP 连接，而是把该 socket 保留在 worker 的事件监听列表中。
此时 socket 处于“可读但无数据”状态，Nginx 不主动轮询，而是交由 epoll_wait() 挂起等待——内核一旦检测到新数据到达（比如客户端发来第二个请求），立刻唤醒 worker，触发读事件回调。整个过程不占 CPU、不切换线程、也不重新建连。
- 连接复用时，只重置 request 上下文和缓冲区，不重建 ngx_connection_t 结构体，直接从连接池中取用
- 空闲期间，socket 句柄始终注册在 epoll 实例里，但不消耗 worker 循环的处理时间
- 超时由红黑树统一管理，keepalive_timeout 到期后自动触发关闭流程，无需额外定时器线程
keepalive 相关参数如何影响事件调度
这些指令不是“开关”，而是告诉事件循环：这个连接能待多久、能接几单、什么情况下该放手。
- keepalive_timeout 65s：设置 socket 在无数据时最大挂起时间；到期后 epoll 会返回 EPOLLIN 或超时事件，worker 执行 FIN 关闭
- keepalive_requests 100：每处理完一个请求就计数，达到上限后强制关闭，防止单连接长期占用内存或积累异常状态
- client_header_timeout / send_timeout：分别约束请求头读取和响应发送阶段的等待窗口，避免慢客户端拖住事件槽位
连接池与内存复用支撑高密度长连接
worker 进程启动时就预分配好固定数量的连接结构（由 worker_connections 控制），所有长连接都从中复用。
- 每次 accept 新连接或复用 keepalive 连接，都只是重置已有 ngx_connection_t 结构体字段，不 malloc/new
- HTTP 请求解析使用 slab 分配器管理 buffer，头部字段以指针方式引用原始接收内存，避免字符串拷贝
- 静态文件响应走 sendfile()，数据直接从磁盘到 socket 发送队列，绕过用户态内存拷贝
多 worker 协同不抢连接，但各自管好自己的长连接
Nginx 默认启用 accept_mutex on，防止多个 worker 同时争抢新连接；而对已建立的长连接，每个 worker 独立维护自己的 epoll 实例和连接池，互不干扰。
- 一个长连接从建立到关闭，全程绑定在某个 worker 上，不会跨 worker 转移
- worker_processes 设置为 auto 或等于 CPU 核心数，确保每个核跑一个 worker，最大化利用多核
- 若后端也支持长连接（如 upstream.keepalive 32），Nginx 会复用到后端的连接，进一步减少握手开销
