开发者学堂课程【Nginx 企业级 Web 服务实战：IO 模型介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/649/detail/10751
IO 模型介绍（二）
三、网络 I/O 模型
分为阻塞型、非阻塞型、复用型、信号驱动型、异步
1.同步阻塞型 IO 模型（blocking IO）：
阻塞 IO 模型是最简单的 IO 模型，用户线程在内核进行 IO 操作时被阻塞用户线程通过系统调用 read 发起 IO 读操作，由用户空间转到内核空间。
内核等到数据包到达后，然后将接收的数据拷⻉到用户空间，完成 read 操作用户需要等待 read 将数据读取到 buffe r后，才继续处理接收的数据。
整个 IO 请求的过程中，用户线程是被阻塞的，这导致用户在发起 IO 请求时，不能做任何事情，对 CPU 的资源利用率不够优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源
缺点：
每个连接需要独立的进程/线程单独处理，当并发请求量⼤时为了维护程序，内存、线程切换开销较大，apache 的 preforck 使用的是这种模式。
2. 同步非阻塞型 IO 模型（blocking IO）：
用户线程发起 IO 请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起 IO 请求，直到数据到达后，才真正读取到数据，继续执行。
即 “轮询”机制存在两个问题：如果有⼤量文件描述符都要等，那么就得一个一个的read。
这会带来大量的 Context Switch（read 是系统调用，每调用⼀次就得在用户态和核心态切换⼀次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。
等待时间设的太⻓，程序响应延迟就过大；设的太短，就会造成过于频繁的重试，干耗 CPU 而已，是比较浪费 CPU 的方式，⼀般很少直接使用这种模型，⽽是在其他 IO 模型中使用非阻塞 IO 这⼀特性。
3.IO 多路复用型(IO multiple xing)：
IO multiplexing 就是我们说的 select，poll，epoll，有些地方也称这种 IO 方式为event driven IO。
select/poll/epoll 的好处就在于单个 process 就可以同时处理多个网络连接的 IO。
它的基本原理就是 select，poll，epol l这个 function 会不断的轮询所负责的所有socket，当某个 socket 有数据到达了，就通知用户进程。
当用户进程调用了 select，那么整个进程会被 block，而同时，kernel 会“监视”所有 select 负责的 socket，当任何⼀个 socket 中的数据准备好了，select 就会返回。这个时候用户进程再调用 read 操作，将数据从 kernel 拷⻉到用户进程。
Apache prefork 是此模式的主进程+多进程/单线程 +select，work 是主进程+多进程/多线程+poll 模式
四、信号驱动式IO(signal-driven IO)
信号驱动 IO：
signal-driven I/O 用户进程可以通过 sigaction 系统调用注册⼀个信号处理程序，然后主程序可以继续向下执行，当有 IO 操作准备就绪时，由内核通知触发⼀个 SIGIO信号处理程序执行，然后将用户进程所需要的数据从内核空间拷⻉到用户空间，此模型的优势在于等待数据报到达期间进程不被阻塞。
用户主程序可以继续执行，只要等待来自信号处理函数的通知。
优点：
线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率缺点：
信号 I/O 在⼤量 IO 操作时可能会因为信号队列溢出导致没法通知。
五、异步(非阻塞) IO (asynchronous IO)
相对于同步 IO，异步 IO 不是顺序执行。用户进程进行 aio_read 系统调用之后，无论内核数据是否准备好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。
等到 socket 数据准备好了，内核直接复制数据给进程，然后从内核向进程发送通知。
IO 两个阶段，进程都是非阻塞的。 Linux 提供了 AIO 库函数实现异步，但是用的很少。目前有很多开源的异步 IO 库，例如 libevent、libev、libuv。
六、IO对比
这五种网络 I/O 模型中，越往后，阻塞越少，理论上效率也是最优前四种属于同步 I/O，因为其中真正的 I/O 操作(recvfrom)将阻塞进程/线程，只有异步 I/O 模型才与 POSIX 定义的异步 I/O 相匹配。
七、实现方式
Nginx 支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：
1. select:
select 库是在 linux 和 windows 平台都基本支持的事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。
2、poll:
在 Linux 的基本驱动模型，windows 不支持此驱动模型，是 select 的升级版，取消了最大的并发限制，在编译 nainx 的时候可以使用 --with-poll module 和 --without-poll module 这两个指定是否编译select库。
3.epoll:
epoll 是库是 Nainx 服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和 select 和 poll 有很大的区别，epoll 是 poll 的升级版，但是与poll 的效率有很大的区别.
epoll 的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发生，epoll 支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时 epoll 库的 IO 效率不随描述符数目增加而线性下降，因为它只会对内核上报的“活跃”的描述符进行操作。
4、rtsig:
不是一个常用事件驱动，最大队列1024，不是很常用
5、 kaueue:
用于支持 BSD 系列平台的高校事件驱动模型，主要用在 FreeBSD4.1及以上版本、OpenBSD 2.0 级以上版本，NetBSD 级以上版本及 Mac OS X 平台上，该模型也是poll 库的变种，因此和 epoll 没有本质上的区别，都是通过避免轮训操作提供效率。
6./dev/poll:
用于支持 unix 衍生平台的高效事件驱动模型，主要在 Solaris 平台、HP/UX，该模型是 sun 公司在开发 Solaris 系列-平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的 /dev/poll 设备，开发人员将要见识的文件描述符加入这个设备，然后通过 ioctl/) 调用来获取事件通知，因此运行在以上系列平台的时候请使用 /dev/poll事件驱动机制
7. eventport:
该方案也是 sun 公司在开发 Solaris 的时候提出的事件驱动库，只是 Solaris 10 以上的版本，该驱动库看防止内核崩溃等情况的发生。
8. locp:
Windows 系统上的实现方式，对应第5种（异步 l/O）模型。
