高性能Web服务器详情介绍

Web服务器基础介绍

1.1单次web服务访问流程

正常情况下的单次web服务访问流程如下：

浏览器发出HTTP请求：

• 用户在浏览器中输入网址（URL），浏览器会通过互联网（WWW）向服务器发送一个HTTP请求。

Web服务器接收请求：

• 服务器接收到来自浏览器的HTTP请求。Web服务器是专门用来处理这些请求的软件，它决定如何处理请求并将其传递给相应的应用程序。

应用程序处理请求：

• Web服务器将请求转发给相关的应用程序，应用程序根据请求的内容进行处理，比如从数据库中获取数据或进行一些计算处理。

Web服务器发送HTTP响应：

• 应用程序处理完成后，将结果返回给Web服务器。然后，Web服务器将这些结果封装成HTTP响应，发送回浏览器。

浏览器显示结果：

• 浏览器接收到HTTP响应后，会将响应内容解析并呈现给用户，比如在网页上显示“Hello, World!”。

1.2 Web服务器介绍

1.2.1 Apache经典的Web服务器

Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发

目前经历了两大版本分别是1.X和2.X

其可以通过编译安装实现特定的功能

1.2.1.1 Apache prefork 模型

• 预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024
• 每个子进程有一个独立的线程响应用户请求
• 相对比较占用内存，但是比较稳定，可以设置最大和最小进程数
• 是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景

优点：稳定

缺点：每个用户请求需要对应开启一个进程,占用资源较多，并发性差,不适用于高并发场景

其相关进程如下：

主进程：

• 图中的“主进程”负责创建和管理多个子进程。主进程不直接处理客户端请求，而是负责维护整个服务器的运行状态，包括启动和停止子进程。

子进程：

• 每个子进程独立存在，并且在主进程启动时会被创建。每个子进程负责处理传入的请求。当一个请求到达服务器时，主进程会将这个请求分配给某一个空闲的子进程进行处理。
• 在prefork模型中，每个子进程都是独立的，子进程之间互不影响。

线程：

• 在子进程内部，每个子进程包含一个或多个线程。每个线程可以处理一个HTTP请求。这样，多个线程可以同时处理多个请求，从而提高服务器的并发处理能力。
• 在图中，每个子进程都启动了一个线程来处理请求。

请求处理：

• 每个线程接收到请求后，会处理该请求并返回响应。当一个请求被处理完毕后，线程将继续等待下一个请求的到来。

由以上可看出，Apache的prefork模型通过使用多个子进程，每个子进程处理单个或多个线程来应对并发请求。这个模型的优点是隔离性强，每个子进程独立处理请求，减少了线程之间的竞争与干扰，适用于需要高隔离性的应用场景。缺点是由于每个子进程都占用较多资源（如内存），因此在高并发情况下，资源消耗可能较大。

1.2.1.2 Apache worker模型

• 一种多进程和多线程混合的模型
• 有一个控制进程，启动多个子进程
• 每个子进程里面包含固定的线程
• 使用线程程来处理请求
• 当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求，
• 由于其使用了线程处理请求，因此可以承受更高的并发

优点：相比prefork 占用的内存较少，可以同时处理更多的请求

缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用（该问题在prefork模式下，同样会发生）

其相关进程如下：

主进程：

• 主进程负责创建和管理子进程。主进程的作用类似于prefork模型中的主进程，主要负责维护服务器的运行状态，包括创建子进程和监控其健康状况。

子进程：

• 每个子进程启动后，会创建多个线程。这些子进程主要负责管理和调度线程的执行。
• 与prefork模型不同的是，worker模型中的子进程能够同时处理多个请求，因为每个子进程可以创建多个线程来处理这些请求。

线程：

• 每个子进程中的多个线程是实际处理请求的单元。线程是轻量级的，因此在一个子进程内可以运行多个线程。
• 当请求到达时，子进程将其分配给一个空闲的线程进行处理。

请求处理：

