服务器响应一个http请求的步骤

1. 把磁盘文件读入内核缓冲区
2. 从内核缓冲区读到内存
3. 处理（静态资源不需处理）
4. 发送到网卡的内核缓冲区（发送缓存）
5. 网卡发送数据

　　数据从第一步中的内核缓冲区到第四步的内核缓冲区白白绕了一个圈，没有任何变化浪费了时间 而sendfile系统调用就是来解决这个问题的。sendfile省略了上面的 2、3步，磁盘文件被直接发送到了网卡的内存缓冲区，减少了数据复制和内核态切换的开销 。

　　如果不用sendfile，网络的传输流程

read(file, tmp_buf, len);
write(socket, tmp_buf, len);

硬盘 >> kernel buffer >> user buffer >> kernel socket buffer >> 协议栈

1. 系统调用 read() 产生一个上下文切换：从 user mode 切换到 kernel mode，然后 DMA 执行拷贝，把文件数据从硬盘读到一个 kernel buffer 里。
2. 数据从 kernel buffer 拷贝到 user buffer，然后系统调用 read() 返回，这时又产生一个上下文切换：从kernel mode 切换到 user mode。
3. 系统调用 write() 产生一个上下文切换：从 user mode 切换到 kernel mode，然后把步骤2读到 user buffer 的数据拷贝到 kernel buffer（数据第2次拷贝到 kernel buffer），不过这次是个不同的 kernel buffer，这个 buffer 和 socket 相关联。
4. 系统调用 write() 返回，产生一个上下文切换：从 kernel mode 切换到 user mode（第4次切换了），然后 DMA 从 kernel buffer 拷贝数据到协议栈（第4次拷贝了）。

　　上面4个步骤有4次上下文切换，有4次拷贝，我们发现如果能减少切换次数和拷贝次数将会有效提升性能。在kernel 2.0+ 版本中，系统调用 sendfile() 就是用来简化上面步骤提升性能的。sendfile() 不但能减少切换次数而且还能减少拷贝次数。

再来看一下用 sendfile() 来进行网络传输的过程

sendfile(socket, file, len);

硬盘 >> kernel buffer (快速拷贝到kernel socket buffer) >> 协议栈

1. 系统调用 sendfile() 通过 DMA 把硬盘数据拷贝到 kernel buffer，然后数据被 kernel 直接拷贝到另外一个与 socket 相关的 kernel buffer。这里没有 user mode 和 kernel mode 之间的切换，在 kernel 中直接完成了从一个 buffer 到另一个 buffer 的拷贝。
2. DMA 把数据从 kernel buffer 直接拷贝给协议栈，没有切换，也不需要数据从 user mode 拷贝到 kernel mode，因为数据就在 kernel 里。

　　步骤减少了，切换减少了，拷贝减少了，自然性能就提升了。这就是为什么说在 Nginx 配置文件里打开 sendfile on 选项能提高 web serve r性能的原因

普通read，write

　　为了更好的理解不用sendfile代码所涉及的操作，请看图1。图的上半部展示了上下文切换，而下半部展示了复制操作。请看图一

　　上图所经历了四步

1. 系统调用read导致了从用户空间到内核空间的上下文切换。DMA模块从磁盘中读取文件内容，并将其存储在内核空间的缓冲区内，完成了第1次复制。
2. 数据从内核空间缓冲区复制到用户空间缓冲区，之后系统调用read返回，这导致了从内核空间向用户空间的上下文切换。此时，需要的数据已存放在指定的用户空间缓冲区内(参数tmp_buf)，程序可以继续下面的操作。系统调用write导致从用户空间到内核空间的上下文切换。数据从用户
3. 空间缓冲区被再次复制到内核空间缓冲区，完成了第3次复制。不过，这次数据存放在内核空间中与使用的socket相关的特定缓冲区中，而不是步骤一中的缓冲区。
4. 系统调用返回，导致了第4次上下文切换。第4次复制在DMA模块将数据从内核空间缓冲区传递至协议引擎的时候发生，这与我们的代码的执行是独立且异步发生的。你可能会疑惑：“为何要说是独立、异步？难道不是在write系统调用返回前数据已经被传送了？write系统调用的返回，并不意味着传输成功——它甚至无法保证传输的开始。调用的返回，只是表明以太网驱动程序在其传输队列中有空位，并已经接受我们的数据用于传输。可能有众多的数据排在我们的数据之前。除非驱动程序或硬件采用优先级队列的方法，各组数据是依照FIFO的次序被传输的(图1中叉状的DMA copy表明这最后一次复制可以被延后)。

　　上面的过程中存在很多的数据冗余。某些冗余可以被消除，以减少开销、提高性能。某些硬件支持完全绕开内存，将数据直接传送给其他设备的特性。这一特性消除了系统内存中的数据副本，因此是一种很好的选择，但并不是所有的硬件都支持。此外，来自于硬盘的数据必须重新打包(地址连续)才能用于网络传输，这也引入了某些复杂性。为了减少开销，我们可以从消除内核缓冲区与用户缓冲区之间的复制入手。

用mmap共享内存

　　消除复制的一种方法是将read系统调用，改为mmap系统调用

tmp_buf = mmap(file, len);
write(socket, tmp_buf, len);

　　为了更好的理解这其中设计的操作，请看图2。上下文切换部分与图1保持一致。

1. mmap系统调用导致文件的内容通过DMA模块被复制到内核缓冲区中，该缓冲区之后与用户进程共享，这样就内核缓冲区与用户缓冲区之间的复制就不会发生。
2. write系统调用导致内核将数据从内核缓冲区复制到与socket相关联的内核缓冲区中。
3. DMA模块将数据由socket的缓冲区传递给协议引擎时，第3次复制发生。

