Nginx 的 epoll 不依赖 mmap 降低拷贝，其作用仅为高效通知就绪 fd；真正实现零拷贝的是 sendfile、splice 等机制，配合 sendfile on; 等配置优化数据路径。
Nginx 在 Linux 下使用 epoll 时，并不直接依赖内存映射（mmap）来降低数据拷贝。这是一个常见误解：epoll 本身是基于内核事件通知机制的 I/O 多路复用接口，它不涉及 mmap；而真正与“零拷贝”和减少数据拷贝相关的技术，是 sendfile、splice 和 tcp_nopush/tcp_nodelay 等机制。Nginx 会结合这些机制，在特定场景下绕过用户态内存拷贝，但 epoll 仅负责高效就绪事件通知。
epoll 的作用：高效获取就绪连接，不参与数据搬运
epoll 的核心价值在于替代 select/poll，以 O(1) 时间复杂度管理海量连接：
- 内核维护一个红黑树存储监听的 fd，一个就绪链表记录已触发事件的 fd
- 调用
epoll_wait()时，仅将就绪 fd 从内核链表复制到用户空间数组 —— 这次拷贝量极小（通常每个就绪事件仅 12 字节），与传输的数据量无关 - epoll 不读取 socket 接收缓冲区数据，也不写入发送缓冲区；它只告诉 Nginx “哪个 fd 可读/可写”
真正减少数据拷贝的技术：sendfile 与 splice
当 Nginx 提供静态文件服务（如 HTML、图片）时，为避免将文件内容从内核页缓存 → 用户态缓冲区 → socket 发送缓冲区的两次拷贝，它会启用：
- sendfile 系统调用：直接在内核空间把文件页缓存中的数据复制到 TCP 发送缓冲区，跳过用户态，实现“零拷贝”（实际是一次内核内拷贝，无用户态参与）
- splice 系统调用（需配合管道）：在支持 pipe 的场景下（如代理中转发响应体），可实现更彻底的零拷贝，数据在内核 buffer 间移动，完全不触碰用户内存
- Nginx 通过配置
sendfile on;和tcp_nopush on;启用并优化 sendfile 路径
为什么有人误以为 epoll 用了 mmap？
混淆可能源于以下事实：
- 某些高性能服务器（如部分自研网关）会用
mmap将大文件映射到进程地址空间，再配合writev或sendfile使用，但这属于应用层优化，与 epoll 无关 - Linux 的
epoll实现内部确实使用了内核内存池和高效数据结构，但这些对用户透明，且不对外暴露 mmap 接口 - DPDK 或 XDP 等旁路技术会大量使用 mmap 映射网卡 ring buffer，但那是完全绕过内核协议栈的方案，Nginx 默认不使用
Nginx 实际的数据路径优化要点
要真正降低拷贝开销，关键不在 epoll，而在请求类型和配置协同：
- 静态文件服务：启用
sendfile on;+tcp_nopush on;，让内核完成文件到 socket 的搬运 - 反向代理响应转发：Nginx 1.17.6+ 支持
proxy_buffering off;配合splice（需内核支持），实现响应体零拷贝中转 - 避免大 body 读取：用
client_max_body_size限制上传，防止 Nginx 将整个请求体读入用户态内存 - 利用内核 TCP 缓冲区：合理设置
net.ipv4.tcp_wmem和net.ipv4.tcp_rmem，减少分段与重传带来的额外拷贝