• 每个线程处理一个请求。当线程处理完请求后，它会返回结果并等待处理下一个请求。
• 由于一个子进程可以拥有多个线程，因此可以在同一时间处理多个请求，从而提高并发能力。

由上可以看出，Apache的worker模型结合了多进程和多线程的优点，通过在每个子进程中运行多个线程来处理并发请求。这种模型在资源使用上更加高效，因为多个线程共享子进程的资源（如内存），从而减少了资源消耗。worker模型适用于需要处理大量并发请求的场景，同时也提供了比prefork模型更高的性能和更好的可伸缩性。

1.2.1.3 Apache event模型

​ Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll)每个进程响应多个请求，在现在版本里的已经是稳定可用的模式它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题（某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）

​ event MPM中，会有一个专门的线程来管理这些keepalive类型的线程当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力

• 优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放

• 缺点：没有线程安全控制

其相关进程如下：

1. 主进程 (Main Process)

• 负责初始化服务器并生成子进程。
• 子进程是处理具体请求的工作单位。

2. 子进程 (Child Processes)

• 每个子进程包含一个或多个监听线程和工作线程。
• 监听线程负责接收新请求并分配给空闲的工作线程。
• 工作线程处理具体的HTTP请求，包括静态资源的返回和动态内容的生成。

3. 监听线程 (Listener Threads)

• 每个子进程有一个监听线程。
• 监听线程不断监听新的网络连接请求，一旦有新的请求，监听线程会将其分配给空闲的工作线程。
• 如果没有空闲的工作线程，新的请求可能会被放置在队列中等待。

4. 工作线程 (Worker Threads)

• 实际处理请求的线程。
• 在接收到监听线程分配的请求后，工作线程执行具体的任务，例如读取请求数据、调用后端应用程序、生成响应并返回给客户端。
• 处理完一个请求后，工作线程会回到空闲状态，准备处理下一个请求。

5. 请求处理流程

• 请求1、请求3等请求由监听线程分配给工作线程。
• 当工作线程完成任务后，它将重新进入等待状态，等待新的请求。

6. 空闲保持 (Keep-alive)

• 为了处理HTTP keep-alive连接，部分工作线程在处理完请求后，不会立即释放，而是保持空闲状态，等待客户端的下一个请求。
• 这样可以减少新建连接的开销，进一步提高性能。

1.2.2 Nginx 高性能的Web服务器

​ 官网地址 www.nginx.org

​ Nginx是一个高性能的开源Web服务器和反向代理服务器，同时也可以用作IMAP/POP3邮件代理服务器。Nginx最初由俄罗斯程序员Igor Sysoev开发，目的是解决C10K问题，即在单个服务器上有效地处理1万并发连接的问题。

​ Nginx历经十几年的迭代更新（https://nginx.org/en/CHANGES）， 目前功能已经非常完善且运行稳定，另外Nginx的版本分为开发版、稳定版和过期版，nginx以功能丰富著称，它即可以作为http服务器，也可以作为反向代理服务器或者邮件服务器能够快速的响应静态网页的请求，是许多大型网站和应用的核心组件（天猫 淘宝 京东 小米 163 新浪等一线互联网公司都在用Nginx或者进行二次开发）。

​ 支持FastCGI/SSL/Virtual Host/URL Rwrite /Gzip / HTTP Basic Auth/http或者TCP的负载均衡(1.9版本以上且开启stream模块)等功能，并且支持第三方的功能扩展。

基于Nginx的工作场景：

1.2.3 用户访问体验和性能

1.2.3.1 用户访问体验统计

• 互联网存在用户速度体验的1-3-10原则，即1秒最优，1-3秒较优，3~10秒比较慢，10秒以上用户无法接受。用户放弃一个产品的代价很低，只是换一个URL而已。

  • 全球最大搜索引擎 Google：慢500ms = 20% 将放弃访问。
  • 全球最大的电商零售网站亚马逊：慢100ms = 1% 将放弃交易

