网络面试题：select，poll，epoll原理

一. 背景知识

1. 计算机是如何接收数据的

从网卡接收数据说起：

下边是一个典型的计算机结构图，计算机由 CPU、存储器(内存)与网络接口等部件组成，先从硬件的角度看计算机怎样接收网络数据。

下图展示了网卡接收数据的过程：

• 在 1 阶段，网卡收到网线传来的数据。
• 经过 2 阶段的硬件电路的传输。
• 最终 3 阶段将数据写入到内存中的某个地址上。

这个过程涉及到 DMA 传输、IO 通路选择等硬件有关的知识，但我们只需知道：网卡会把接收到的数据写入内存。

网卡接收数据的过程：
通过硬件传输，网卡接收的数据存放到内存中，操作系统就可以去读取它们。

2. 计算机如何知道要接受数据？（中断）

答：中断

• 计算机执行程序时，会有优先级的需求。比如，当计算机收到断电信号时，它应立即去保存数据，保存数据的程序具有较高的优先级(电容可以保存少许电量，供 CPU 运行很短的一小段时间)。
• 一般而言，由硬件产生的信号需要 CPU 立马做出回应，不然数据可能就丢失了，所以它的优先级很高。
• CPU 理应中断掉正在执行的程序，去做出响应;当 CPU 完成对硬件的响应后，再重新执行用户程序。

中断的过程如下图，它和函数调用差不多，只不过函数调用是事先定好位置，而中断的位置由“信号”决定。

中断程序调用

以键盘为例，当用户按下键盘某个按键时，键盘会给 CPU 的中断引脚发出一个高电平，CPU 能够捕获这个信号，然后执行键盘中断程序。

下图展示了各种硬件通过中断与 CPU 交互的过程：

现在可以回答“如何知道接收了数据?”这个问题了：当网卡把数据写入到内存后，网卡向 CPU 发出一个中断信号，操作系统便能得知有新数据到来，再通过网卡中断程序去处理数据。

3. 用户空间 / 内核空间

现在操作系统都是采用虚拟存储器，那么对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。

操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。

4. 进程阻塞

正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得了CPU资源），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

5. 进程切换

为了控制进程的执行，内核必须有能力挂起正在CPU上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。因此可以说，任何进程都是在操作系统内核的支持下运行的，是与内核紧密相关的，并且进程切换是非常耗费资源的。

至于进程切换为什么消耗资源可以看看这篇博客：进程切换和线程切换，协程

6.文件描述符

文件描述符（File descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。

文件描述符在形式上是一个非负整数。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。

7. 缓存I/O

缓存I/O又称为标准I/O，大多数文件系统的默认I/O操作都是缓存I/O。在Linux的缓存I/O机制中，操作系统会将I/O的数据缓存在文件系统的页缓存中，即数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。

8. CPU 的时间片轮转机制

单核 CPU 在某一时刻只能跑一个进程。但小时候用的单核 CPU 的电脑一样可以“同时”运行多个程序，为什么？这是因为操作系统提供了一种CPU时间片轮转机制。

时间片轮转调度是一种最古老、最简单、最公平且使用最广的算法。每个进程被分配一个时间段,称作它的时间片,即该进程允许运行的时间。

如果在时间片结束时进程还在运行，则CPU使用权将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。

由于切换的时间很短（大概为5毫秒），切片时间也很短（一般为100毫秒），以人的反应结果就是感觉多个程序同时运行，且没有停顿（切换的时间和在别的切片上的时间）。当然如果我们开多了程序，也会很直观的感觉卡，玩游戏的时候会把其它软件关掉，也有这个道理。

知道了 CPU 的时间片轮转机制，你就知道了程序阻塞了它的进程之后，CPU 会立马跑别的进程。

但是你想知道CPU 还会不会回来尝试跑这个进程，你需要知道工作队列和等待队列。这个后续会解释。

二. 进程阻塞和唤醒

2.1. 进程阻塞的过程

