【五种IO模型】

 一、IO读写原理

1、内核态与用户态

为了避免用户进程直接操作内核，保证内核安全，操作系统将内存（虚拟内存）划分为两部分：

①内核空间（kernel-Space）：内核模块运行在内核空间，对应的进程处于内核态；

②用户空间（User-Space）：用户程序运行在用户空间，对应的进程处于用户态。

内核态和用户态是操作系统的两种运行状态。

1.1、内核态

操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内核空间，也有访问底层硬件设备的权限。内核空间总是驻留在内存中，它是为操作系统的内核保留的。应用程序是不允许直接在内核空间域进行读写，也是不允许直接调用内核代码定义的函数。

1.2、用户态

每个应用程序进程都有一个单独的用户空间，对应的进程处于用户态，用户进程不能访问内核空间中的数据，也不能直接调用内核函数，必须通过[系统调用]陷入内核中，才能访问特权资源。

1.3、为什么要区分用户态和内核态

在CPU的所有指令中，有一些指令是非常危险的，如果错用，会导致整个系统崩溃。比如：清空内存、修改时钟等。如果所有程序代码都能够直接使用这些指令，那么可能系统短时间内就会死n次。

所以，CPU将指令分为特权指令和非特权指令，对于较为危险的指令，只允许操作系统本身及其相关模块进行调用；普通的、用户自行编写的应用程序只能使用那些不会造成危险的指令。

基于安全的考虑，CPU提供了特权分级机制，将区域分成了四个Ring，越往内侧权限越高，越往外侧权限越低。

 内核空间对应特权等级的Ring0，用户空间对应特权等级的Ring3。

1.4、IO底层

• 内核态进程可以执行任意命令，调用系统的一切资源，而用户态进程只能调用简单的运算，不能直接调用系统资源，所以用户态进程必须通过系统接口（System Call），才能向内核发出指令，完成调用系统资源之类的操作；
• 用户程序进行IO的读写，依赖于底层IO读写，基本都会用到底层的两大系统调用：sys_read和sys_write。sys_read和sys_write两大系统调用都会涉及到缓冲区。sys_read系统调用会把数据从内核缓冲区复制到应用程序的进程缓冲区；sys_write会把数据从应用程序的进程缓冲区复制到操作系统的内核缓冲区。
• 应用程序的IO操作实际是内核缓冲区和应用程序进程缓冲区的缓冲复制sys_read和sys_write两大系统的调用，都不负责数据在内核缓冲区和物理设备（如磁盘、网卡等）之间的交换。这项底层的读写交换操作，是由操作系统内核（kernel）来完成的。
• 所以，应用程序中的IO操作，无论是对socket的IO操作，还是对文件的IO操作，都属于上层应用的开发，它们的在输入（input）和输出（output）维度上的执行流程，都是在内核缓冲区和进程缓冲区之间进行的数据交换。

2、内核缓冲区和进程缓冲区

设置缓冲区的目的为：减少频繁地与设备之间的物理交换。

计算机的外部物理设备与内存及CPU相比，有很大的差别，外部设备的直接读写，涉及到操作系统的中断。发生系统中断时，需要保存之前的进程数据和状态等信息，而结束中断之后，还需要恢复之前的进程数据和状态等信息。为了减少底层系统的频繁中断所导致的时间损耗、性能损耗，于是出现了内核缓冲区。

有了内核缓冲区，操作系统会对内核缓冲区进行监控，等待缓冲区达到一定数量时，再进行IO设备的中断处理，集中执行物理设备的实际IO操作，通过这种机制来提升系统的性能。至于具体在什么时候执行系统中断（包括读中断、写中断），则由系统的内核来决定，应用程序不需要关心这个问题。

上层应用程序使用sys_read系统调用时，仅仅是吧数据从内核缓冲区复制到了进程缓冲区；

而在使用sys_write系统调用时，仅仅是把数据从进程缓冲区复制到了内核缓冲区。

内核缓冲区与进程缓冲区在数量上也不相同。在Linux系统中，操作系统内核只有一个内核缓冲区，而每个用户程序都有自己独立的缓冲区（即进程缓冲区）。Linux系统中的用户程序的IO读写程序，在大多数情况下，并没有进行实际的IO操作，而是在内核缓冲区和进程缓冲区之间进行数据的交换。

3、图示

 举例说明，比如客户端和服务端之间完成一次socket请求和响应的数据交换，其流程如下：