• 有很多研究都表明，性能对用户的行为有很大的影响：

  • 79%的用户表示不太可能再次打开一个缓慢的网站
  • 47%的用户期望网页能在2秒钟以内加载
  • 40%的用户表示如果加载时间超过三秒钟，就会放弃这个网站
  • 页面加载时间延迟一秒可能导致转换损失7%，页面浏览量减少11%
  • 8秒定律：用户访问一个网站时，如果等待网页打开的时间超过8秒，会有超过30%的用户放弃等待

1.2.3.2 影响用户体验的因素

1.客户端

• 客户端硬件配置
• 客户端网络速率
• 客户端与服务端距离

2.服务器

• 服务端网络速率
• 服务端硬件配置
• 服务端架构设计
• 服务端应用程序工作模式
• 服务端并发数量服务端响应文件大小及数量 buffer cache
• 服务端I/O压力1.2.4 服务端 I/O 流程

1.2.4 服务端I/O流程

​ I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

​ 一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。

服务器的I/O：

• 磁盘I/O
• 网络I/O : 一切皆文件,本质为对socket文件的读写

1.2.4.1 磁盘I/O

​ 磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是html 文件或者图片，然后内核通过相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间

机械磁盘的寻道时间、旋转延迟和数据传输时间：
寻道时间：是指磁头移动到正确的磁道上所花费的时间，寻道时间越短则I/O处理就越快，目前磁盘的寻道时间一般在3-15毫秒左右。

旋转延迟：是指将磁盘片旋转到数据所在的扇区到磁头下面所花费的时间，旋转延迟取决于磁盘的转速，通常使用磁盘旋转一周所需要时间的1/2之一表示，比如7200转的磁盘平均训传延迟大约为60*1000/7200/2=4.17毫秒，公式的意思为 （每分钟60秒*1000毫秒每秒/7200转每分/2），如果是15000转的则为60*1000/15000/2=2毫秒。

数据传输时间：指的是读取到数据后传输数据的时间，主要取决于传输速率，这个值等于数据大小除以传输速率，目前的磁盘接口每秒的传输速度可以达到600MB，因此可以忽略不计。

常见的机械磁盘平均寻道时间值：
7200转/分的磁盘平均物理寻道时间：9毫秒
10000转/分的磁盘平均物理寻道时间：6毫秒
15000转/分的磁盘平均物理寻道时间：4毫秒

常见磁盘的平均延迟时间：
7200转的机械盘平均延迟：60*1000/7200/2 = 4.17ms
10000转的机械盘平均延迟：60*1000/10000/2 = 3ms
15000转的机械盘平均延迟：60*1000/15000/2 = 2ms

每秒最大IOPS的计算方法：
7200转的磁盘IOPS计算方式：1000毫秒/(9毫秒的寻道时间+4.17毫秒的平均旋转延迟时间)=1000/13.13=75.9 IOPS
10000转的磁盘的IOPS计算方式：1000毫秒/(6毫秒的寻道时间+3毫秒的平均旋转延迟时间)=1000/9=111IOPS
15000转的磁盘的IOPS计算方式：15000毫秒/(4毫秒的寻道时间+2毫秒的平均旋转延迟时间)=1000/6=166.6 IOPS

1.2.4.2 网络I/O

网络通信就是网络协议栈到用户空间进程的IO就是网络IO

网络I/O处理过程

• 获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）
• 构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）
• 返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）

不论磁盘和网络I/O

每次I/O，都要经由两个阶段：

• 第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长
• 第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

1.3 I/O 模型

1.3.1 I/O模型的的相关概念

• 同步/异步：关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状态的通知。
  • 同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事情是否处理完成
  • 异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态

• 阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态
  • 阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情。
  • 非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情

1.3.2 网络I/O模型

阻塞型、非阻塞型、复用型、信号驱动型、异步

1.3.2.1 阻塞型 I/O 模型（blocking IO）

• 阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞

• 用户线程通过系统调用read发起I/O读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作

• 用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个I/O请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够

• 优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源

• 缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较apache 的preforck使用的是这种模式。同步阻塞：程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮询查看I/O是否完成，完成后进程将I/O结果返回给Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看I/O是否完成，这种方式简单，但是比较慢，用的比较少。