正在执行的进程，由于期待的某些事件未发生，如请求系统资源失败、等待某种操作的完成、新数据尚未到达或无新工作做等，则由系统自动执行阻塞原语(Block)，使自己由运行状态变为阻塞状态。可见，进程的阻塞是进程自身的一种主动行为，也因此只有处于运行态的进程（获得了CPU资源），才可能将其转为阻塞状态。当进程进入阻塞状态，是不占用CPU资源的。

从操作系统进程调度的角度来看数据接收。阻塞是进程调度的关键一环，指的是进程在等待某事件(如接收到网络数据)发生之前的等待状态，Recv、Select 和 Epoll 都是阻塞方法。

2.2 工作队列

• 操作系统为了支持多任务，实现了进程调度的功能，会把进程分为“运行”和“等待”等几种状态。
• 运行状态是进程获得 CPU 使用权，正在执行代码的状态;等待状态是阻塞状态，比如上述程序运行到 Recv 时，程序会从运行状态变为等待状态，接收到数据后又变回运行状态。
• 操作系统会分时执行各个运行状态的进程，由于速度很快，看上去就像是同时执行多个任务。

如下图所示，Linux 内核空间里会维持一个工作队列，因为时间片轮转机制，系统会在进程A、B、C等多个进程间切换着跑

假如现在进程 A 里跑的程序有一个对象执行了某个方法将当前进程阻塞了，内核会立刻将进程A从工作队列中移除，同时在该对象里创建等待队列，并新建一个引用指向进程A。如下图：

从图中可以看到，进程A被排在了工作队列之外，不受系统调度了，这就是我们常说的被操作系统“挂起”。
这也提现了阻塞和挂起的关系。阻塞是人为安排的，让你程序走到这里阻塞。而阻塞的实现方式是系统将进程挂起。

下面我们以socket为例讲解进程阻塞和唤醒

为简单起见，我们从普通的 Recv 接收开始分析，先看看下面代码：

//创建socket 
int s = socket(AF_INET, SOCK_STREAM, 0);    
//绑定 
bind(s, ...) 
//监听 
listen(s, ...) 
//接受客户端连接 
int c = accept(s, ...) 
//接收客户端数据 
recv(c, ...); 
//将数据打印出来 
printf(...) 

这是一段最基础的网络编程代码，先新建 Socket 对象，依次调用 Bind、Listen 与 Accept，最后调用 Recv 接收数据。

Recv 是个阻塞方法，当程序运行到 Recv 时，它会一直等待，直到接收到数据才往下执行。那么阻塞的原理是什么?

工作队列中有 A、B 和 C 三个进程

2.3 等待队列

当进程 A 执行到创建 Socket 的语句时，操作系统会创建一个由文件系统管理的 Socket 对象(如下图)。

创建 Socket

这个 Socket 对象包含了发送缓冲区、接收缓冲区与等待队列等成员。等待队列是个非常重要的结构，它指向所有需要等待该 Socket 事件的进程。

当程序执行到 Recv 时，操作系统会将进程 A 从工作队列移动到该 Socket 的等待队列中(如下图)。

Socket 的等待队列

由于工作队列只剩下了进程 B 和 C，依据进程调度，CPU 会轮流执行这两个进程的程序，不会执行进程 A 的程序。所以进程 A 被阻塞，不会往下执行代码，也不会占用 CPU 资源。

注：操作系统添加等待队列只是添加了对这个“等待中”进程的引用，以便在接收到数据时获取进程对象、将其唤醒，而非直接将进程管理纳入自己之下。上图为了方便说明，直接将进程挂到等待队列之下。

2.4 唤醒进程

当 Socket 接收到数据后，操作系统将该 Socket 等待队列上的进程重新放回到工作队列，该进程变成运行状态，继续执行代码。

同时由于 Socket 的接收缓冲区已经有了数据，Recv 可以返回接收到的数据。

2.5 内核接收网络数据全过程

这一步，贯穿网卡、中断与进程调度的知识，叙述阻塞 Recv 下，内核接收数据的全过程。

内核接收数据全过程

