select、poll、epoll浅析
select
概念
接口
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
- writefds:”可写“状态的描述符集合
- readfds:”可读“状态的描述符集合
- exceptfds:”异常“状态的描述符集合
- timeout:超时时间
- 返回值:
- -1:所有描述符集清0
- 0:超时
- >0:就绪描述符个数
- 功能:需要轮询来获取就绪的描述符
- 优点
- 良好的跨平台性:目前所有平台支持
- 缺点
- 单进程监听的fd存在最大限制:在linux上FD_SETSIZE一般为1024(32bits)
- 效率低:对socket进行扫描时是线性扫描,即采用轮询的方法
- 开销大:需要维护一个用来存放大量fd的数据结构,这样会使得用户空间和内核空间在传递该结构时复制开销大。
poll
概念
接口
int poll (struct pollfd *fds, unsigned int nfds, int timeout); struct pollfd { int fd; /* file descriptor */ short events; /* requested events to watch */ short revents; /* returned events witnessed */ };
- fds:要监控的描述符集合
- nfds:要监控的描述符数量
- timeout:超时时间
- 返回值:返回就绪的描述符的个数
- 功能:需要轮询来获取就绪的描述符
- 优点
- 不同于select的 参数-值 传递方式
- 没有最大连接数的限制:基于链表
- 缺点
- 开销大:大量的fd的数组被整体复制于用户态和内核地址空间之间
- “水平触发“:如果报告了fd后,没有被处理,那么下次poll时会再次报告该fd。
epoll
概念
接口
int epoll_create(int size);//创建一个epoll的句柄,size用来告诉内核这个监听的数目一共有多大
- size:采用红黑树,size设置无效
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
- epoll_create返回值:epollfd
- epfd:epollfd
- op:
- 添加EPOLL_CTL_ADD
- 删除EPOLL_CTL_DEL
- 修改EPOLL_CTL_MOD
- fd:是需要监听的fd
- epoll_event:监听事件
- EPOLLIN:可读
- EPOLLOUT:可写
- EPOLLET:边沿触发
- …………
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
- maxevents:最多返回maxevents个就绪的描述符
- 返回值:就绪描述符的个数
- 工作模式
- LT:LT(level triggered)是缺省的工作方式,并且同时支持block和no-block socket.在这种做法中,内核告诉你一个文件描述符是否就绪了,然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作,内核还是会继续通知你的。
- ET:ET(edge-triggered)是高速工作方式,只支持no-block socket。在这种模式下,当描述符从未就绪变为就绪时,内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪,并且不会再为那个文件描述符发送更多的就绪通知,直到你做了某些操作导致那个文件描述符不再为就绪状态了。
- ET模式在很大程度上减少了epoll事件被重复触发的次数,因此效率要比LT模式高。epoll工作在ET模式的时候,必须使用非阻塞套接口,以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
优点
- 没有最大描述符限制:使用一个文件描述符管理多个描述符,将用户关系的文件描述符的事件存放到内核的一个事件表中,这样在用户空间和内核空间的copy只需一次。
- 效率提升:
- 使用“事件”的就绪通知方式,通过epoll_ctl注册fd,一旦该fd就绪,内核就会采用类似callback的回调机制来激活该fd,epoll_wait便可以收到通知。(此处去掉了遍历文件描述符,而是通过监听回调的的机制,是epoll最大特点)
- 减小开销:通过内核与用户空间mmap(内存映射)同一块内存,减少复制开销。
缺点
- callback的回调机制的开销。
epool为什么高效?
https://blog.csdn.net/unknow_cdc/article/details/70216654
总结
表面上看epoll的性能最好,但是在连接数少并且连接都十分活跃的情况下,select和poll的性能可能比epoll好,毕竟epoll的通知机制需要很多函数回调。
select低效是因为每次它都需要轮询。但低效也是相对的,视情况而定,也可通过良好的设计改善。
参考网站:
https://www.jianshu.com/p/dfd940e7fca2
https://segmentfault.com/a/1190000003063859
https://cloud.tencent.com/developer/article/1005481