1.3.2.2 非阻塞型 I/O 模型 (nonblocking IO)

​ 用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。即 “轮询”机制存在两个问题：如果有大量文件描述符都要等，那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长，程序响应延迟就过大;设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式，一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

非阻塞：程序向内核发送请I/O求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核I/O是否完成。

查看上图可知，在设置连接为非阻塞时，当应用进程系统调用 recvfrom 没有数据返回时，内核会立即返回一个 EWOULDBLOCK 错误，而不会一直阻塞到数据准备好。如上图在第四次调用时有一个数据报准备好了，所以这时数据会被复制到 应用进程缓冲区 ，于是 recvfrom 成功返回数据

当一个应用进程这样循环调用 recvfrom 时，称之为轮询 polling 。这么做往往会耗费大量CPU时间，实际使用很少

1.3.2.3 多路复用I/O 型(I/O multiplexing)

上面的模型中,每一个文件描述符对应的IO是由一个线程监控和处理

• 多路复用IO：指一个线程可以同时（实际是交替实现，即并发完成）监控和处理多个文件描述符对应各自的IO，即复用同一个线程一个线程之所以能实现同时处理多个IO,是因为这个线程调用了内核中的SELECT,POLL或EPOLL等系统调用，从而实现多路复用IO

• I/O multiplexing 主要包括:select，poll，epoll三种系统调用，select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。

  它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

• 当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket，

• 当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

Apache prefork是此模式的select，worker是poll模式。

**IO多路复用（IO Multiplexing) ：**是一种机制，程序注册一组socket文件描述符给操作系统，表示“我要监视这些fd是否有IO事件发生，有了就告诉程序处理”IO多路复用一般和NIO一起使用的。NIO和IO多路复用是相对独立的。NIO仅仅是指IO API总是能立刻返回，不会被Blocking;而IO多路复用仅仅是操作系统提供的一种便利的通知机制。操作系统并不会强制这俩必须得一起用，可以只用IO多路复用 + BIO，这时还是当前线程被卡住。IO多路复用和NIO是要配合一起使用才有

实际意义

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，就通知该进程多个连接共用一个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而不是阻塞在真正的IO操作上用户首先将需要进行IO操作添加到select中，同时等待select系统调用返回。当数据到达时，IO被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及调用select函数的额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种，一次只能监控一个IO虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO模型，而非真正的异步IO

优缺点

• 优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程)，这样可以大大节省系统资源

• 缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理需要 2 次系统调用，占用时间会有增加

IO多路复用适用如下场合：

• 当客户端处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用
• 当一个客户端同时处理多个套接字时，此情况可能的但很少出现
• 当一个服务器既要处理监听套接字，又要处理已连接套接字，一般也要用到I/O复用
• 当一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用
• 当一个服务器要处理多个服务或多个协议，一般要使用I/O复用

1.3.2.4 信号驱动式 I/O 模型 (signal-driven IO)

信号驱动I/O的意思就是进程现在不用傻等着，也不用去轮询。而是让内核在数据就绪时，发送信号通知进程。

调用的步骤是，通过系统调用 sigaction ，并注册一个信号处理的回调函数，该调用会立即返回，然后主程序可以继续向下执行，当有I/O操作准备就绪,即内核数据就绪时，内核会为该进程产生一个 SIGIO信号，并回调注册的信号回调函数，这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间

此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处理函数的通知。

在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续运行并不阻塞

当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。

• 优点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率

• 缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知

异步阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程请求后进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程。

1.3.2.5 异步 I/O 模型 (asynchronous IO)

异步I/O 与 信号驱动I/O最大区别在于，信号驱动是内核通知用户进程何时开始一个I/O操作，而异步I/O是由内核通知用户进程I/O操作何时完成，两者有本质区别,相当于不用去饭店场吃饭，直接点个外卖，把等待上菜的时间也给省了

相对于同步I/O，异步I/O不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。