如上图所示，进程在 Recv 阻塞期间：

• 计算机收到了对端传送的数据(步骤 ①)
• 数据经由网卡传送到内存(步骤 ②)
• 然后网卡通过中断信号通知 CPU 有数据到达，CPU 执行中断程序(步骤 ③)

此处的中断程序主要有两项功能，先将网络数据写入到对应 Socket 的接收缓冲区里面(步骤 ④)，再唤醒进程 A(步骤 ⑤)，重新将进程 A 放入工作队列中。

唤醒进程的过程如下图所示：

2.6 进程阻塞为什么不消耗CPU？

答：进程执行的过程的确是在内核CPU中执行的，会消耗CPU。但是当进程阻塞变成等待态的时候，会被加入该socket的等待队列中，并不会出现在内核中了，而是在socket的等待队列中“等待”。当进程被操作系统唤醒后，又会被加入到工作队列中。

三. 提出问题

以上是内核接收数据全过程，这里我们可能会思考两个问题：

• 操作系统如何知道网络数据对应于哪个 Socket?
• 如何同时监视多个 Socket 的数据?

第一个问题：因为一个 Socket 对应着一个端口号，而网络数据包中包含了 IP 和端口的信息，内核可以通过端口号找到对应的 Socket。当然，为了提高处理速度，操作系统会维护端口号到 Socket 的索引结构，以快速读取。

第二个问题是多路复用的重中之重，也正是本文后半部分的重点。

四. 同时监视多个 Socket 的简单方法（select）

根据上图我们可以知道，socket阻塞是被文件系统的文件描述符（fd）管理的，所以其实select是通过监控fd列表来判断当前socket是否阻塞或者就绪的。

• 服务端需要管理多个客户端连接，而 Recv 只能监视单个 Socket，这种矛盾下，人们开始寻找监视多个 Socket 的方法。Epoll 的要义就是高效地监视多个 Socket。
• 从历史发展角度看，必然先出现一种不太高效的方法，人们再加以改进，正如 Select 之于 Epoll。先理解不太高效的 Select，才能够更好地理解 Epoll 的本质。
• 假如能够预先传入一个 Socket 列表，如果列表中的 Socket 都没有数据，挂起进程，直到有一个 Socket 收到数据，唤醒进程。这种方法很直接，也是 Select 的设计思想。
• 为方便理解，我们先复习 Select 的用法。在下边的代码中，先准备一个数组 FDS，让 FDS 存放着所有需要监视的 Socket。
• 然后调用 Select，如果 FDS 中的所有 Socket 都没有数据，Select 会阻塞，直到有一个 Socket 接收到数据，Select 返回，唤醒进程。
• 用户可以遍历 FDS，通过 FD_ISSET 判断具体哪个 Socket 收到数据，然后做出处理。

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

Select 的实现思路很直接，假如程序同时监视如下图的 Sock1、Sock2 和 Sock3 三个 Socket，那么在调用 Select 之后，操作系统把进程 A 分别加入这三个 Socket 的等待队列中。

操作系统把进程 A 分别加入这三个 Socket 的等待队列中。当任何一个 Socket 收到数据后，中断程序将唤起进程。下图展示了 Sock2 接收到了数据的处理流程：

Sock2 接收到了数据，中断程序唤起进程 A

注：Recv 和 Select 的中断回调可以设置成不同的内容。

所谓唤起进程，就是将进程从所有的等待队列中移除，加入到工作队列里面，如下图所示：

将进程 A 从所有等待队列中移除，再加入到工作队列里面

经由这些步骤，当进程 A 被唤醒后，它知道至少有一个 Socket 接收了数据。程序只需遍历一遍 Socket 列表，就可以得到就绪的 Socket。

这种简单方式行之有效，在几乎所有操作系统都有对应的实现。但是简单的方法往往有缺点，主要是：

• 每次调用 Select 都需要将进程加入到所有监视 Socket 的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历
• 每次都要将整个 FDS 列表传递给内核，有一定的开销。
• 正是因为遍历操作开销大，出于效率的考量，才会规定 Select 的最大监视数量，默认只能监视 1024 个 Socket。

