IO复用

IO复用简介

IO复用使得程序能同时监听多个文件描述符，这对提高程序的性能至关重要。通常，网络程序在下列情况下需要使用IO复用技术：

• 客户端程序要同时处理多个socket。
• 客户端程序要同时处理用户输入和网络连接。
• TCP服务器同时处理监听socket和连接socket。
• 服务器要同时处理TCP请求和UDP请求。

需要指出的是，IO复用虽然能同时监听多个文件描述符，但它本身是阻塞的。并且当多个文件描述符同时就绪时，如果不采取额外的措施，程序就只能按顺序依次处理其中的每一个文件描述符，这使得服务器程序看起来像是串行工作的。如果要实现并发，只能使用多进程或多线程等编程手段。

Linux下实现IO复用的系统调用主要有select、poll和epoll。

select系统调用

select系统调用的用途是：在一段指定时间内，监听用户感兴趣的文件描述符上的可读、可写和异常事件。

select API

select系统调用的原型如下：

#include <sys/select.h> #include <sys/time.h> int select(int maxfd, fd_set *readfds, fd_set *writefds, fe_set *exceptfds, const struct timeval *timeout); 

1）maxfd参数指定被监听的文件描述符的总数。它通常被设置为select监听的所有描述符中的最大值加1，因为文件描述符是从0开始计数的。

2）readfds、writefds和exceptfds参数分别指向可读、可写和异常等事件对应的文件描述符中集合。应用程序调用select函数时，通过这3个参数传入自己感兴趣的文件描述符。select调用返回时，内核将修改它们来通知应用程序哪些文件描述符已经就绪。这3个参数是fd_set结构体指针类型。
由于位操作过于繁琐，我们应该使用下面的一系列宏来访问fd_set结构体中的位：

void FD_CLR(int fd, fd_set *fdset)     /* 清除fdse所有位.*/int FD_ISSET(int fd, fd_set *fdset)    /* 测试fdset的位fd是否被设置 */void FD_SET(int fd, fd_set *fdset)     /* 设置fdset的位fd */void FD_ZERO(fd_set *fdset)            /* 清除fdset的位fd */

3）timeout参数用来设置select函数的超时时间。它是一个timeval结构类型的指针，采用指针参数是因为内核将修改它以告诉程序select等待了多久。不过我们不能完全信任select调用返回后的timeout值，比如调用失败时timeout值是不确定的。timeout结构体的定义如下：