信号驱动IO当内核通知触发信号处理程序时，信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到用户空间缓冲区这个阶段，而异步IO直接是在第二个阶段完成后，内核直接通知用户线程可以进行后续操作了

• 优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠

• 缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的

异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求

Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、libuv。

异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的IO如果不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现较大的同时并实现较高的IO复用，因此异步非阻塞使用最多的一种通信方式。

1.3.3 五种I/O对比

这五种 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配

1. 阻塞型 I/O 模型 (Blocking IO)

• 流程: 在阻塞 I/O 模型中，操作系统会将进程或线程阻塞，直到 I/O 操作完成。图中表示的过程是：调用 I/O 操作，进程进入阻塞状态，直到数据准备好并被拷贝到用户空间后，I/O 操作完成。
• 特点: 进程在等待数据准备期间是阻塞的，无法执行其他任务。

2. 非阻塞型 I/O 模型 (Nonblocking IO)

• 流程: 进程会不断地检查数据是否准备好 (轮询)，每次调用 I/O 操作都会立即返回，且不会阻塞进程。只有在数据准备好后，I/O 操作才会完成。
• 特点: 进程在检查数据准备的过程中不会被阻塞，但需要持续轮询，可能导致 CPU 资源浪费。

3. 多路复用 I/O 型 (IO Multiplexing)

• 流程: 使用 select 或 poll 等系统调用，进程可以同时等待多个 I/O 事件。一旦某个事件准备好，进程才会去执行实际的 I/O 操作。图中表示了检查 (check) 数据准备情况的过程，只有当数据准备好时，I/O 操作才会继续。
• 特点: 多路复用允许进程在单线程中管理多个 I/O 操作，适用于需要同时处理多个 I/O 事件的场景。

4. 信号驱动式 I/O 型 (Signal-driven IO)

• 流程: 进程会注册一个信号处理函数，当数据准备好时，操作系统会通过信号通知进程。进程收到通知后执行 I/O 操作。
• 特点: 不需要像非阻塞 I/O 模型那样持续轮询，进程可以在等待数据期间做其他事情，提高了资源利用率。

5. 异步 I/O 模型 (Asynchronous IO)

• 流程: 进程发出 I/O 请求后立即返回，操作系统在后台完成 I/O 操作并在完成后通知进程。进程在收到通知后处理数据。
• 特点: 进程在发出 I/O 请求后可以继续处理其他任务，直到操作系统通知 I/O 操作完成。这是最复杂但也是最高效的模型，特别适用于需要高并发和高性能的应用场景。

1.3.4 I/O的具体实现方式

1.3.4.1 I/O常见实现

Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：

1、select：

select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。

2、poll：

在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编译nginx的时候可以使用–with-poll_module和–without-poll_module这两个指定是否编译select库。

3、epoll：

epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和select和poll有很大的区别，epoll是poll的升级版，但是与poll有很大的区别.epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮询检查这个表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时epoll库的I/O效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作。

4、kqueue：

用于支持BSD系列平台的高校事件驱动模型，主要用在FreeBSD 4.1及以上版本、OpenBSD 2.0级以上版本NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别，都是通过避免轮询操作提供效率。

5、Iocp：

Windows系统上的实现方式，对应第5种（异步I/O）模型。

6、rtsig：

不是一个常用事件驱动，最大队列1024，不是很常用

7、/dev/poll:

用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。

8、eventport：

该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防止内核崩溃等情况的发生。

常用的为：select、poll、epoll这三种I/O

1.3.4.2 常用I/O模型比较

	select	poll	epoll
操作方式	遍历	遍历	回调
底层实现	数组	链表	哈希表
IO效率	每次调用都进行线性遍历，时间复杂度为0(n)	每次调用都进行线性遍历，时间复杂度为0(n)	事件通知方式，每当d就绪，系统注册的回调函数就会被调用，将就绪的fd放到rdmist里，时间复杂度O(1)
最大连接数	1024(x86) 2048(x64)	无上限	无上限
fd拷贝	每次调用select都需要把fd集合从用户拷贝到内核态	每次调用poll，都需要把fd集合从用户态拷贝到内核态	调用epoll ctl时拷贝进内核并保存，之后每次epoll wait不拷贝

