网络io与select，poll，epoll_网络阻塞模型select poll-CSDN博客

本文链接：https://blog.csdn.net/m0_37845735/article/details/124874388

前言

网络 IO，会涉及到两个系统对象，一个是用户空间调用 IO 的进程或者线程，另一个是内核空间的内核系统，比如发生 IO 操作 read 时，它会经历两个阶段：

1. 等待数据准备就绪

2. 将数据从内核拷贝到进程或者线程中

因为在以上两个阶段上各有不同的情况，所以出现了多种网络 IO 模型

一、五种 IO 网络模型

1.1、阻塞 IO（blocking IO）

所谓阻塞型接口是指系统调用（一般是 IO 接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。一个典型的读操作流程如下：

除非特别指定，几乎所有的 IO 接口 ( 包括 socket 接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

1.2、非阻塞 IO（non-blocking IO）

Linux 下，可以通过设置 socket 使其变为 non-blocking。当对一个 non-blocking socket 执行读操作时，流程是这个样子：

循环调用 read()将大幅度推高 CPU 占用率；此外，在这个方案中 read()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如 select()多路复用模式，可以一次检测多个连接是否活跃。

1.3、多路复用 IO（IO multiplexing）

IO multiplexing 这个词可能有点陌生，但是提到 select/epoll，大概就都能明白了。有些地方也称这种 IO 方式为事件驱动 IO(event driven IO)。我们都知道，select/epoll 的好处就在于单个 process 就可以同时处理多个网络连接的 IO。它的基本原理就是 select/epoll 这个 function会不断的轮询所负责的所有 socket，当某个 socket 有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了 select，那么整个进程会被 block，而同时，kernel 会“监视”所有 select 负责的 socket，当任何一个 socket 中的数据准备好了，select 就会返回。这个时候用户进程再调用 read 操作，将数据从 kernel 拷贝到用户进程。

使用 select 以后最大的优势是用户可以在一个线程内同时处理多个 socket 的 IO 请求。用户可以注册多个 socket，然后不断地调用 select 读取被激活的 socket，即可达到在同一个线程内同时处理多个 IO 请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的

这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。

大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。

下面给出 select 接口的原型：

FD_ZERO(int fd, fd_set* fds)
FD_SET(int fd, fd_set* fds)
FD_ISSET(int fd, fd_set* fds)
FD_CLR(int fd, fd_set* fds)
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,struct timeval *timeout)

在 select()函数中，readfds、writefds 和exceptfds 同时作为输入参数和输出参数

但这个模型依旧有着很多问题。首先 select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll

其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性

幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有libevent 库，还有作为 libevent 替代者的 libev 库

select存在一个bug：当某个socket接收缓冲区有新数据到达，然后select报告这个socket描述符可读，但随后，协议栈检查到这个新分节检验和错误时，会丢弃这个分节，这时再调用read则无数据可读，如果socket没有被设置成nonblocking，此read将阻塞当前线程。需要将socket设置成nonblocking

在select中关闭socket时需要注意：关闭socket需要及时更新监测socket集合。当一个socket被关闭之后，我们需要将其对应的文件描述符从select的监测集合中删除。否则，会导致select函数在下一次调用时伪唤醒，也就是说，调用后立即返回，并且一直返回“有事件发生”，而实际上这个已关闭的文件描述符并没有事件可处理。