　　通过调用mmap而不是read，我们已经将内核需要执行的复制操作减半。当有大量数据要进行传输是，这将有相当良好的效果。然而，性能的改进需要付出代价的;是用mmap与write这种组合方法，存在着一些隐藏的陷阱。例如，考虑一下在内存中对文件进行映射后调用write，与此同时另外一个进程将同一文件截断的情形。此时write系统调用会被进程接收到的SIGBUS信号中断，因为当前进程访问了非法内存地址。对SIGBUS信号的默认处理是杀死当前进程并生成dump core文件——而这对于网络服务器程序而言不是最期望的操作。
　　

　　有两种方式可用于解决该问题：
　　第一种方式是为SIGBUS信号设置信号处理程序，并在处理程序中简单的执行return语句。在这样处理方式下，write系统调用返回被信号中断前已写的字节数，并将errno全局变量设置为成功。必须指出，这并不是个好的解决方式——治标不治本。由于收到SIGBUS信号意味着进程发生了严重错误，我不鼓励采取这种解决方式。

　　第二种方式应用了文件租借（在Microsoft Windows系统中被称为“机会锁”)。这才是解劝前面问题的正确方式。通过对文件描述符执行租借，可以同内核就某个特定文件达成租约。从内核可以获得读/写租约。当另外一个进程试图将你正在传输的文件截断时，内核会向你的进程发送实时信号——RT_SIGNAL_LEASE。该信号通知你的进程，内核即将终止在该文件上你曾获得的租约。这样，在write调用访问非法内存地址、并被随后接收到的SIGBUS信号杀死之前，write系统调用就被RT_SIGNAL_LEASE信号中断了。write的返回值是在被中断前已写的字节数，全局变量errno设置为成功。下面是一段展示如何从内核获得租约的示例代码。

)
{
    perror("kernel lease set signal");
    ;
}

/* l_type can be F_RDLCK F_WRLCK */
if(fcntl(fd, F_SETLEASE, l_type))
{
    perror("kernel lease set type");
    ;
}

sendfile

　　作用于数据拷贝在两个文件描述符之间的操作函数.这个拷贝操作是内核中操作的,所以称为"零拷贝".sendfile函数比起read和write函数高效得多,因为read和write是要把数据拷贝到用户应用层操作.目的是简化通过网络在两个本地文件之间进行的数据传输过程。sendfile系统调用的引入，不仅减少了数据复制，还减少了上下文切换的次数。
参数说明:

1. out_fd 是已经打开了,用于写操作(write)的文件描述符;
2. in_fd 是已经打开了,用于读操作(read)的文件描述符;
3. offset 偏移量;表示sendfile函数从in_fd中的哪一偏移量开始读取数据.如果是零表示从文件的开始读,否则从相应的便宜量读取.如果是循环读取的时候,下一次offset值应为sendfile函数返回值加上本次的offset的值.
4. count是在两个描述符之间拷贝的字节数(bytes)

返回值:
　　如果成功的拷贝,返回写操作到out_fd的字节数,错误返回-1,并相应的设置error信息.

1. EAGAIN 无阻塞I/O设置O_NONBLOCK时,写操作(write)阻塞了.
2. EBADF 输出或者输入的文件描述符没有打开.
3. EFAULT 错误的地址.
4. EINVAL 描述符不可用或者锁定了,或者用mmap()函数操作的in_fd不可用.

#include <sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

1. sendfile系统调用导致文件内容通过DMA模块被复制到某个内核缓冲区，之后再被复制到与socket相关联的缓冲区内。
2. 当DMA模块将位于socket相关联缓冲区中的数据传递给协议引擎时，执行第3次复制。

　　你可能会在想，我们在调用sendfile发送数据的期间，如果另外一个进程将文件截断的话，会发生什么事情？如果进程没有为SIGBUS注册任何信号处理函数的话，sendfile系统调用返回被信号中断前已发送的字节数，并将全局变量errno置为成功。
　　然而，如果在调用sendfile之前，从内核获得了文件租约，那么类似的，在sendfile调用返回前会收到RT_SIGNAL_LEASE。
　　到此为止，我们已经能够避免内核进行多次复制，然而我们还存在一分多余的副本。这份副本也可以消除吗？当然，在硬件提供的一些帮助下是可以的。为了消除内核产生的素有数据冗余，需要网络适配器支持聚合操作特性。该特性意味着待发送的数据不要求存放在地址连续的内存空间中；相反，可以是分散在各个内存位置。在内核版本2.4中，socket缓冲区描述符结构发生了改动，以适应聚合操作的要求——这就是Linux中所谓的"零拷贝“。这种方式不仅减少了多个上下文切换，而且消除了数据冗余。从用户层应用程序的角度来开，没有发生任何改动，

　　为了更好的理解所涉及的操作，请看图4

1. sendfile系统调用导致文件内容通过DMA模块被复制到内核缓冲区中。
2. 数据并未被复制到socket关联的缓冲区内。取而代之的是，只有记录数据位置和长度的描述符被加入到socket缓冲区中。DMA模块将数据直接从内核缓冲区传递给协议引擎，从而消除了遗留的最后一次复制。

　　由于数据实际上仍然由磁盘复制到内存，再由内存复制到发送设备，有人可能会声称这并不是真正的"零拷贝"。然而，从操作系统的角度来看，这就是"零拷贝",因为内核空间内不存在冗余数据。应用"零拷贝"特性，出了避免复制之外，还能获得其他性能优势，例如更少的上下文切换，更少的CPU cache污染以及没有CPU必要计算校验和.