• Select：

  POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理、

  • 缺点

    单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核对socket是线性扫描，即采用轮询的方法，效率较低select 采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大

• poll：

  本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态其没有

  最大连接数的限制，原因是它是基于链表来存储的大量的fd的数组被整体复制于用户态和内核地址空间

  之间，而不管这样的复制是不是有意义poll特点是“水平触发”，如果报告了fd后，没有被处理，那么下次

  poll时会再次报告该fd select是边缘触发即只通知一次

• epoll：

  在Linux 2.6内核中提出的select和poll的增强版本支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会通知一次使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知

  • 优点:

    没有最大并发连接的限制：能打开的FD的上限远大于1024(1G的内存能监听约10万个端口)，具体查看

    /proc/sys/fs/file-max，此值和系统内存大小相关

    效率提升：非轮询的方式，不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函

    数，即epoll最大的优点就在于它只管理“活跃”的连接，而跟连接总数无关

    内存拷贝，利用mmap(Memory Mapping)加速与内核空间的消息传递;即epoll使用mmap减少复制开销

总结:

1、epoll只是一组API，比起select这种扫描全部的文件描述符，epoll只读取就绪的文件描述符，再加入基于事件的就绪通知机制，所以性能比较好

2、基于epoll的事件多路复用减少了进程间切换的次数，使得操作系统少做了相对于用户任务来说的无用功。

3、epoll比select等多路复用方式来说，减少了遍历循环及内存拷贝的工作量，因为活跃连接只占总并发连接的很小一部分。

1.3.4.3 I/O相关案例

• 最大并发连接数和内存有直接关系：

[root@nginx ~]# free -h        # 显示系统内存使用情况
               total        used        free      shared  buff/cache   available
Mem:           1.7Gi       686Mi       470Mi       9.0Mi       767Mi       1.0Gi
Swap:          2.0Gi          0B       2.0Gi
[root@nginx ~]# cat /proc/sys/fs/file-max     # 显示 Linux 系统中可以同时打开的最大文件描述符
9223372036854775807

total: 物理内存总量。

used: 已使用的内存量。

free: 未使用的内存量。

shared: 被共享内存使用的量（一般用于 tmpfs）。

buff/cache: 被缓存和缓冲区使用的内存量。这部分内存主要是为提高系统性能而保留的，系统在需要时可以将其用于其他目的。

available: 应用程序可用的内存量。它考虑了内存分配策略和缓存的情况，表示实际可以分配给新应用程序的内存。

Swap:

• total: 交换空间的总量。
• used: 已使用的交换空间量。
• free: 未使用的交换空间量。

• select、poll、epoll的帮助

[root@nginx ~]# whatis select
select (2)           - synchronous I/O multiplexing      -- 同步 I/O 多路复用
select (3p)          - synchronous I/O multiplexing
[root@nginx ~]# whatis poll
poll (2)             - wait for some event on a file descriptor   --等待某个文件描述符上的事件，比如数据可读、可写或发生异常。
poll (3p)            - input/output multiplexing    -- I/O 多路复用技术，类似于select
[root@nginx ~]# whatis epoll
epoll (7)            - I/O event notification facility   -- 用于通知 I/O 事件的机制。它是 select 和 poll 的增强版，通常在处理大量并发连接时表现更好

[root@nginx ~]# man 2 select
[root@nginx ~]# man 2 poll
[root@nginx ~]# man 2 epoll

1.4 零拷贝

1.4.1 零拷贝介绍

零拷贝就是上述问题的一个解决方案，通过尽量避免拷贝操作来缓解 CPU 的压力。零拷贝并没有真正做到“0”拷贝，它更多是一种思想，很多的零拷贝技术都是基于这个思想去做的优化

1.4.1.1 传统 Linux中 I/O 的问题

1. User（用户层）：
   • User 缓存：用户进程中的数据缓冲区（如内存中的一块区域），用户进程会首先将数据写入这个缓冲区。