1. 客户端发送请求：客户端通过sys_write系统调用，将数据复制到内核缓冲区，Linux将内核缓冲区的请求数据通过客户端机器的网卡发送出去；
2. 服务端系统接收数据：在服务端，这份请求数据会被服务端操作系统通过DMA硬件，从接收网卡中读取大服务端机器的内核缓冲区；
3. 服务端程序获取数据：服务端程序通过sys_read系统调用，从Linux内核缓冲区复制数据到用户缓冲区；
4. 服务端业务处理：服务器在自己的用户空间中，完成客户端请求所对应的业务处理；
5. 服务端返回数据：服务端程序完成处理后，构建好的响应数据，通过sys_write将这些数据从用户缓冲区写入内核缓冲区；
6. 服务端系统发送数据：服务端Linux系统将内核缓冲区中的数据写入网卡，网卡通过底层的通信协议，会将数据发送给目标客户端。

二、IO的基本概念

1、阻塞IO和非阻塞IO

网卡同步数据到内核缓冲区，如果内核缓冲区中的数据未准备好，用户进程发起read操作，阻塞则会一直等待内存缓冲区数据完整后再解除阻塞，而非阻塞则会立即返回不会等待，注意，内核缓冲区与用户缓冲区之间的读写操作肯定是阻塞的。

2、同步和异步

1. 同步：调用者主动发送请求，调用者主动等待这个结果返回，一旦调用就必须有返回值；
2. 异步：调用发出后直接返回，所以没有返回结果。被调用者处理完成后通过回调、通知等机制来通知调用者。

三、五种IO模型

 引言：TCP传送数据流程

要深入理解各种IO模型，那么必须先了解下产生各种IO的原因是什么，要知道这其中的本质问题，那么我们就必须要知道一条消息是如何从一个人发送到另外一个人的。以两个应用程序通讯为例，我们来了解一下当“A”向“B”发送一条消息，简单来说会经过如下流程：

1.  应用A把消息发送到TCP发送缓冲区；
2. TCP发送缓冲区再把消息发送出去，经过网络传递后，消息会发送到应用B的TCP接收缓冲区；
3. 应用B再从TCP接收缓冲区去读取属于自己的数据。

根据上图我们基本了解到消息发送要经过应用A、应用A对应服务器的TCP发送缓冲区、经过网络传输后消息发送到了应用B对应服务器的TCP接收缓冲区，最终应用B接收到消息。

 

 针对这一步，也就是应用A将消息发送到TCP发送缓冲区，如果TCP发送缓冲区满了，那么是告诉应用A现在没空间了，还是让应用A等着，等TCP发送缓冲区有空间了再把应用A的消息数据拷贝到发送缓冲区。同样的，在应用B向TCP接收缓冲区发起读取申请时，在接收缓冲区内还没有接收到属于应用B的消息时，是应该告诉应用B现在没有属于B的数据，还是应该让应用B等着，等到有数据了再把数据给B呢。这里就涉及到了IO模型。

3.1、阻塞IO模型

3.1.1、概述

结合上述例子，阻塞IO就是当应用B发起读取申请时，在内核数据没有准备好之前，应用B会一直处于等待数据状态，直到内核把数据准备好了交给应用B才结束。

3.1.2、术语

在应用调用read()函数读取数据时，其系统调用直到数据包到达且被复制到应用缓冲区或者发送错误时才返回，在此期间会一直等待，进程从调用到返回这段时间内都是被阻塞的，称为阻塞IO。

3.1.3、图解

 3.1.4、流程

1. 用户进程用read()系统函数，用户进程进入阻塞状态；
2. 系统内核收到read()系统调用，网卡开始准备接收数据，在一开始内核缓冲区数据为空，内核在等待接收数据，用户进程同步阻塞等待；
3. 内核缓冲区中有完整的数据后，内核会将数据从内核缓冲区复制到用户缓冲区；
4. 直到用户缓冲区中有数据，用户进程才能解除阻塞状态继续执行。

3.1.5、优缺点

•  优点：①开发简单，由于accept()、recv()都是阻塞的，为了服务于多个客户端请求，新的连接创建一个线程去处理即可。②阻塞的时候，线程挂起，不消耗CPU资源。
• 缺点：①每新来一个IO请求，都需要新建一个线程对应，高并发下系统开销大，多线程上下文切换频繁；②创建线程太多，内存消耗大。

3.1.6、思考

因为accept()、recv()函数都是阻塞的，如果系统想要支持多个IO请求，就需要创建更多的线程，如何去解决这个问题呢？ 要避免创建过多的线程来降低内存消耗，如果将accept()、recv()函数变为非阻塞的方式，是否能解决问题呢？这就引入了同步非阻塞IO。

3.2、非阻塞IO模型

3.2.1、概述

按照上述思路，所谓非阻塞IO就是当应用B发起读取申请时，若内核数据没准备好会立刻告诉应用B，不会让B在这等待。

3.2.2、图解

 3.2.3、流程

