IO多路复用之select,poll,epoll

背景

通过操作系统记录的进程控制信息可以找到打开文件描述符表，
里面包含着进程打开的文件、创建的socket等。
socket的所有操作都需要由操作系统的系统调用来完成。
每创建一个socket,就会在文件描述符表中增加一条记录，返回给应用程序的只有一个socket描述符，用于识别不同的socket。
每个TCP socket创建时，操作系统都会为其分配一个读缓冲区和写缓冲区，要获得响应数据就需要从读内核空间的读缓冲区拷贝到用户空间，同样想发送数据时，需要把用户空间的数据拷贝到写缓冲区，然后再发送给服务器。

问题来了，想读数据的时候，读缓冲区里不一定有数据，想发送的时候写缓冲区不一定有地方。

解决办法

第一种，阻塞式IO
在发现缓冲区没有数据或者没有空间的时候，就让出CPU，进入等待队列里，等socket就绪后，再次获得时间片时，就可以执行了。
使用阻塞式IO，要处理一个socket就需要一个线程。这在高并发场景下会加剧调度开销。
第二种，非阻塞式IO
在发现缓冲区没有准备好时，就频繁的检查socket是否就绪，直到就绪了就执行。这是一种“忙等待”的方式，很难把握轮询的间隔时间，容易造成空耗CPU，浪费系统资源。
第三种 , IO多路复用
由操作系统提供支持，把需要等待的socket加入监听集合，这样就可以通过一次系统调用，同时监听多个socket，有一个socket就绪了就可以进行处理了。
既不用为等待某个socket而阻塞，也不用陷入忙等待之中。

IO多路复用方式

第一种 Select

在这里插入支持监听三种模式，可读，可写，异常。
fd_set为一个unsigned long型的数组，默认监听16*64=1024，不仅是个数，也是文件描述符的最大值。想超出可以更改define,重新编译内核。
每次调用select都要传递所有监听集合，这就需要频繁的从用户态到内核态拷贝数据。而且在得到fd就绪后，并不知道是哪个socket就绪了，还需要遍历整个集合。

第二种 Poll

和select类似

第三种epoll

创建需要监听的socket,把socket添加进去，然后得到的集合都是就绪的，无需遍历所有集合，挨个处理即可。
可能出现的问题，一个socket就绪了，但是只读了一半时间片到了，就需要保存现场，等待下一次就绪再进来处理。
既然要频繁的保存和恢复现场，使用协程就很方便了。

如果是用于监听端口的fd就绪了，就建立连接创建一个新的fd，交给一个协程负责，协程执行入口就指向业务处理函数入口，业务处理过程中，需要等待时就注册IO，让出CPU,回到切换该协程的地方继续执行。
如果是可读或者可写就绪了，就恢复相关联的协程即可。
协程拥有自己的栈，要保存和恢复现场都很容易，这样IO多路复用这一循环就和具体业务逻辑解耦了。

可以把read write connect可能等待的函数包装一下，在其中实现IO事件注册与主动让出，这样在业务逻辑层面就可以使用这些包装函数，按照常规的顺序编程方式来实现事务逻辑，这些包装函数在需要等待时就注册IO时间，然后让出协程。这样在实现业务逻辑时，就不用担心保存和恢复现场的问题了。
协程和IO多路复用的合作，不仅保留了高并发的性能，还解放了业务逻辑的实现。

区别

select是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：

1、 单个进程可监视的fd数量被限制，即能监听端口的大小有限。

​ 一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.

2、 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低：

​ 当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度,不管哪个Socket是活跃的,都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大

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

它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：

1、大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。

2、poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

epoll:

epoll有EPOLLLT和EPOLLET两种触发模式，LT是默认的模式，ET是“高速”模式。LT模式下，只要这个fd还有数据可读，每次 epoll_wait都会返回它的事件，提醒用户程序去操作，而在ET（边缘触发）模式中，它只会提示一次，直到下次再有数据流入之前都不会再提示了，无 论fd中是否还有数据可读。所以在ET模式下，read一个fd的时候一定要把它的buffer读光，也就是说一直读到read的返回值小于请求值，或者 遇到EAGAIN错误。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

总结：

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点。

1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善