在 nginx 中配置 sendfile 机制，需要在 events 块中确保启用 epoll 模型（linux 下默认），并在 http 块中使用 sendfile on; 指令开启该功能。这一组合能让 nginx 在内核态直接传输文件数据，避免用户态与内核态之间的频繁拷贝，从而显著提升静态文件服务的性能。
为什么必须在 events 块中配置 epoll？
因为 sendfile 的高效运行依赖于底层的 I/O 多路复用模型。在 Linux 系统中，Nginx 必须使用 epoll 才能配合 sendfile 实现非阻塞的高并发处理。如果 events 块中没有显式或隐式指定 use epoll;，Nginx 可能会回退到 select 或 poll，这会限制并发连接数并降低整体吞吐量。
# nginx.conf
events {
worker_connections 1024;
use epoll; # 关键：明确指定使用 epoll 模型以支持 sendfile
}
http {
server {
listen 80;
server_name localhost;
location /static/ {
root /var/www/html;
sendfile on; # 开启 sendfile
tcp_nopush on; # 配合 sendfile 优化数据包发送
}
}
}
上述配置中，use epoll; 确保了事件循环的高效性，而 sendfile on; 则告诉 Nginx 在处理静态文件时调用系统的 sendfile() 系统调用。这两个配置共同作用，使得文件数据直接从磁盘缓冲区流向网络缓冲区，无需经过用户空间。
sendfile 与 tcp_nopush 的配合效果如何？
sendfile 通常与 tcp_nopush 配合使用以达到最佳性能。tcp_nopush 的作用是当 sendfile 传输完一个 HTTP 响应头后，强制将响应头和文件数据的首部分一起发送，减少网络包的数量。这种组合能有效降低网络延迟并提高带宽利用率。
# nginx.conf
http {
# ... 其他配置 ...
server {
listen 80;
server_name localhost;
location /static/ {
root /var/www/html;
sendfile on;
tcp_nopush on; # 优化：合并头部和数据首块
tcp_nodelay on; # 可选：对于小文件或实时数据，可保持低延迟
}
}
}
在这个配置中，tcp_nopush on; 会在 sendfile 开始传输文件之前，等待 HTTP 响应头完全准备好，然后将头和文件的第一个数据块打包成一个 TCP 包发送。这减少了网络拥塞控制算法中的“小包”问题，提升了大文件传输的效率。注意，tcp_nodelay 通常用于即时通信场景，而在静态文件服务中，tcp_nopush 是更合适的选择。
sendfile 在什么情况下会失效或需要关闭？
sendfile 并非在所有场景下都适用。当 Nginx 需要对文件内容进行动态修改（如通过 satisfy 或 auth_request 进行认证）或使用 proxy_pass 代理后端服务时，sendfile 可能无法直接使用或需要特殊处理。此外，在某些 NFS 挂载的文件系统上，sendfile 可能表现不佳甚至出错，此时应将其设置为 off。
# nginx.conf
http {
server {
listen 80;
server_name localhost;
location /dynamic/ {
# 如果内容需要动态处理，sendfile 可能不适用
# 或者在 NFS 环境下，可能需要关闭 sendfile
sendfile off;
alias /var/www/dynamic/;
}
}
}
在上述配置中，location /dynamic/ 下的 sendfile off; 确保了即使在该目录下有静态文件，Nginx 也会通过传统的 read/write 方式读取文件，以便后续可能的动态处理逻辑能够正确介入。这种细粒度的控制允许管理员根据具体路径的需求调整 sendfile 的行为。