1. 用户进程发起请求调用read()函数，系统内核收到read()系统调用，网卡开始准备接收数据；
2. 内核缓冲区数据还没准备好，即刻返回EWOULDBLOCK错误码，用户进程不断地重试查询内核缓冲区数据有没有准备好；
3. 当内核缓冲区数据准备好了之后，用户进程阻塞，内核开始将内核缓冲区数据复制到用户缓冲区，否则依然返回错误码；
4. 复制完成后，用户进程解除阻塞，读取数据继续执行。

 3.2.4、优缺点

• 优点：①非阻塞，accept()、recv()均不阻塞，用户线程立即返回；②规避了同步阻塞模式的多线程问题；
• 缺点：假如现在有一万个客户端连接，但只有一个客户端发送数据，为了获取这一个客户端的数据，需要循环向内核发送一万遍recv()系统调用，而这其中有9999次是无效的请求，极大地浪费了CPU资源。

 3.2.5、思考

针对同步非阻塞模式的缺点，假如内核提供一个方法，可以一次性地将这一万个客户端socket连接传入，在内核中去遍历，如果没有数据，这个方法就一直阻塞，一旦有数据，这个方法解除阻塞并把所有有数据的socket返回，把这个遍历的过程交给内核去处理，是不是就可以避免空跑，避免一万次用户态到内核态的切换呢？

3.3、IO多路复用模型

3.3.1、概述

由一个线程监控多个网络请求（称文件描述符为fd,Linux系统把网络请求以fd来标识），这样就可以需要一个或几个线程就可以完成数据状态询问的操作，当有数据准备就绪之后再分配对应的线程去读取数据，这么做就可以节省出大量的线程资源出来，这个就是IO复用模型的思路。

 正如上图，IO复用模型的思路就是系统提供了一种函数可以同时监控多个fd的操作，这个函数就是我们常说到的select、poll、epoll函数，有了这个函数后，应用线程通过调用select函数就可以同时监控多个fd，select函数监控的fd中只要有任何一个数据状态准备就绪了，select函数就会返回可读状态，这时询问线程再去通知处理数据的线程，对应线程此时再发起recvfrom请求去读取数据。

 3.3.2、术语

IO多路复用即一个线程监测多个IO操作，该模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题，即一次性将N个客户端socket连接传入内核然后阻塞，交由内核去轮询，当某一个或多个socket连接有事件发生时，解除阻塞并返回事件列表，用户进程再循环遍历处理有事件的socket连接。这样就避免了多次调用recv()系统调用，避免了用户态到内核态的多次切换。

 3.3.3、图解

3.3.4、IO多路复用的三种实现

 3.3.4.1、select函数

（1）概述

select函数仅仅知道有几个IO事件发生了，但并不知道具体是哪几个socket连接有IO事件，还需要轮询去查找，时间复杂度为，处理的请求越多，所消耗的时间越长。

（2）流程

1. 从用户空间拷贝fd_set（注册的事件集合）到内核空间；
2. 遍历所有fd文件，并将当前进程挂到每个fd的等待队列中，当某个fd文件设备接收到消息后，会唤醒等待队列上睡眠的进程，那么当前进程就会被唤醒；
3. 如果遍历完所有的fd文件都没有IO事件，则当前进程进入睡眠，当有某个fd文件有IO事件或当前进程睡眠超时后，当前进程重新唤醒再次遍历所有fd文件。

（3）缺点

1. 单个进程所打开的fd是有限制的，通过FD_SIZE设置，默认为1024；
2. 每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大；
3. 每次调用select都需要将进程加入到所有监视socket的等待队列，每次唤醒都需要从队列中移除；
4. select函数在每次调用之前都要对参数进行重新设定，这样做比较麻烦，而且会降低性能；
5.  进程被唤醒后，程序并不知道是哪些socket收到数据，还需要遍历一次。

3.3.4.2、poll函数

（1）概述

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，但是poll没有最大连接数的限制，原因是它是基于链表来存储的。 

3.3.4.3、epoll函数

（1）概述

epoll可以理解为event pool，不同于select、poll的轮询机制，epoll采用的是事件驱动机制，每个fd上注册有回调函数，当网卡接收到数据时会回调该函数，同时将该fd的引用放入rdlist就绪列表中。当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。 

（2）流程

1. 调用epoll_create()创建一个ep对象，即红黑树的根结点，返回一个文件句柄；
2. 调用epoll_ctl()向这个ep对象（红黑树）添加、删除、修改感兴趣的事件；
3. 调用epoll_wait()等待，当有事件发生时网卡驱动会调用fd上注册的函数并将该fd添加到rdlist中，解除阻塞。

 （3）优点

