IO模型、IO多路复用、select poll epoll

 

基础知识

    同步、异步

    进程的阻塞

    理解 IO操作

Unix下可用的5种I/O模型

    同步阻塞 IO

    同步非阻塞 IO

    IO 多路复用

    异步 IO

    5中IO模型的比较

    IO多路复用的理解

select poll epoll的区别

 

基础知识

 

高性能架构设计主要有两方面：

1.提高单服务器的性能。

2.服务器采用集群。

 

提升单服务器的性能的关键之一就是服务端采用并发模型。

并发模型主要有两方面：

1.服务器如何管理连接。

2.服务器如何处理请求。

 

以上两点都和 操作系统的 IO模型和进程模型有关。

1.IO模型：阻塞、非阻塞、同步、异步。

2.进程模型：单进程、多进程、多线程。

 

在讨论 IO模型之前，先梳理一下基础知识。

 

同步、异步

 

POSIX术语定义：

同步I/O操作，导致请求进程阻塞，直到I/O操作完成；

异步I/O操作，不导致请求进程阻塞。

 

同步和异步：关注的是通信机制。

同步：发生一个“调用”时，调用方主动等待，一直到被调用方生产出结果，然后返回。

异步：发生一个“调用”时，调用方不等待被调用方的结果，而是直接返回，当被调用方生产出结果后，通知调用方。

 

进程的阻塞

正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。

可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得CPU），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

 

阻塞和非阻塞：关注的是调用方自身的状态。

 

理解 IO操作

对于一次IO的Read：

【数据】—>【内核的缓冲区】————>【应用程序的缓冲区】—>【应用进程】

所以，当一个read操作发生时，它会经历两个阶段：

　　1. 等待数据准备（把数据拷贝到内核）

　　2. 将数据从内核缓存拷贝到进程缓存中

 

同步：（阻塞、非阻塞、IO多路复用）第2步是用户线程自行完成拷贝。此过程用户进程阻塞于 recvfrom调用。

异步：第2步是内核完成拷贝，将数据拷贝到了用户线程指定的缓存区，并通知用户线程。全程无阻塞。

 

 

Unix下可用的5种I/O模型

 

同步模型：

阻塞式I/O：blocking IO

非阻塞式I/O：nonblocking IO ——Socket被设置为NONBLOCK。

I/O复用：IO multiplexing（select和poll）——Reactor设计模式。

信号驱动式I/O：signal driven IO ——不常用。

异步模型：

异步I/O：asynchronous IO（POSIX的aio_系列函数）——Proactor设计模式。

 

【插播】：

陈皓说，异步 I/O 模型的发展技术是： select -> poll -> epoll -> aio -> libevent -> libuv。Unix/Linux 用了好几十年走过这些技术的变迁，然而，都不如 Windows I/O Completion Port 设计得好。

在《从0开始学架构》的评论里有人说，Reactor与Proactor能不能这样打个比方：

1、假如我们去饭店点餐，饭店人很多，如果我们付了钱后站在收银台等着饭端上来我们才离开，这就成了同步阻塞了。

2、如果我们付了钱后给你一个号就可以离开，饭好了老板会叫号，你过来取。这就是Reactor模型。

3、如果我们付了钱后给我一个号就可以坐到坐位上该干啥干啥，饭好了老板会把饭端上来送给你。这就是Proactor模型了。

 

同步阻塞 IO

进程在第一步和第二步都是阻塞的。

伪代码：

{

read(socket, buffer);

process(buffer);

}

 

同步非阻塞 IO

{

while(read(socket, buffer) != SUCCESS)

;

process(buffer);

}

 

IO 多路复用

 

{

select(socket);

while(1) {

sockets = select();

for(socket in sockets) {

if(can_read(socket)) {

read(socket, buffer);

process(buffer);

}

}

}

}

 

异步 IO

 

void UserCompletionHandler::handle_event(buffer) {

process(buffer);

}

{

aio_read(socket, new UserCompletionHandler);

}

 

5中IO模型的比较

 

IO多路复用的理解

 

《unix网络编程》v3的6.1：

在5.12节中，我们看到TCP客户同时处理两个输入：标准输入和TCP套接字。

我们遇到的问题是就在客户阻塞于（标准输入上的）fgets调用期间，服务器进程会被杀死。服务器TCP虽然正确地给客户TCP发送了一个FIN，但是既然客户进程正阻塞于从标准输入读入的过程，它将看不到这个EOF，直到从套接字读时为止（可能已过了很长时间）。

这样的进程需要一种预先告知内核的能力，使得内核一旦发现进程指定的一个或多个I/O条件就绪（也就是说输入已准备好被读取，或者描述符已能承接更多的输出），它就通知进程。这个能力称为I/O复用（I/Omultiplexing），是由select和poll这两个函数支持的。

What we need is the capability

to tell the kernel that we want to be notified if one or more I/O conditions are ready

(i.e., input is ready to be read, or the descriptor is capable of taking more output).