进程被唤醒后，程序并不知道哪些 Socket 收到数据，还需要遍历一次。那么，有没有减少遍历的方法?有没有保存就绪 Socket 的方法?这两个问题便是 Epoll 技术要解决的。

补充说明：本节只解释了 Select 的一种情形。当程序调用 Select 时，内核会先遍历一遍 Socket，如果有一个以上的 Socket 接收缓冲区有数据，那么 Select 直接返回，不会阻塞。

这也是为什么 Select 的返回值有可能大于 1 的原因之一。如果没有 Socket 有数据，进程才会阻塞。

五. poll

poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态， 但是它没有最大连接数的限制，原因是它是基于链表来存储的.

六. epoll的设计思路

Epoll 是在 Select 出现 N 多年后才被发明的，是 Select 和 Poll(Poll 和 Select 基本一样，有少量改进)的增强版本。Epoll 通过以下一些措施来改进效率：

6.1 措施一：功能分离

Select 低效的原因之一是将“维护等待队列”和“阻塞进程”两个步骤合二为一。

相比 Select，Epoll 拆分了功能

如上图所示，每次调用 Select 都需要这两步操作，然而大多数应用场景中，需要监视的 Socket 相对固定，并不需要每次都修改。

Epoll 将这两个操作分开，先用 epoll_ctl 维护等待队列，再调用 epoll_wait 阻塞进程。显而易见地，效率就能得到提升。

为方便理解后续的内容，我们先了解一下 Epoll 的用法。如下的代码中，先用 epoll_create 创建一个 Epoll 对象 Epfd，再通过 epoll_ctl 将需要监视的 Socket 添加到 Epfd 中，最后调用 epoll_wait 等待数据：

int s = socket(AF_INET, SOCK_STREAM, 0);    
bind(s, ...) 
listen(s, ...) 
 
int epfd = epoll_create(...); 
epoll_ctl(epfd, ...); //将所有需要监听的socket添加到epfd中 
 
while(1){ 
    int n = epoll_wait(...) 
    for(接收到数据的socket){ 
        //处理 
    } 
} 

功能分离，使得 Epoll 有了优化的可能。

6.2 措施二：就绪列表

Select 低效的另一个原因在于程序不知道哪些 Socket 收到数据，只能一个个遍历。如果内核维护一个“就绪列表”，引用收到数据的 Socket，就能避免遍历。

就绪列表示意图

如上图所示，计算机共有三个 Socket，收到数据的 Sock2 和 Sock3 被就绪列表 Rdlist 所引用。

当进程被唤醒后，只要获取 Rdlist 的内容，就能够知道哪些 Socket 收到数据。

6.3 Epoll 的原理与工作流程

创建 Epoll 对象

如下图所示，当某个进程调用 epoll_create 方法时，内核会创建一个 eventpoll 对象(也就是程序中 Epfd 所代表的对象)。

内核创建 eventpoll 对象

eventpoll 对象也是文件系统中的一员，和 Socket 一样，它也会有等待队列。

创建一个代表该 Epoll 的 eventpoll 对象是必须的，因为内核要维护“就绪列表”等数据，“就绪列表”可以作为 eventpoll 的成员。

维护监视列表
创建 Epoll 对象后，可以用 epoll_ctl 添加或删除所要监听的 Socket。以添加 Socket 为例。

添加所要监听的 Socket

如上图，如果通过 epoll_ctl 添加 Sock1、Sock2 和 Sock3 的监视，内核会将 eventpoll 添加到这三个 Socket 的等待队列中。

当 Socket 收到数据后，中断程序会操作 eventpoll 对象，而不是直接操作进程。

接收数据

当 Socket 收到数据后，中断程序会给 eventpoll 的“就绪列表”添加 Socket 引用。

给就绪列表添加引用

如上图展示的是 Sock2 和 Sock3 收到数据后，中断程序让 Rdlist 引用这两个 Socket。

