五种IO模型

用户空间和内核空间

服务器大多都采用Linux系统，这里以Linux为例来讲解:

任何Linux发行版，其系统内核都是Linux。应用都需要通过Linux内核与硬件交互。

为了避免用户应用导致冲突甚至内核崩溃，用户应用与内核是分离的：

• 进程的寻址空间会划分为两部分：内核空间、用户空间
• 用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问
• 内核空间可以执行特权命令（Ring0），调用一切系统资源

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

• 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
• 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

阻塞IO

在《UNIX网络编程》一书中，总结归纳了5种IO模型：

• 阻塞IO（Blocking IO）
• 非阻塞IO（Nonblocking IO）
• IO多路复用（IO Multiplexing）
• 信号驱动IO（Signal Driven IO）
• 异步IO（Asynchronous IO）

读数据实际上就分为两个阶段：

1. 等待数据就绪
2. 读取数据

阻塞IO就是两个阶段都必须阻塞等待：

阻塞IO模型中，用户进程在两个阶段都是阻塞状态，数据拷贝完成时，用户进程解除阻塞，处理数据。

非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

• 如果调用recvfrom时，恰好没有数据，阻塞IO会使CPU阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。
• 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

而在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有IO事件都必须等待，性能自然会很差。

就比如服务员给顾客点餐，分两步：

①顾客思考要吃什么（等待数据就绪）【顾客长时间思考就会导致效率很差】

②顾客想好了，开始点餐（读取数据）

提高效率：

方案一： 增加更多服务员，更多的服务员开不起工资了（多线程，多线程开销变大了，线程之间上下文切换也会增大开销）

方案二： 不排队，谁想好了吃什么（数据就绪了），服务员就给谁点餐（用户应用就去读取数据）【IO多路复用】

用户进程如何知道内核中数据是否就绪呢？

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

IO多路复用：是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

①用户进程调用select，指定要监听的FD集合

②内核监听FD对应的多个socket

③任意一个或多个socket数据就绪则返回readable

④此过程中用户进程阻塞

阶段二：

①用户进程找到就绪的socket

②依次调用recvfrom读取数据

③内核将数据拷贝到用户空间

④用户进程处理数据

监听FD的方式、通知的方式有多种实现，常见的有：

• select
• poll
• epoll

差异：

• select和poll只会通知用户进程有FD就绪，但不确定具体是哪个FD，需要用户进程逐个遍历FD来确认
• epoll则会在通知用户进程FD就绪的同时，把已就绪的FD写入用户空间

select

select是Linux最早的I/O多路复用技术：

执行流程

bit位0/1监听fd是否就绪

用户态fd_set拷贝到内核态，内核遍历fd_set判断是否有数据就绪，fd_set就绪的保留未就绪的删除（改成0），内核态只返回有几个就绪此时并不知道是哪个fd就绪，把此时的fd_set拷贝覆盖用户态fd_set，最后用户态遍历fd_set找到就绪的fd处理数据

select模式存在的问题：

1. 需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间（两次用户态和内核态切换）
2. select无法得知具体是哪个fd就绪，需要遍历整个fd_set
3. fd_set监听的fd数量不能超过1024

poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

IO流程

①创建pollfd数组，向其中添加关注的fd信息，数组大小自定义

②调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限

③内核遍历fd，判断是否就绪

④数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n

⑤用户进程判断n是否大于0

⑥大于0则遍历pollfd数组，找到就绪的fd

与select对比：

• select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
• 监听FD越多，每次遍历消耗时间也越久，性能反而会下降

epoll

epoll模式是对select和poll的改进，它提供了三个函数：

流程图：

小结

select模式存在的三个问题：

1. 能监听的FD最大不超过1024
2. 每次select都需要把所有要监听的FD都拷贝到内核空间
3. 每次都要遍历所有FD来判断就绪状态

poll模式的问题：

• poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的？

• 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
• 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
• 利用ep_poll_callback机制来监听FD状态，无需遍历所有FD（将句柄中就绪FD列表拷贝到用户态中），因此性能不会随监听的FD数量增多而下降

事件通知机制

当FD有数据可读时，调用epoll_wait（或者select、poll）可以得到通知。但是事件通知的模式有两种：

• LevelTriggered：简称LT，也叫做水平触发。只要某个FD中有数据可读，每次调用epoll_wait都会得到通知。（epoll默认机制）
• EdgeTriggered：简称ET，也叫做边沿触发。只有在某个FD有状态变化时，调用epoll_wait才会被通知。

LT模式，如果数据未读完，就绪链表是不会断开的，直到数据读完，断开链表

ET模式，只要读取数据，不管数据有没有读完，直接断开链表，因此这种模式，处理方式略有不同：

①可以在未读完数据时，手动调用epoll_ctl函数将未读完的数据重新添加到就绪链表中

②直接循环读将数据直接全部读完【非阻塞IO读，有无读到数据都直接返回结果；阻塞IO读不到数据会一直阻塞，阻塞进程】

区别：

• LT：事件通知频率较高，会有重复通知，影响性能
• ET：仅通知一次，效率高。可以基于非阻塞IO循环读取解决数据读取不完整问题

select和poll仅支持LT模式，epoll可以自由选择LT和ET两种模式。

web服务流程

信号驱动IO

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待，第二阶段仍需阻塞等待。

缺陷：

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

异步IO

异步IO的整个过程都是非阻塞的，用户进程调用完异步API后就可以去做其它事情，内核等待数据就绪并拷贝到用户空间后才会递交信号，通知用户进程。

缺陷：

异步IO，在高并发场景下，用户进程不断发起请求，内核不断接受请求，内存占用过大，可能导致系统崩溃。

因此，五种IO模型，还是IO多路复用最常用。

同步和异步

IO操作是同步还是异步，关键看数据在内核空间与用户空间的拷贝过程（数据读写的IO操作），也就是阶段二是同步还是异步：