This capability is called I/O multiplexing and is provided by the select and poll functions.

I/O复用典型使用在下列网络应用场合。

• 当客户处理多个描述符（通常是交互式输入和网络套接字）时，必须使用I/O复用。
• 一个客户同时处理多个套接字是可能的，不过比较少见。
• 如果一个TCP服务器既要处理监听套接字，又要处理已连接套接字，一般就要使用I/O复用。
• 如果一个服务器即要处理TCP，又要处理UDP，一般就要使用I/O复用。
• 如果一个服务器要处理多个服务或者多个协议（例如我们将在13.5节讲述的inetd守护进程），一般就要使用I/O复用。

I/O复用并非只限于网络编程，许多重要的应用程序也需要使用这项技术。

 

【我的注解】

对此处的定义的理解：IO复用是一种能力（功能）。

step1. 用户进程先告诉内核：有一些IO，例如：[a，b，c]，如果它们中有准备好的，内核你就通知我。

step2. 内核发现在 [a，b，c]中有准备好了的，然后内核会把“有IO准备好了”这个信息通知给用户进程。

step3. 用户进程再检查哪个IO是准备好的，然后操作这个IO。

这个过程中，内核如果能支持上述的行为，那么内核就支持IO多路复用。

这种解释是从“功能”的角度作出解释。我从字面解释一下：

• case1. 没有IO复用的时候，用户进程需要对自己关心的每一个IO是否准备好，进行查询（非阻塞）。例如，循环对[a,b,c]按个查询，对3个IO对象查询，就好比是走3条不同的“路”。
• case2. 而使用了IO复用后，用户进程不需要对每个IO进行查询，而是内核通知用户进程，只需要这一条“路”。
• 由case1到case2，就好像是需要3条路才能解决的事情，变成了只需1条路就可以解决，即“多路复用”。

 

与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减小了系统的开销。

IO多路复用的具体实现有select、poll和epoll三种。

 

select poll epoll的区别

 

select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。

但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

 

三种IO多路复用进行对比：

 

select

调用过程：

（1）使用 copy_from_user从用户空间拷贝 fd_set到内核空间

（2）注册回调函数 __pollwait

（3）遍历所有fd，调用其对应的poll方法（对于socket，这个poll方法是sock_poll，sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll）

（4）以tcp_poll为例，其核心实现就是__pollwait，也就是上面注册的回调函数。

（5）__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，对于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）。在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。

（6）poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。

（7）如果遍历完所有的fd，还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。

（8）把fd_set从内核空间拷贝到用户空间。

 

select的缺点：

（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大

（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大

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

 

poll

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

 

epoll

epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？

 

在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。

而epoll提供了三个函数：

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察看,一般来说这个数目和系统内存关系很大。

 

总结：

（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内部定义的等待队列）。这也能节省不少的开销。

 

原型

 

select

基于位图型集合，通过宏和fd_set结构体设置事件和检测事件的发生。

最早被提出所以可移植性最好，该实现有以下缺点：

1.每次调用都需要将fd集合从用户空间拷贝到内核空间，完成后再从内核空间拷贝回用户空间，fd很多时开销很大。

2.实现过程是在内核中遍历所有fd，fd很多时开销很大。

3.支持同时可监控的文件描述符数少，1024或2048。

4.fd_set在select返回后会改变，所以再次调用select时需要再次设置fd_set

 

原型：

#include

#include int select(int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *exceptset, const struct timeval *timeout)

 

返回值：就绪描述符的数目，超时返回0，出错返回-1

 

函数参数：

（1）第一个参数 maxfdp1 指定待测试的描述字个数。

它的值是待测试的最大描述字加1（因此把该参数命名为maxfdp1），描述字0、1、2...maxfdp1-1均将被测试。因为文件描述符是从0开始的。

（2）中间的三个参数 readset、writeset和exceptset 指定我们要让内核测试读、写和异常条件的描述字。

如果对某一个的条件不感兴趣，就可以把它设为空指针。

struct fd_set可以理解为一个集合，这个集合中存放的是文件描述符，可通过以下四个宏进行设置：

          void FD_ZERO(fd_set *fdset);           //清空集合

          void FD_SET(int fd, fd_set *fdset);   //将一个给定的文件描述符加入集合之中

          void FD_CLR(int fd, fd_set *fdset);   //将一个给定的文件描述符从集合中删除

          int FD_ISSET(int fd, fd_set *fdset);   // 检查集合中指定的文件描述符是否可以读写 

（3）timeout 告知内核等待所指定描述字中的任何一个就绪可花多少时间。

其timeval结构用于指定这段时间的秒数和微秒数。

         struct timeval{

                   long tv_sec;   //seconds

                   long tv_usec;  //microseconds

       };

这个参数有三种可能：

（1）永远等待下去：仅在有一个描述字准备好I/O时才返回。为此，把该参数设置为空指针NULL。

