简单流程梳理

我们先从只监听一个socket开始讲起：

首先我们有一个程序A，他运行这下面这样一段代码：

//创建socket
int s = socket(AF_INET, SOCK_STREAM, 0);   
//绑定端口
bind(s, ...)
//监听
listen(s, ...)
//接受客户端连接
int c = accept(s, ...)
//接收客户端数据，没有数据就先阻塞在这里
recv(c, ...);
//将数据打印出来
printf(...)

当程序A运行到recv()的时候它阻塞了，

之后就挂起在等待队列中，等待被唤醒之后继续执行，

而在Linux中，万事万物皆为文件，我们的socket也占用了一个fd。

我们的A就挂在socket中的等待队列中。

接下来我们来看一个简单的流程：

首先第一步是通过网线发送数据到网卡
网卡将数据存到内存中
网卡对cpu发出中断信号，提醒cpu过来处理网卡的任务
cpu接到信号后暂时中断自己的任务，过来运行网卡准备的中断程序
中断程序的内容是：将网卡写到内存中的网络数据写入socket的输入缓冲区
然后中断程序再唤醒处于阻塞状态的A唤醒，并挂到工作队列中让cpu运行它，而cpu就会运行刚刚代码的最后一段：打印

//将数据打印出来
printf(...)

当然，实际应用中我们不可能只监听一个socket，接下来我们就直接来看一下，能监听多个socket的select是怎么实现的：

select

select：上世纪 80 年代就实现了，它支持注册 FD_SETSIZE(1024) 个 socket，在那个年代肯定是够用的，不过现在嘛，肯定是不行了。

当然，这里的select不是指nio里的select()方法，而是指操作系统中的一个实现，它的改进版本是poll和epoll，请大家注意不要混淆。

我们先从select说起：

int s = socket(AF_INET, SOCK_STREAM, 0);  
bind(s, ...);
listen(s, ...);
int fds[] =  // 存放需要监听的socket;
while(1){
    // 这里就是我们的select
    int n = select(..., fds, ...)
    for(int i=0; i < fds.count; i++){
        if(FD_ISSET(fds[i], ...)){
            //fds[i]的数据处理
        }
    }
}

这段代码中，先准备了一个数组 fds，让 fds 存放着所有需要监视的 socket。然后调用 select，如果 fds 中的所有 socket 都没有数据，select 会阻塞，直到有一个 socket 接收到数据，select 返回，唤醒进程。用户可以遍历 fds，通过 FD_ISSET 判断具体哪个 socket 收到数据，然后做出处理。

接下来我们看一下流程图：

流程基本都一样，A却存在于多个socket的等待队列中
当某个socket被写入数据时，A也被唤醒并从多个socket的等待队列中移除后加入工作队列
但是此时A并不知道是哪个socket被写入了数据，所以只能遍历所有socket
在A处理完任务后移出工作队列，但是此时却需要遍历所有socket并加入它们的等待队列中

select的缺点在于：

每次调用 select 都需要将进程加入到所有监视 socket 的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历，而且每次都要将整个 fds 列表传递给内核，有一定的开销。正是因为遍历操作开销大，出于效率的考量，才会规定 select 的最大监视数量，默认只能监视 1024 个 socket。
进程被唤醒后，程序并不知道哪些 socket 收到数据，还需要遍历一次。

poll

因此人们先提出了poll

poll：1997 年，出现了 poll 作为 select 的替代者，最大的区别就是，poll 不再限制 socket 数量。

但是poll并没有解决刚刚提到的select的问题，所以就有了epoll

epoll

select 低效的原因之一是将“维护等待队列”和“阻塞进程”两个步骤合二为一。如下图所示，每次调用 select 都需要这两步操作，然而大多数应用场景中，需要监视的 socket 相对固定，并不需要每次都修改。epoll 将这两个操作分开，先用 epoll_ctl 维护等待队列，再调用 epoll_wait 阻塞进程。显而易见地，效率就能得到提升。