eventpoll 对象相当于 Socket 和进程之间的中介，Socket 的数据接收并不直接影响进程，而是通过改变 eventpoll 的就绪列表来改变进程状态。

当程序执行到 epoll_wait 时，如果 Rdlist 已经引用了 Socket，那么 epoll_wait 直接返回，如果 Rdlist 为空，阻塞进程。

阻塞和唤醒进程

假设计算机中正在运行进程 A 和进程 B，在某时刻进程 A 运行到了 epoll_wait 语句。

epoll_wait 阻塞进程

如上图所示，内核会将进程 A 放入 eventpoll 的等待队列中，阻塞进程。

当 Socket 接收到数据，中断程序一方面修改 Rdlist，另一方面唤醒 eventpoll 等待队列中的进程，进程 A 再次进入运行状态(如下图）

也因为 Rdlist 的存在，进程 A 可以知道哪些 Socket 发生了变化。

6.4 epoll数据结构设计（等待队列和就绪队列）

至此，相信读者对 Epoll 的本质已经有一定的了解。但我们还需要知道 eventpoll 的数据结构是什么样子?

此外，就绪队列应该使用什么数据结构?eventpoll 应使用什么数据结构来管理通过 epoll_ctl 添加或删除的 Socket?

6.4.1 就绪队列

就绪列表引用着就绪的 Socket，所以它应能够快速的插入数据。程序可能随时调用 epoll_ctl 添加监视 Socket，也可能随时删除。

当删除时，若该 Socket 已经存放在就绪列表中，它也应该被移除。所以就绪列表应是一种能够快速插入和删除的数据结构。

双向链表就是这样一种数据结构，Epoll 使用双向链表来实现就绪队列(对应上图的 Rdlist)。

6.4.2 等待队列

既然 Epoll 将“维护监视队列”和“进程阻塞”分离，也意味着需要有个数据结构来保存监视的 Socket，至少要方便地添加和移除，还要便于搜索，以避免重复添加。

红黑树是一种自平衡二叉查找树，搜索、插入和删除时间复杂度都是 O(log(N))，效率较好，Epoll 使用了红黑树作为索引结构(对应上图的 RBR)。

注：因为操作系统要兼顾多种功能，以及有更多需要保存的数据，Rdlist 并非直接引用 Socket，而是通过 Epitem 间接引用，红黑树的节点也是 Epitem 对象。

同样，文件系统也并非直接引用着 Socket。为方便理解，本文中省略了一些间接结构。

7. 总结

select：

• select说的通俗一点就是各个客户端连接的文件描述符也就是套接字，都被放到了一个集合（fd_set）中，调用select函数之后会一直监视这些文件描述符中有哪些可读，如果有可读的描述符那么我们的工作进程就去读取资源。
• 所以每次都需要将fd_set（一个long数组）加载至内核中进行遍历，找到就绪的socket

poll:

• poll 和 select 的实现非常类似，本质上的区别就是存放 fd 集合的数据结构不一样。select 在一个进程内可以维持最多 1024 个连接，poll 在此基础上做了加强，可以维持任意数量的连接。
• 但 select 和 poll 方式有一个很大的问题就是，我们不难看出来 select 是通过轮训的方式来查找是否可读或者可写，打个比方，如果同时有100万个连接都没有断开，而只有一个客户端发送了数据，所以这里它还是需要循环这么多次，造成资源浪费。

epoll:

• epoll是基于内核的反射机制，在有活跃的 socket 时，系统会调用我们提前设置的回调函数。
• 简单来说epoll维护了两个队列：等待队列和就绪队列
• 等待队列使用红黑树结构，存储正在等待的进程
• 就绪队列使用双向链表结构，存储数据已经就绪的socket，每次直接从队头就可以知道哪个socket已经就绪了
• 进程阻塞时，内核会将进程放入 eventpoll 的等待队列中，阻塞进程。
• 当 Socket 接收到数据，中断程序一方面修改 Rdlist，另一方面唤醒 eventpoll 等待队列中的进程。