（2）等待一段固定时间：在有一个描述字准备好I/O时返回，但是不超过由该参数所指向的timeval结构中指定的秒数和微秒数。

（3）根本不等待：检查描述字后立即返回，这称为轮询。为此，该参数必须指向一个timeval结构，而且其中的定时器值必须为0。

 

poll

poll的机制与select类似，与select在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。

poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

 

要比select高级一些，实现和select大致相同，内核中遍历所有文件描述符。使用链表式集合，不需要重复设置监控事件，同时监控文件描述符数远大于select。

缺点也和select大致相同：

1.每次调用都需要将pollfd集合从用户空间拷贝到内核空间，完成后再从内核空间拷贝回用户空间。

2.实现过程是在内核中遍历所有pollfd。

 

原型:

# include

int poll ( struct pollfd * fds, unsigned int nfds, int timeout);

返回值：

    成功时返回revents不为0的文件描述符个数，0表示超时但没有任何事件发生，-1表示失败

参数：

struct pollfd {

    int fd; 文件描述符

    short events; 等待的事件，掩码控制多个事件

    short revents; 实际发生的事件，掩码控制多个事件

}

fds链表是要监控文件描述符的pollfd链表

nfds指定描述符个数

timeout：0表示立即返回，非阻塞；正值表示等待的毫秒数；负值表示无限等待，阻塞模式

 

返回值：revents不为0的pollfd数，-1表示出错

 

events和revents中的事件：

合法事件：

POLLIN 有数据可读

POLLRDNORM 有普通数据可读

POLLRDBAND 有优先数据可读

POLLPRI 有紧迫数据可读

POLLOUT 写数据不会导致阻塞

POLLWRNORM 写普通数据不会导致阻塞

POLLWRBAND 写优先数据不会导致阻塞

POLLMSGSIGPOLL 消息可用不会导致阻塞

非法事件：

POLLER 文件描述符发生错误

POLLHUP 文件描述符挂起事件

POLLNVAL 文件描述符非法

 

epoll

epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

 

通过3个函数来实现，更加高效，当前使用也最多。

在epoll_ctl中注册事件到epoll文件描述符中，把fd全部拷贝进内核，而不是在epoll_wait中重复拷贝。实现中内核通过为每个fd指定一个回调函数，当fd就绪时调用回调函数把就绪fd加入一个就绪链表，epoll_wait只需要查看这个就绪链表是否有就绪fd就可。可监控文件描述符数是系统可同时打开文件数（超过10万）

 

原型：

#include

int epoll_create(int size);

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

 

int epoll_create(int size); //返回epoll文件描述符，size表示要监听的数目 （这个返回的fd要记得close）

创建一个epoll的句柄，size用来告诉内核这个监听的数目一共有多大。这个参数不同于select()中的第一个参数，给出最大监听的fd+1的值。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

 

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); //epoll事件注册函数

epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件epoll的事件注册函数，它不同与select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

参数：

epfd 是epoll_create返回的值

op 是动作：

EPOLL_CTL_ADD：注册新的 fd到epfd中；

EPOLL_CTL_MOD：修改已注册的fd的监听事件；

EPOLL_CTL_DEL：从epfd删除1个fd。

fd 是要监听的fd

event 是告诉内核要监听什么事件

struct epoll_event{

__uint32_t events; //epoll events

epoll_data_t data; //user data variable

}

event是宏的集合：

EPOLLIN ：表示对应的文件描述符 可以读（包括对端SOCKET正常关闭）；

EPOLLOUT：表示对应的文件描述符 可以写；

EPOLLPRI：表示对应的文件描述符 有紧急的数据可读（这里应该表示有带外数据到来）；

EPOLLERR：表示对应的文件描述符 发生错误；

EPOLLHUP：表示对应的文件描述符 被挂断；

EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。

EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到 EPOLL队列里

 

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); //等待事件发生

等待事件的产生，类似于select()调用。

参数：

events 用来从内核得到事件的集合，是返回的事件链表；

maxevents 告之内核这个events链表元素个数，这个maxevents的值不能大于创建epoll_create()时的size

timeout是超时时间（毫秒，0会立即返回，非阻塞；正值表示等待的毫秒数；负值表示无限等待，阻塞模式）。

 

返回值：

需要处理的事件数，通过events返回需要处理的事件。（通过events[i].data.fd和events[i].events匹配判断）

 

工作模式

　　epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。

LT模式是默认模式，LT模式与ET模式的区别如下：

　　LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。

　　ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。

　　ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

 

参考：

https://www.cnblogs.com/zingp/p/6863170.html

http://www.cnblogs.com/fanzhidongyzby/p/4098546.html

http://www.cnblogs.com/Anker/p/3265058.html

《UNIX网络编程》

服务器回射echo程序：

select：http://www.cnblogs.com/Anker/archive/2013/08/14/3258674.html

poll：http://www.cnblogs.com/Anker/archive/2013/08/15/3261006.html

epoll：http://www.cnblogs.com/Anker/archive/2013/08/17/3263780.html