网络IO-select,poll,epoll分析

背景介绍

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

其实在对select,poll和epoll进行分析前,需要对linux系统产生的五种网络模式简单介绍,但是由于我主要学习Java,对linux不台熟悉,而且在刚开始学习网络IO时过多的纠结在同步与异步和阻塞与非阻塞上,因此在日后的学习中不再区分这些概念,对于linux系统的5种网络模式也一样不再深究,只是区分不同网络模式在Java上的表现是否相同.现在学习select,poll和epoll也是因为了解到Netty解决了epoll的一个bug,顺便深入学习一下.

select

函数介绍

函数名

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

参数及返回值介绍

函数参数介绍如下：

1. 第一个参数maxfdp1指定待测试的文件描述符个数，它的值是待测试的最大文件描述符加1(因此把该参数命名为maxfdp1),文件描述符0、1、2…maxfdp1-1均将被测试,因为文件描述符是从0开始的.
2. 中间的三个参数readset、writeset和exceptset指定我们要让内核测试读、写和异常条件的描述字。如果对某一个的条件不感兴趣，就可以把它设为空指针。fd_set是文件描述符集合.
3. timeout是等待时间,告知内核等待所指定描述字中的任何一个就绪可花多少时间。其timeval结构用于指定这段时间的秒数和微秒数。

实现原理

睡眠等待逻辑

1. 将等待读事件的fd_set从用户空间拷贝到内核空间
2. 遍历fd_set,若某个文件描述符有读事件,直接返回;若文件描述符没有读事件,则为当前process构建一个wait_entry节点，然后插入到被监控socket的sleep_list中
   
3. 遍历fd_set结束后仍未返回,当前process睡眠

唤醒逻辑

1. 若fd_set中有某个socket有数据可读,则会唤醒该socket的sleep_list中正在睡眠的process
2. process被唤醒后,再次遍历fd_set,此时在fd_set必定有至少一个fd有读事件

缺点

1. 每次调用select()必须将三个fd_set从用户空间拷贝到内核空间
2. 为了减少数据拷贝带来的性能损坏，内核对被监控的fd_set集合大小做了限制，并且这个是通过宏控制的，大小不可改变(限制为1024)
3. process被唤醒后,必须要再次遍历fd_set,才能确定是哪个socket上有数据可读

poll-鸡肋

函数介绍

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

pollfd封装了文件描述符和等待的事件,相当于使用pollfd代替fd_set

优缺点

1. 解决了select()的1024问题
2. 其余两个关乎性能的问题没有解决

epoll

解决问题思路

在计算机行业中，有两种解决问题的思想:

[1] 计算机科学领域的任何问题, 都可以通过添加一个中间层来解决
[2] 变集中(中央)处理为分散(分布式)处理

我们就按照上述的两个思想尝试解决select剩下的两个问题

变集中为分散解决fd_set拷贝问题

每次select都要将fd_set从用户空间拷贝到内核空间中,但是fd_set的改变次数相较于select的执行次数是非常少的,因此我们可以将select()中的复制fd_set和遍历fd_set两个逻辑分开,每个逻辑由一个函数完成.(其实就是将fd_set的复制从集中复制变为分散增加)
epoll引入了int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)用于添加和删除fd集合,具体的遍历及等待逻辑是在int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout)中完成

添加中间层解决process被唤醒后遍历fd_set的问题

当process从睡眠中被唤醒时,虽然此时fd_set中至少会有一个fd有读事件,但仍然需要再次遍历fd_set,当fd_set很大时,遍历的大多操作是无用的,因此如果我们能将就绪的fd放在单独的列表中,就可以避免无效遍历.

如何才能将就绪的fd放在单独的ready_list中?
在select()中是将process封装为wait_entry放在socket的sleep_list中,如果我们将一个callback函数封装为wait_entry,此函数的逻辑是将当前socket放置在ready_list中.那么当socket有读事件时,便会执行该函数,将socket放入ready_list中

process的睡眠与唤醒问题?
有了ready_list后,process的睡眠和唤醒时机便很明显.当ready_list为空时睡眠,ready_list非空时唤醒

如和将ready_list串联在一起?
个人感觉是通过int epoll_create(int size);返回的fd将一切串联在一起的.即process是睡眠在epoll_create()返回的fd上,根据ready_list的空与非空将process睡眠与唤醒.

函数介绍

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的fd作为中间层并返回

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

将被监听的socket拷贝至内核空间,并且将callback封装为wait_entry挂在socket的sleep_list上.

添加两个被监听的socket后

再添加2个被监听的socket后

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

若调用epoll_wait()时无就绪的fd,则当前process会睡眠在中间层fd的sleep_list中

若一段时间后,sk1和sk2都有读事件到达,则分别会执行sk1和sk2的callback,将sk1和sk2放入中间层fd的read_list中,同时唤醒睡眠在中间层fd的process

process被唤醒后,遍历read_list,此时read_list中全是有读事件的sk,不会产生无用遍历

总结

1. 此篇博客只是介绍了下epoll解决select存在问题的大致思路,具体情况还请查找相关资料
2. 无epoll的ET和LT模式介绍.

参考

• 大话 Select、Poll、Epoll,思路非常清楚,强烈推荐
• select、poll、epoll之间的区别总结[整理],介绍比较详细