IO复用简单介绍
IO复用使得程序能同一时候监听多个文件描写叙述符。这对提高程序的性能至关重要。通常。网络程序在下列情况下须要使用IO复用技术:
- client程序要同一时候处理多个socket。
- client程序要同一时候处理用户输入和网络连接。
- TCPserver同一时候处理监听socket和连接socket。
- server要同一时候处理TCP请求和UDP请求。
须要指出的是。IO复用尽管能同一时候监听多个文件描写叙述符,但它本身是堵塞的。而且当多个文件描写叙述符同一时候就绪时,假设不採取额外的措施。程序就仅仅能按顺序依次处理当中的每个文件描写叙述符,这使得server程序看起来像是串行工作的。假设要实现并发,仅仅能使用多进程或多线程等编程手段。
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。
对于那些须要支持上万连接数目的IMserver来说显然太少了。这时候你一是能够选择改动这个宏然后又一次编译内核,只是资料也同一时候指出这样 会带来网络效率的下降;二是能够选择多进程的解决方式(传统的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网卡驱动架构。