静态文件服务是Nginx最经典的用途之一。无论是图片站、下载站还是前端静态资源分发，Nginx都能在单机上万并发的情况下保持极低的CPU占用，这背后的功臣之一就是sendfile机制。很多面试官也喜欢问：sendfile到底快在哪里？为什么它能减少拷贝次数？要回答这些问题，得先从传统文件传输的完整流程说起。
传统的read/write方式到底慢在哪里
在没有sendfile之前，如果我们要把磁盘上的一个文件通过网络发送出去，应用层的典型写法是：先调用read把文件内容读到用户态缓冲区，再调用write把数据写入socket。看起来只有两次系统调用，但操作系统内部做的事情远比这多。
整个流程展开来看是这样的：首先read调用会陷入内核态，DMA引擎把数据从磁盘拷贝到内核的页缓存（Page Cache），接着CPU把数据从内核缓冲区拷贝到用户态的堆内存；然后write又触发一次内核态切换，CPU再把用户态缓冲区的数据拷贝到socket的发送缓冲区；最后由DMA把数据从socket缓冲区搬运到网卡。整个过程中，数据一共经历了4次拷贝（其中2次由DMA完成，2次由CPU完成），同时伴随着4次用户态与内核态的上下文切换。更糟糕的是，这些数据在用户态的停留毫无必要——应用根本不关心文件内容是什么，它只是一个搬运工。
CPU参与的拷贝是纯粹的浪费：它占用CPU周期，抢占内存带宽，还要因为上下文切换产生缓存失效。当并发量上来之后，这些开销会被成倍放大，这就是传统方式处理静态文件时性能上不去的根本原因。认清这个瓶颈之后，sendfile的设计目标就很清晰了：能不能让数据完全不经过用户态，直接在内核里从文件搬到网卡？
sendfile零拷贝的底层原理
Linux从2.4版本开始提供sendfile系统调用，它的函数签名非常简洁：
#include <sys/sendfile.h> ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); // out_fd: 目标文件描述符（必须是socket） // in_fd: 源文件描述符（必须支持mmap类操作，即普通文件）
调用sendfile(fd_socket, fd_file, &offset, count)之后，用户态和内核态之间只发生一次系统调用的切换，数据流转路径变成：DMA把数据从磁盘读到页缓存，内核直接把页缓存中的数据描述信息（文件描述符、内存地址、长度）挂到socket缓冲区，最后DMA gather操作根据这些描述信息直接从页缓存读取数据发往网卡。这样一来，CPU参与的拷贝从2次降到了0次，只剩下DMA完成的硬件搬运，上下文切换也从4次减少到2次。这就是所谓的零拷贝——指的是CPU拷贝次数为零，而不是完全没有数据移动。
值得注意的是，sendfile的in_fd在较老的内核上要求必须是普通文件，out_fd必须是socket，这个限制在2.6.33之后有所放宽。另外，零拷贝并非只有sendfile一条路，mmap配合write、splice、tee等系统调用也能达到类似效果，但sendfile因为使用最简单，成了Nginx这类静态文件服务器的首选。可以简单对比一下几种方式的开销差异：
| 传输方式 | CPU拷贝次数 | DMA拷贝次数 | 上下文切换 |
|---|---|---|---|
| read + write | 2 | 2 | 4 |
| mmap + write | 1 | 2 | 4 |
| sendfile | 1 | 2 | 2 |
| sendfile + DMA gather | 0 | 2 | 2 |
Nginx中sendfile指令的配置与使用
Nginx通过sendfile指令来开启这一机制，配置非常简单：
http {
sendfile on; # 开启零拷贝传输，默认关闭
tcp_nopush on; # 配合sendfile，尽量等数据包攒满后再发送
tcp_nodelay on; # 对keepalive连接禁用Nagle算法，降低小包延迟
server {
listen 80;
location /download/ {
sendfile on;
sendfile_max_chunk 512k; # 单次调用传输的最大块，防止大文件占用io过久
}
}
}
tcp_nopush和sendfile是一对好搭档。它的作用是启用TCP_CORK选项，让内核在发送响应头和文件内容的头几个包时尽量把数据攒满一个MSS再发出去，这样能减少小包数量、提升网络利用率。而tcp_nodelay是相反的思路，它禁用Nagle算法让小数据立即发出，两者看似矛盾，实际可以同时开启：Nginx会在不同的发送阶段自动切换策略——大文件传输用CORK攒包，交互性小数据用nodelay立刻发送。
sendfile_max_chunk则是一个容易被忽略的调优点。如果没有这个限制，一个超大文件的单次sendfile调用可能长时间独占worker进程，导致同进程内的其他连接被阻塞。设置成512k左右，可以让worker在传输大文件时定期让出执行机会，提升整体公平性。另外要清楚，sendfile优化的是文件到socket的直接搬运，如果location中配置了需要读取或修改响应体的逻辑，比如sub_filter替换、gzip压缩，sendfile就会自动失效，回退到传统方式，这是排查性能问题时必须留意的细节。
sendfile并非万能：适用场景与注意事项
sendfile的优势场景很明确：文件内容不需要任何加工、直接原样发送的静态资源服务，例如图片、CSS、JS、安装包下载。这类场景下开启sendfile通常能带来明显的吞吐提升，特别是大文件传输时CPU占用的下降会非常直观。
但它也有不适用的情况。第一，前面提到的压缩场景，gzip开启后数据必须经过用户态处理，零拷贝路径走不通；第二，在NFS等网络文件系统上，sendfile的表现可能反而不如预期，因为数据源本身不在本地页缓存中，内核需要额外处理；第三，极小的文件配合高并发短连接时，sendfile的收益有限，此时连接建立和TLS握手的开销才是主要矛盾，更应该关注keepalive和HTTP/2的配置。
总的来说，sendfile是理解操作系统I/O优化的一扇很好的窗口。它体现了Unix设计哲学中一条重要原则：如果中间人不需要处理数据，就别让数据经过中间人。把这条思路延伸开去，你会发现在Kafka的日志存储、RocketMQ的消息刷盘、各种RPC框架的大文件传输模块里，零拷贝思想无处不在。搞懂sendfile的原理，不只是会配一行Nginx指令，更是掌握了分析I/O性能问题的一把通用钥匙。
Nginx sendfile零拷贝文件传输优化修改时间：2026-09-11 22:18:44