2. Kernel（内核层）：
   • Kernel 缓存：内核中的缓存区，用于临时存储数据。当用户进程需要将数据发送到网络或写入磁盘时，数据首先会从用户缓存复制到内核缓存。
   • Socket 缓存：如果数据要通过网络发送，内核会将数据从 Kernel 缓存复制到 Socket 缓存，这是与网络接口相关的缓冲区。
3. Hardware（硬件层）：
   • 磁盘文件：表示数据最终写入到磁盘文件上。
   • 网络：表示数据最终通过网络接口发送到外部设备或网络。

数据流动过程：

• 第一步：User 缓存到 Kernel 缓存：
  • 当用户程序需要进行 I/O 操作（如写文件或发送数据）时，数据从用户空间（User 缓存）复制到内核空间（Kernel 缓存）。
• 第二步：Kernel 缓存到硬件设备：
  • 数据在 Kernel 缓存中被处理后，会根据目的地继续被复制到对应的硬件设备。例如：
    • 如果是写入磁盘文件，数据从 Kernel 缓存复制到磁盘文件中。
    • 如果是通过网络发送，数据从 Kernel 缓存复制到 Socket 缓存，再通过网络接口发送出去。

传统的 Linux 系统的标准 I/O 接口（read、write）是基于数据拷贝的，也就是数据都是 copy_to_user或者 copy_from_user，这样做的好处是，通过中间缓存的机制，减少磁盘 I/O 的操作，但是坏处也很明显，大量数据的拷贝，用户态和内核态的频繁切换，会消耗大量的 CPU 资源，严重影响数据传输的性能，统计表明，在Linux协议栈中，数据包在内核态和用户态之间的拷贝所用的时间甚至占到了数据包整个处理流程时间的57.1%

1.4.2 零拷贝相关技术

1.4.2.1MMAP ( Memory Mapping )

​ MMAP ( Memory Mapping )系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以向访问普通内存一样对文件进行访问。

mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

• 内存映射减少数据在用户空间和内核空间之间的拷贝操作,适合大量数据传输

1.4.2.2 SENDFILE

sendfile 是一种用于高效地在文件与网络接口之间传输数据的系统调用。它最初是为解决传统 I/O 操作中的多次数据拷贝问题而设计的。传统的文件传输方式通常需要数据从磁盘读取到用户空间，再从用户空间写入到内核空间，最后通过网络发送出去。这种方式涉及多次数据拷贝，导致性能开销较大。

• 工作原理：

  • sendfile 允许直接在内核空间内将数据从一个文件描述符复制到另一个文件描述符，而不需要经过用户空间。
  • 典型应用场景是将文件从磁盘直接发送到网络接口（如通过 socket 发送文件数据），例如在实现一个简单的 Web 服务器时，可以使用 sendfile 来高效地发送静态文件。

• 优点：

  • 减少了用户空间与内核空间之间的数据拷贝次数，从而提升了数据传输的效率。
  • 通过减少内存拷贝和上下文切换，降低了 CPU 的负担。

1.4.2.3 DMA 辅助的 SENDFILE

DMA（Direct Memory Access，直接内存访问）是一种硬件功能，允许设备直接在内存与外设之间传输数据，而不需要经过 CPU 的参与。将 DMA 与 sendfile 结合，可以进一步优化数据传输效率。

• 工作原理：
  • 在 DMA 辅助的 sendfile 实现中，数据可以直接从磁盘通过 DMA 传输到网络接口，而无需经过内核的中间缓冲区。这样，数据从磁盘到网络接口的整个过程都无需 CPU 的干预，只是在开始和结束时需要 CPU 的参与。
  • 这种方式减少了内核中的数据拷贝步骤，进一步提升了系统的 I/O 性能。
• 优点：
  • 高效传输：通过使用 DMA，数据传输速度更快，减少了系统总线的负载。
  • 降低 CPU 开销：由于 DMA 直接管理数据传输，CPU 可以腾出更多资源处理其他任务，进一步提升了系统的整体性能。