struct timeval {       long tv_sec; // seconds       long tv_usec; // and microseconds};

由上定义可知，select给我们提供了一个微秒级的定时方式。如果给timeout变量的tv_sec成员和tv_usec成员都传递0，则select将立即返回。如果给timeout传递NULL，则select将一直阻塞，直到某个文件描述符就绪。

select成功时返回就绪（可读、可写和异常）文件描述符的总数。如果在超时时间内没有任何文件描述符就绪，select将返回0.select失败时返回-1并设置errno。如果在select等待期间，程序收到信号，则select立即返回-1，并设置errno为EINTR。

文件描述符就绪条件

哪些情况下文件描述符可以被认为是可读、可写或异常，对于select的使用非常关键。在网络编程中，下列情况下socket可读：

• socket内核接收缓存区中的字节数大于或等于其低水位标记SO_RCVLOWAT。此时我们可以无阻塞地读该socket，并且读操作返回的字节数大于0.
• socket通信的对方关闭连接。此时对改socket的读操作将返回0.
• 监听socket上有新的连接请求。
• socket上有未处理的错误。此时我们可以使用getsockopt来读取和清除该错误。

下列情况下socket可写：

• socket内核发送缓存区中的可用字节数大于或等于其低水位标记SO_SNDLOWAT。此时我们可以无阻塞地写该socket，并且写操作返回的字节数大于0.
  
• socket的写操作被关闭。对写操作被关闭的socket执行写操作将触发一个SIGPIPE信号。
• socket使用非阻塞connect连接成功或者失败（超时）之后。
• socket上有未处理的错误。此时我们可以使用getsockopt来读取和清除该错误。

网络编程中，select能处理的异常情况只有一种;socket接受到带外数据。

poll系统调用

poll系统调用和select类似，也是在指定时间被轮询一定数量的文件描述符，以测试其中是否有就绪者。poll的原型如下：

#include <poll.h>int   poll(struct pollfd *fd, nfds_t nfds, int timeout);

1）fds参数是一个pollfd结构类型的数组，它指定所有我们感兴趣的文件描述符上发生的可读、可写和异常等事件。pollfd结构体的定义如下：

struct pollfd {       int fd;        /* 文件描述符 */       short events; /* 等待的事件 */       short revents; /* 实际发生了的事件 */};

其中，fd成员指定文件描述符；events成员告诉poll监听fd上的哪些事件，它是一系列事件的按位或；revents成员则由内核修改，以通知应用程序fd上实际发生了哪些事件。

POLLIN 　　　　　　　　有数据可读。
　　POLLRDNORM 　　　　  有普通数据可读。
　　POLLRDBAND　　　　　 有优先数据可读。
　　POLLPRI　　　　　　　　 有紧迫数据可读。
　　POLLOUT　　　　　　      写数据不会导致阻塞。
　　POLLWRNORM　　　　　  写普通数据不会导致阻塞。
　　POLLWRBAND　　　　　   写优先数据不会导致阻塞。
　　POLLMSGSIGPOLL 　　　　消息可用。
　　此外，revents域中还可能返回下列事件：
　　POLLER　　   指定的文件描述符发生错误。
　　POLLHUP　　 指定的文件描述符挂起事件。
　　POLLNVAL　　指定的文件描述符非法。
这些事件在events域中无意义，因为它们在合适的时候总是会从revents中返回。

2）nfds参数指定被监听事件集合fds的大小。其类型nfds_t的定义如下：

typedef unsigned long int nfds_t;

3）timeout参数指定poll的超时值，单位是毫秒。当timeout为-1时，poll调用将永久阻塞，直到某个事件发生；当timeout为0时，poll调用将立即返回。

poll系统调用的返回值的含义与select相同。

epoll系列系统调用

内核事件表

epoll是Linux特有的IO复用函数。它在实现和使用上与select、poll有很大差异。首先，epoll使用一组函数来完成任务，而不是单个函数。其次、epoll把用户关心的文件描述符上的事件放在内核里的一个事件表中，从而无须像select和poll那样每次调用都要重复传入文件描述符集或事件集。但epoll需要使用一个额外的文件描述符，来唯一标识内核中的这个事件表。这个文件描述符使用如下epoll_reate函数来创建：

#include<sys/epoll.h>int epoll_create(int size);

size参数现在并不 起作用，只是给内核一个提示，告诉它事件表需要多大。该函数返回的文件描述符将用作其他所有epoll系统调用的第一个参数，以指定要访问的内核事件表。

下面的函数用来操作epoll的内核事件表：

#include <sys/epoll.h>int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

fd参数是要操作的文件描述符，op参数则指定操作类型。操作类型有如下3种：

• EPOLL_CTL_ADD，往事件表中注册fd上的事件。
• EPOLL_CTL_MOD，修改fd上的注册事件。
• EPOLL_CTL_DEL，删除fd上的注册事件。

events参数指定事件，它是epoll_event结构指针类型。epoll_event的定义如下：

struct epoll_event {       __uint32_t events; /* Epoll events */       epoll_data_t data; /* User data variable */};

其中events成员描述事件类型。epoll支持的事件类型和poll基本相同。表示epoll事件类型的宏是在poll对应的宏前加上“E”,比如epoll的数据可读事件是EPOLLIN。但epoll有两个额外的事件类型——EPOLLET和EPOLLONESHOT。它们对于epoll的高效运作非常关键，我们将在后面讨论它们。data成员用于存储用户数据。

epoll_ctl成功时返回0，失败则返回-1并设置errno。

epoll_wait函数

epoll系列系统调用的主要接口是epoll_wait函数。它在一段超时时间内等待一组文件描述符上的事件，其原型如下：

#include <sys/epoll.h>int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);

该函数成功时返回就绪的文件描述符的个数，失败时返回-1并设置errno。

关于该函数的参数，我们从后往前讨论。timeout参数的含义与poll接口的timeout参数相同。maxevents参数指定最多监听多少个事件，它必须大于0.

epoll_wait函数如果检测到事件，就将所有就绪的事件从内核事件表（由epfd参数指定）中复制到它的第二个参数events指向的数组中。这个数组只用于输出epoll_wait检测到的就绪事件，而不像select和poll的数组参数那样既用于传入用户注册的事件，又用于输出内核检测到的就绪事件。这就极大地提高了应用程序索引就绪文件描述符的效率。

LT和ET模式

epoll对文件描述符的操作有两种模式;LT(Level Trigger，电平触发)模式和ET（Edge Trigger，边沿触发）模式。LT模式是默认的工作模式，这种模式下epoll相当于一个效率较高的poll。当往epoll内核事件表中注册一个文件描述符上的EPOLLET事件时，epoll将以ET模式来操作该文件描述符。ET模式是epoll的高效工作模式。

对于采用LT工作模式的文件描述符，当epoll_wait检测到其上有事件发生并将此事件通知应用程序后，应用程序可以不立即处理该事件。这样，当应用程序下一次调用epoll_wait时，epoll_wait还会再次向应用程序通告此事件，直到该事件被处理。而对于采用ET工作模式的文件描述符，当epoll_wait检测到其上有事件发生并将此事件通知应用程序后，应用程序必须立即处理该事件，因为后序的epoll_wait调用将不再想应用程序通知这一事件。可见，ET模式在很大程度上降低了同一个epoll事件被重复触发的次数，因此效率要比LT模式高。

EPOLLONESHOT事件

即使我们使用ET模式，一个socket上的某个事件还是可能被触发多次。这在并发程序中就会引发一个问题。比如一个线程（或进程，下同）在读取完某个socket上的数据后开始处理这些数据，而在数据的处理过程中该socket上又有新数据可读（EPOLLIN再次被触发），此时另外一个线程被唤醒来读取这些新的数据。于是就出现了两个线程同时操作一个socket的局面。这当然不是我们期望的。我们期望的是一个socket连接在任意时刻都只能被一个线程处理。这一点可以使用epoll的EPOLLONESHOT事件来实现。

对于注册了EPOLLONESHOT事件的文件描述符，操作系统最多触发其上注册的一个可读、可写或者异常事件。这样，当一个线程在处理某个socket时，其他线程是不可能有机会操作该socket的。但反过来思考，注册了EPOLLONESHOT事件的socket一旦被某个线程处理完毕，该线程就应该立即重置这个socket的EPOLLONESHOT事件，以确保这个socket下一次可读时，其EPOLLIN事件能被触发，进而让其他工作线程有机会继续处理这个socket。

epoll的优点

1）支持一个进程打开大数目的socket描述符(FD)
    select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置， 默认值是2048。对于那些需要支持上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样 会带来网络效率的下降；二是可以选择多进程的解决方案(传统的Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加 上进程间数据同步远比不上线程间同步高效，所以这也不是一种完美的方案。不过epoll 没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于select 所支持的2048。举个例子，在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看，一般来说这个数目和系统内存关系很大。
2）IO效率不随FD数目增加而线性下降
    传统select/poll的另一个致命弱点就是当你拥有一个很大的socket集合，由于网络得延时，使得任一时间只有部分的socket是"活跃" 的，而select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进 行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。于是，只有"活跃"的socket才会主动去调用 callback函数，其他idle状态的socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll也不比select/poll低多少效率，但若 过多使用的调用epoll_ctl，效率稍微有些下降。然而一旦使用idle connections模拟WAN环境，那么epoll的效率就远在select/poll之上了。
3） 使用mmap加速内核与用户空间的消息传递
    这点实际上涉及到epoll的具体实现。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就显 得很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你像我一样从2.5内核就开始关注epoll的话，一定不会忘记手 工mmap这一步的。
4） 内核微调
    这一点其实不算epoll的优点，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比 如，内核TCP/IP协议栈使用内存池管理sk_buff结构，可以在运行期间动态地调整这个内存pool(skb_head_pool)的大小---通 过echo XXXX>/proc/sys/net/core/hot_list_length来完成。再比如listen函数的第2个参数(TCP完成3次握 手的数据包队列长度)，也可以根据你平台内存大小来动态调整。甚至可以在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的 NAPI网卡驱动架构。