1. epoll支持的最大文件描述符上限是整个系统最大可打开的文件数目，1G内存理论上最大创建10万个文件描述符；
2. 每个文件描述符都有一个callback函数，当socket有事件发生时会回调这个函数将该fd的引用添加到rdlist中，select和poll并不会明确指出是哪些fd就绪，而epoll会。造成的区别就是，系统调用返回后，调用select和poll的程序需要遍历监听的整个fd，找到是谁处于就绪状态，而epoll则直接处理即可；
3. select和poll采用轮询的方式来检查fd是否处于就绪状态，而epoll采用回调机制。造成的结果就是，随着fd的增加，select和poll的效率会线性降低，而epoll不会受到太大影响，除非活跃的socket很多。

3.3.4、总结

	select	poll	epoll
支持最大连接数	1024（×86）or2048（×64）	无上限	无上限
IO效率	每次调用要进行线性遍历，时间复杂度为	每次调用要进行线性遍历，时间复杂度为	采用事件通知方式，每当fd就绪，系统注册的回调函数就会被调用，将就绪fd放到rdlist里面，这样epoll_wait返回时，我们就拿到了就绪的fd，事件复杂度为
fd拷贝	每次select都拷贝	每次poll都拷贝	只有调用epoll_ct时拷贝进内核由内核保存，之后每次eopll_wait不拷贝

 3.4、信号驱动IO模型

 3.4.1、概述

IO多路复用模型解决了一个线程监听多个fd的问题，但是select是采用轮询的方式来监控多个fd的，通过不断地询问fd的可读状态来判断是否有可读的数据，而无脑的轮询显得有点暴力，因为大部分情况下的轮询都是无效的，所以有人就想，能不能不要我总是去问你数据是否准备好，能不能在我发出请求后，等你数据准备好了就通知我，所以就衍生了信号驱动IO模型。

信号驱动IO不是用循环请求询问的方式去监控数据的就绪状态，而是在调用sidaction时建立一个SIGIO的信号联系，当内核数据准备好之后，再通过SIGIO信号通过线程数据准备好后的可读状态，当线程收到可读状态的信号后，此时再向内核发起recvform的请求，因为信号驱动IO模型下应用程序在发出信号监控后即可返回，不会阻塞，所以这样的方式下，一个应用线程也可监视多个fd，类似于下图描述：

 3.4.2、术语

首先开启套接口驱动IO功能，并通过系统调用sigaction执行一个信号处理函数，此时请求即刻返回，当数据准备就绪时，就生成对应进程的SIGIO信号，通过信号回调通知应用线程调用recvform来读取数据。

3.4.3、图解

 3.4.4、总结

IO复用模型里面的select虽然可以监视多个fd，但是select实现的本质还是通过不断的轮询fd来监控数据状态，其中大部分的轮询请求都是无效的，所以信号驱动IO意在通过这种建立信号关联的方式，实现了发出请求后只需要等待数据就绪的通知即可，以此避免了大量无效的数据状态轮询操作。 

 3.5、异步IO模型

 3.5.1、概述

经过IO复用模型和信号驱动IO模型，我们可以发现，在读取一个数据时总是要发起两个阶段的请求，第一个阶段发送请求是要询问数据状态是否准备好，而第二个阶段才是发送recvform来读取数据。

那为什么没有一种方法能够实现只发送一段读取数据的请求就可以的呢？其实是有的。异步IO模型就是如此。应用只需要向内核发送一个read请求，告诉内核它要读取数据，然后立刻返回；内核在收到请求后会建立一个信号联系，当数据准备就绪，内核会主动把数据从内核复制到用户空间，等所有的操作都完成之后，内核会发起一个通知告诉应用。

 3.5.2、术语

应用告知内核启动某个操作，并让内核在整个操作完成之后，通知应用，这种模型与信号驱动模型的主要区别在于：信号驱动IO只是由内核通知我们何时可以开始下一个IO操作，而异步IO模型则是由内核通知我们操作什么时候完成。

3.5.3、图解

 3.5.4、总结

异步IO的优化思想是解决了应用程序需要先发后发送询问请求、读取数据请求两个阶段的模式，在异步IO模型下，只需要向内核发送一次请求就可以完成状态询问和数据拷贝的所有操作。

 四、总结

1. 通常说到的同步阻塞IO、同步非阻塞IO、异步非阻塞IO几种术语，通过上面的内容，现在应该也大致有了些了解。所谓阻塞就是发送读取数据请求后，当数据还没准备就绪时，如果等待就是阻塞，不等待立刻返回就是非阻塞；
2. 同步和异步的区别就是：在IO模型里如果请求方从发起请求到数据完成的这一整个阶段都需要自己参与，就称为同步请求；而如果请求方在发送完请求后就不再参与过程，只需等待最终完成结果的通知，就称为异步；
3. 同步阻塞和同步非阻塞：都需要全程参与数据完成的过程，但同步阻塞在数据未就绪时需要等待，同步非阻塞不需等待；
4. 异步非阻塞：为什么只有异步非阻塞没有异步阻塞呢？因为在发送完请求后，直接就返回了，根本就没有后续，所以不可能存在异步阻塞。