linux 5中io模型

1.5种io模型

阻塞IO（bloking IO）
非阻塞IO（non-blocking IO）
多路复用IO（multiplexing IO）
信号驱动式IO（signal-driven IO）

异步IO（asynchronous IO）

一个输入操作通常包括两个阶段：
1.等待数据准备好

2.从内核向进程复制数据

缓存IO（又被称为标准io）：IO的数据缓存在文件系统的页缓存（page cache）中（先拷贝到内核的缓冲区），前4种io模型均需要，异步io不需要

并发：同时进行的任务数

并行：同时工作的物理资源数量（如CPU核数）

阻塞IO和非阻塞IO的区别：数据准备的过程中,进程是否阻塞。

同步IO和异步IO的区别：数据拷贝的过程中,进程是否阻塞。

1.1 BIO（blocking IO）：同步阻塞 I/O（能够及时返回数据，无延迟；性能下降）

当用户进程进行系统调用时，内核就开始了I/O的第一个阶段，准备数据到缓冲区中，当数据都准备完成后，则将数据从内核缓冲区中拷贝到用户进程的内存中，这时用户进程才解除block的状态重新运行。

Blocking I/O是在I/O执行的两个阶段都被block了

1.2 NIO（nonblocking IO）：同步非阻塞 I/O（拷贝数据的整个过程，进程仍然是阻塞的；需要不断询问数据是否准备好了；能够在等待任务完成的过程中处理其他事件；由于需要轮询，所以延迟会增加）

我们把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。

当一个应用程序像这样对一个非阻塞描述符循环调用recvfrom时，我们称之为轮循(polling)

在I/O执行的两个阶段中，用户进程只有在第二个阶段被阻塞了，而第一个阶段没有阻塞，但是在第一个阶段中，用户进程需要盲等，不停的去轮询内核，看数据是否准备好了。

1.3 多路复用IO（ IO multiplexing）（IO多路复用阻塞在select/epoll的系统调用之上的，而真正的IO系统调用如recvfrom是非阻塞的。）

I/O复用模型会用到select或者poll函数，这两个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。 

如果循环查询多个任务的完成状态，只要有任何一个任务完成，就去处理它。轮询不是进程的用户态。这时 “IO 多路复用”就出现了。即UNIX/Linux 的 select、poll、epoll，IO多路复用是阻塞在select，epoll这样的系统调用之上，而没有阻塞在真正的I/O系统调用如recvfrom之上。从整个IO过程来看，他们都是顺序执行的，因此可以归为同步模型(synchronous)。都是进程主动等待且向内核检查状态

同步是需要主动等待消息通知，而异步则是被动接受消息通知，通过回调、通知、状态等方式来被动获取消息。IO多路复用在阻塞到select阶段时，用户进程是主动等待并调用select函数来获取就绪状态消息，并且其进程状态为阻塞。所以IO多路复用是同步阻塞模式。

1.4 信号驱动I/O（ signal driven IO）

从上图可以看出，只有在I/O执行的第二阶段阻塞了用户进程，而在第一阶段是没有阻塞的。该模型在I/O执行的第一阶段，当数据准备完成之后，会主动的通知用户进程数据已经准备完成，即对用户进程做一个回调。该通知分为两种，一为水平触发，即如果用户进程不响应则会一直发送通知，二为边缘触发，即只通知一次。

当有I/O时间的时候操作系统会触发 SIGIO 信号。在程序里只需要绑定 SIGIO 信号的处理函数就可以了。操作系统只负责参数信号而实际的信号处理函数必须由用户空间的进程实现。

应用程序提交read请求，调用system call，然后内核开始处理相应的IO操作，而同时，应用程序并不等内核返回响应，就会开始执行其他的处理操作（应用程序没有被IO阻塞），当内核执行完毕，返回read响应，就会产生一个信号或执行一个基于线程的回调函数来完成这次IO处理过程。在这里IO的读写操作是在IO事件发生之后由应用程序来完成。异步IO读写操作总是立即返回，而不论IO是否阻塞，因为真正的读写操作已经有内核掌管。也就是说同步IO模型要求用户代码自行执行IO操作（将数据从内核缓冲区移动用户缓冲区或者相反），而异步操作机制则是由内核来执行IO操作（将数据从内核缓冲区移动用户缓冲区或者相反）。可以这样认为，同步IO向应用程序通知的是IO就绪事件，而异步IO向应用程序通知的是IO完成事件。

1.5 异步 I/O（asynchronous IO）

在该模型中，用户进程调用aio_read函数，告诉内核描述字，缓冲区指针，缓冲区大小，文件偏移以及通知的方式，然后立刻就可以开始去做其它的事情。当内核将数据拷贝到缓冲区后，再通知应用程序。用户进程直接操作数据即可。

异步 I/O执行的两个阶段都不会阻塞。

2.几种I/O模型的比较

前四种模型的区别是第一阶段，而第二阶段基本相同，都是将数据从内核拷贝到调用者的缓冲区。而异步I/O的两个阶段都不同于前四个模型。

同步I/O操作引起请求进程阻塞，直到I/O操作完成；异步I/O操作不引起请求进程阻塞。 
我们的前四个模型都是同步I/O，只有最后一个异步I/O模型是异步I/O。

3.select poll epoll

select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

epoll属于linux特有的

select很多系统都支持

3.1 select

select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

（1）使用copy_from_user从用户空间拷贝fd_set到内核空间
（2）注册回调函数__pollwait（主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，把进程挂到等待队列中并不代表进程已经睡眠了）
（3）遍历所有fd，调用其对应的poll方法（会包含__pollwait，也就是上面注册的回调函数）
（4）poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值（如果没有返回就说明还没有数据，还在阻塞等待，若所有的都在阻塞等待，则进程进入睡眠状态，直到设备就绪以后，进程被唤醒后再次遍历所有的fd）。
（5）如果遍历完所有的fd，还没有返回一个可读写的mask掩码（个人理解：说明如果没有资源可读写，有可能不会返回，被阻塞），则会调用schedule_timeout使调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程，遍历所有fd。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。
（6）把fd_set从内核空间拷贝到用户空间。

缺点：（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大

（3）select支持的文件描述符数量太小了，默认是1024

3.2 poll

poll的实现和select非常相似，只是描述fd集合的方式不同，poll使用pollfd结构而不是select的fd_set结构，其他的都差不多。

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

poll的fd使用的是链表，文件描述符数量不受限制

缺点与select相比，除了第三点，前两点也是poll的缺点

3.3 epoll

epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait，epoll_create是创建一个epoll句柄；epoll_ctl是注册要监听的事件类型；epoll_wait则是等待事件的产生。
对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。
对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果（个人感觉就是轮训），和select实现中的第7步是类似的）。
对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：
LT模式：并且同时支持block和no-block socket,当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件（如果不做任何操作的情况下）。
ET模式：是高速工作方式，只支持no-block socket，当epoll_wait检测到描述符事件发生并将此事件通知应用程序，然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)（个人理解，即它为未就绪状态时，可以接收到就绪通知）。

总结：

（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

【名词解释】

水平触发:如果文件描述符已经就绪可以非阻塞的执行IO操作了,此时会触发通知.允许在任意时刻重复检测IO的状态.select,poll就属于水平触发.
边缘触发:如果文件描述符自上次状态改变后有新的IO活动到来,此时会触发通知.在收到一个IO事件通知后要尽可能多的执行IO操作,因为如果在一次通知中没有执行完IO那么就需要等到下一次新的IO活动到来才能获取到就绪的描述符.信号驱动式IO就属于边缘触发.