【Linux 网络】高级 IO -- 详解

void FD_CLR(int fd, fd_set *set);  // 用来清除描述词组set中相关fd的位
int FD_ISSET(int fd, fd_set *set); // 用来测试描述词组set中相关fd的位是否为真
void FD_SET(int fd, fd_set *set);  // 用来设置描述词组set中相关fd的位
void FD_ZERO(fd_set *set);         // 用来清除描述词组set的全部位

---

（5）select 基本工作流程

若要实现一个简单的 select 服务器，该服务器要做的就是读取客户端发来的数据并进行打印，那么该 select 服务器的工作流程如下：

1. 先初始化服务器，完成套接字的创建、绑定和监听。
2. 定义一个 _fd_array 数组用于保存监听套接字和已经与客户端建立连接的套接字，初始化时就可将监听套接字添加到 _fd_array 数组中。
3. 然后服务器开始循环调用 select 函数，检测读事件是否就绪，若就绪则执行对应操作。
4. 每次调用 select 函数之前，都需要定义一个读文件描述符集 readfds，并将 _fd_array 中的文件描述符依次设置进 readfds 中，表示让 select 监视这些文件描述符的读事件是否就绪。
5. 当 select 检测到数据就绪时会将读事件就绪的文件描述符设置进 readfds 中，此时就能够得知哪些文件描述符的读事件就绪，并对这些文件描述符进行对应操作。
6. 若读事件就绪的是监听套接字，则调用 accept 函数从底层全连接队列获取已建立的连接，并将该连接对应的套接字添加到 _fd_array 数组中。
7. 若读事件就绪的是与客户端建立连接的套接字，则调用 read 函数读取客户端发来的数据并进行打印输出。
8. 服务器与客户端建立连接的套接字读事件就绪，也可能是客户端将连接关闭了，此时服务器应该调用 close 关闭该套接字，并将该套接字从 _fd_array 数组中清除，不需要再监视该文件描述符的读事件了。

注意：

• 传入 select 函数的 readfds、writefds 和 exceptfds 都是输入输出型参数。当 select 函数返回时这些参数中的值已经被修改了，因此每次调用 select 函数时都需对其进行重新设置，timeout 也是如此。
• 因为每次调用 select 函数之前都需要对 readfds 进行重新设置，所以需要定义一个 _fd_array 数组保存与客户端已经建立的若干连接和监听套接字，实际 _fd_array 数组中的文件描述符就是需要让 select 监视读事件的文件描述符。
• select 服务器只是读取客户端发来的数据，因此只需要让 select 监视特定文件描述符的读事件，若要同时让 select 监视特定文件描述符的读事件和写事件，则需要分别定义 readfds 和 writefds，并定义两个数组分别保存需要被监视读事件和写事件的文件描述符，便于每次调用 select 函数前对 readfds 和 writefds 进行重新设置。
• 由于调用 select 时还需要传入被监视的文件描述符中最大文件描述符值 +1，因此每次在遍历 _fd_array 对 readfds 进行重新设置时，还需要记录最大文件描述符值。

---

（6）select 服务器

A. Sock.hpp

编写一个 Socket 类，对套接字相关的接口进行一定封装，为了让外部能直接调用 Socket 类中封装的函数，于是将部分函数定义成静态成员函数。

---

B. selectServer.hpp

• 当调用 accept 函数从底层获取上来连接后，不能立即调用 read 函数读取该连接中的数据。因为此时新连接中的数据可能并没有就绪，如果直接调用 read 函数可能发生阻塞，应该将这个等待过程交给 select 函数来完成，因此在获取完连接后直接将该连接对应的文件描述符添加到 _fd_array 数组中即可，当该连接的读事件就绪时再进行数据读取。
• 添加文件描述符到 fd_array 数组中，本质就是遍历 fd_array 数组，找到一个没有被使用的位置将该文件描述符添加进去。但有可能 _fd_array 数组中全部的位置都已被占用，那么文件描述符就会添加失败，此时就只能将刚获取上来的连接对应的套接字进行关闭，因为此时服务器已经没有能力处理这个连接了。

---

C. select 服务器测试

使用 telnet 工具连接服务器，此时通过 telnet 向服务器发送的数据就能够被服务器读到并且打印输出了。

虽然 selectServer 仅是一个单进程、单线程服务器，但却可以同时为多个客户端提供服务。因为 select 函数调用后，会告知 select 服务器是哪个客户端对应的连接事件就绪，此时 select 服务器就可以读取对应客户端发来的数据，读取完后又会调用 select 函数等待某个客户端连接的读事件就绪。

当服务器检测到客户端退出后，也会关闭对应的连接，并将对应的套接字从 _fd_array 数组中清除。

---

D. 存在的问题

1. select 服务器如果要向客户端发送数据的话，不能直接调用 write 函数。因为调用 write 函数时，实际上也分为 “等” 和 “拷贝” 两步，也应该将 “等” 的这个过程交给 select 函数，因此在每次调用 select 函数之前，除了需要重新设置 readfds，也要重新设置 writefds，并且还需要一个数组来保存需被监视写事件是否就绪的文件描述符，当某一文件描述符的写事件就绪时，才能够调用 write 函数向客户端发送数据。
2. 没有定制协议。代码中读取数据时并没有按照某种规则进行读取，可能造成粘包问题，根本原因就是没有定制协议。比如，HTTP 协议规定在读取底层数据时读取到空行就表明读完了一个 HTTP 报头，此时再根据 HTTP 报头中的 Content-Length 属性得知正文的长度，最终就能够读取到一个完整的 HTTP 报文，HTTP 协议通过这种方式避免了粘包问题。
3. 没有对应的输入输出缓冲区。代码中直接将读取的数据存储到了字符数组 buffer 中，这是不严谨的，因为本次数据读取可能并没有读取到一个完整的报文，此时服务器就不能进行数据的分析处理，应该将读取到的数据存储到一个输入缓冲区中，当读取到一个完整的报文后再让服务器进行处理。此外，如果服务器要能够对客户端进行响应，那么服务器的响应数据也不应该直接调用 write 函数发送给客户端，而是应该先存储到一个输出缓冲区中，因为响应数据可能很庞大，无法一次发送完毕，所以可能需要进行分批发送。

---

（7）select 的优点

• 可以同时等待多个文件描述符，且只负责等待（有大量的连接，但只有少量是活跃的，节省资源），实际的 IO 操作由 accept、read、write 等接口完成，保证接口在进行 IO 操作时不会被阻塞。
• select 同时等待多个文件描述符，因此可以将 “等” 的时间重叠，提高 IO 效率。

注意：上述优点也是所有多路转接接口的优点。

---

（8）select 的缺点

• 每次调用 select，都需手动设置 fd 集合，从接口使用角度来说也非常不便。
• 每次调用 select，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大。
• 同时每次调用 select 都需要在内核遍历传递进来的所有 fd，这个开销在 fd 很多时也很大。
• select 可监控的文件描述符数量太少。

• ---

  为了维护第三方数组，select 服务器会充满大量的遍历操作。OS 底层帮我们关心 fd 的时候，也要进行遍历。
• 每一次都要对 select 输出参数进行重新设定。
• select 能够同时管理的 fd 的个数是有上限的。
• 因为几乎每一个参数都是输入输出型的，也就决定了 select 一定会频繁的进行用户到内核、内核到用户的参数数据拷贝。
• 编码比较复杂。

---

A. select 可监控的文件描述符个数

调用 select 函数时传入的 readfds、writefds 以及 exceptfds 都是 fd_set结构，fd_set 结构本质是一个位图，用一个 bit 位来标记一个文件描述符，因此 select 可监控的文件描述符个数取决于 fd_set 类型的 bit 位个数。

运行代码后可以发现，select可监控的文件描述符个数为 1024。

---

B. 一个进程能打开的文件描述符个数

进程控制块 task_struct 中有一个 files 指针，该指针指向一个 struct files_struct 结构，进程的文件描述符表 fd_array 就存储在该结构中，其中文件描述符表 fd_array 的大小定义为 NR_OPEN_DEFAULT，NR_OPEN_DEFAULT 的值实际就是 32。

但不意味着一个进程最多只能打开 32 个文件描述符，进程能打开的文件描述符个数是可以扩展的，通过 ulimit -a 命令可以看到进程能打开的文件描述符上限。

select 可监控的文件描述符个数是 1024，除去监听套接字，那么最多只能连接 1023 个客户端。

---

（9）select 的适用场景

多路转接接口 select、poll 和 epoll，需在一定的场景下使用，如果场景不适宜，可能会适得其反。

多路转接接口一般适用于多连接，且多连接中只有少部分连接比较活跃。因为少量连接比较活跃，也意味着几乎所有的连接在进行 IO 操作时，都需要花费大量时间来等待事件就绪，此时使用多路转接接口就可以将这些等的事件进行重叠，提高 IO 效率。

对于多连接中大部分连接都很活跃的场景，其实并不适合使用多路转接。因为每个连接都很活跃，也意味着任何时刻每个连接上的事件基本都是就绪的，此时根本不需要动用多路转接接口来进行等待，毕竟使用多路转接接口也是需要花费系统的时间和空间资源的。

多连接中只有少量连接是比较活跃的，如聊天工具，登录 QQ 后大部分时间其实是没有聊天的，此时服务器端不可能调用一个 read 函数阻塞等待读事件就绪。

多连接中大部分连接都很活跃，如企业当中进行数据备份时，两台服务器之间不断在交互数据，这时连接是特别活跃的，几乎不需要等的过程，也就没必要使用多路转接接口了。

---

2、poll

（1）poll 函数接口

---

A. 参数说明

• fds：一个 poll 函数监视的结构列表，每一个元素都包含三部分内容：文件描述符、监视的事件集合、就绪的事件集合。
• nfds：表示 fds 数组的长度。
• timeout：表示 poll 函数的超时时间，单位是毫秒（ms）。

---

B. 参数 timeout 的取值

• -1：poll 调用后进行阻塞等待，直到被监视的某个文件描述符上的某个事件就绪。
• 0：poll 调用后进行非阻塞等待，无论被监视的文件描述符上的事件是否就绪，poll 检测后都会立即返回。
• 特定的时间值：poll 调用后在指定的时间内进行阻塞等待，若被监视的文件描述符上没有事件就绪，则在该时间后 poll 进行超时返回。

---

C. 返回值说明

• 若函数调用成功，则返回有事件就绪的文件描述符个数。
• 若 timeout 时间耗尽，表示超时，则返回 0，表示 poll 以非阻塞方式等待。
• 若函数调用失败，则返回 -1，poll 要以阻塞方式等待，同时错误码被设置。

---

D. 错误码

poll 调用失败时，错误码可能被设置为：

• EFAULT：fds 数组不包含在调用程序的地址空间中
• EINTR：此调用被信号所中断
• EINVAL：nfds 值超过 RLIMIT_NOFILE值
• ENOMEM：核心内存不足

---

（2）struct pollfd 结构

---

A. 参数说明

• fd：特定的文件描述符，若设置为负值则忽略 events 字段并且 revents 字段返回 0。
• events：需要监视该文件描述符上的哪些事件。
• revents：poll 函数返回时告知用户该文件描述符上的哪些事件已经就绪。

---

B. events 和 revents 的取值

这些值都以宏的方式定义，二进制序列中有且只有一个 bit 位是 1，且为 1 的 bit 位各不相同。

• 在调用 poll 函数之前，可以通过或运算符将要监视的事件添加到events成员中
• 在 poll 函数返回后，可以通过与运算符检测revents成员中是否包含特定事件，以得知对应文件描述符的特定事件是否就绪

---

C. 返回结果

• 返回值小于 0，表示出错。
• 返回值等于 0，表示 poll 函数等待超时。
• 返回值大于 0，表示 poll 由于监听的文件描述符就绪而返回。

---

（3）poll 服务器

poll 的工作流程和 select 基本类似，下面也实现一个简单 poll 服务器，只读取客户端发来的数据并进行打印。

---

A. pollServer.hpp

_fds 数组的大小是固定设置的，因此在将新获取连接对应的文件描述符添加到 fds 数组时，可能会因为 fds 数组已满而添加失败，这时 poll 服务器只能将刚刚获取上来的连接对应的套接字进行关闭。

---

B. poll 服务器测试

在调用 poll 函数时，将 timeout 的值设置成 1000，因此运行服务器后每隔 1000 毫秒没有客户端发来连接请求，那么服务器就会超时返回。

用 telnet 工具连接 poll 服务器后，poll 函数在检测到监听套接字的读事件就绪后就会调用 accept 获取建立好的连接，并打印输出客户端的 IP 和端口号等信息，此时客户端发来的数据也能成功被 poll 服务器收到并进行打印输出。

poll 服务器也是单进程、单线程服务器，同样可以为多个客户端服务。

当服务器端检测到客户端退出后，也会关闭对应的连接，并将对应的套接字从 _fds 数组中清除。

---

（4）poll 的优点

• struct pollfd 结构中包含了 events 和 revents，相当于将 select 的输入输出型参数进行分离，因此在每次调用 poll 之前，不需像 select 一样重新对参数进行设置，接口使用比 select 方便。
• poll 可监控的文件描述符数量没有限制（但是数量过大后性能也是会下降）。
• poll 也可以同时等待多个文件描述符，提高 IO 效率。
• 有大量的连接，但只有少量是活跃的，节省资源。

---

（5）poll 的缺点

poll 中监听的文件描述符数目增多时：

• 和 select 函数一样，当 poll 返回后，需要遍历 _fds 数组来获取就绪的文件描述符（轮询pollfd来获取就绪的描述符）。
• 每次调用 poll 都需将大量 struct pollfd 结构从用户态拷贝到内核态，这个开销会随着 poll 监视的文件描述符数目增多而增大。
• 同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。
• 同时每次调用 poll 都需要在内核遍历传递进来的所有 fd，这个开销在 fd 很多时也很大。
• poll 的代码也比较复杂，但比 select 容易一些。

---

3、epoll

（1）初识 epoll

按照 man 手册的说法：是为处理大批量句柄而作了改进的 poll。

epoll 是系统提供的一个多路转接接口。

• epoll 系统调用也可以让程序同时监视多个文件描述符上的事件是否就绪，与 select 和 poll 的定位是一样的，适用场景也相同。
• epoll 在命名上比 poll 多了一个 e，可以理解成是 extend，epoll 就是为了同时处理大量文件描述符而改进的 poll。
• epoll 在 2.5.44 内核中被引进，几乎具备了 select 和 poll 所有优点，它被公认为 Linux2.6 下性能最好的多路 I/O 就绪通知方法。

---

（2）epoll 的相关系统调用

epoll 有 3 个相关的系统调用。

---

A. epoll_create 函数

• 参数 size：自 Linux2.6.8 后，size 参数是被忽略的，但 size 的值必须设置为大于 0 的值。
• 返回值：epoll 模型创建成功返回其对应的文件描述符，否则返回 -1，同时错误码被设置。用完之后，必须调用 close() 关闭。

注意： 当不再使用时，须调用 close 函数关闭 epoll 模型对应的文件描述符，当所有引用 epoll 实例的文件描述符都已关闭时，内核将销毁该实例并释放相关资源。

---

B. epoll_ctl 函数

它不同于 select() 是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

参数说明：

• epfd：epoll_create 函数的返回值（epoll 的句柄）
• op：表示具体的动作，用三个宏来表示
• fd：需要监视的文件描述符 fd
• event：需要监视该文件描述符上的哪些事件

第二个参数 op 的取值有以下三种：

• EPOLL_CTL_ADD：注册新的文件描述符 fd 到指定的 epoll 模型 epfd 中。
• EPOLL_CTL_MOD：修改已经注册的文件描述符的监听事件。
• EPOLL_CTL_DEL：从 epoll 模型 epfd 中删除指定的文件描述符 fd。

返回值：函数调用成功返回 0，调用失败返回 -1，同时错误码会被设置

第四个参数对应的 struct epoll_event 结构如下：

struct epoll_event 结构中有两个成员，第一个成员 events 表示的是需监视的事件，第二个成员 data 为联合体结构，一般选择使用该结构中的 fd，表示需要监听的文件描述符。

events 可以是以下几个宏的集合（常用取值）如下：

• EPOLLIN：表示对应的文件描述符可以读（包括对端 SOCKET 正常关闭）。
• EPOLLOUT：表示对应的文件描述符可以写。
• EPOLLPRI：表示对应的文件描述符有紧急的数据可读（表示应该有带外数据到来）。
• EPOLLERR：表示对应的文件描述符发送错误。
• EPOLLHUP：表示对应的文件描述符被挂断，即对端将文件描述符关闭了。
• EPOLLET：将 epoll 的工作方式设置为边缘触发（Edge Triggered）模式，这是相对于水平触发（Level Triggered）来说的。
• EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需继续监听该文件描述符 socket 的话，需重新将该文件描述符添加到 EPOLL 队列里。

这些取值是以宏的方式定义，二进制序列中有且只有一个 bit 位是 1，且为 1 的 bit 位是各不相同的。

---

C. epoll_wait 函数

参数说明：

• epfd：epoll_create 函数的返回值（epoll 句柄），用于指定 epoll 模型。
• events：内核会将已就绪的事件拷贝到 events 数组中（不能是空指针，内核只负责将就绪事件拷贝到该数组，不会在用户态中分配内存）。
• maxevents：events 数组中的元素个数，该值不能大于创建 epoll 模型时传入的 size 值。
• timeout：表示 epoll_wait 函数的超时时间，单位是毫秒（ms），0 会立即返回，-1 是永久阻塞。

参数 timeout 的取值：

• -1：epoll_wait 调用后进行阻塞等待，直到被监视的某个文件描述符上的某个事件就绪。
• 0：epoll_wait 调用后进行非阻塞等待，无论被监视的文件描述符上的事件是否就绪，epoll_wait 检测后都会立即返回。
• 特定的时间值：epoll_wait 调用后在特定的时间内阻塞等待，若被监视的文件描述符上没有事件就绪，则在该时间后 epoll_wait 超时返回。

返回值：

• 若函数调用成功，则返回有事件就绪的文件描述符个数。
• 若 timeout 时间耗尽，则返回 0。
• 若函数调用失败，则返回 -1，同时错误码会被设置。

epoll_wait 调用失败时，错误码可能被设置为：

• EBADF：传入的 epoll 模型对应的文件描述符无效。
• EFAULT：events 指向的数组空间无法通过写入权限访问。
• EINTR：此调用被信号所中断。
• EINVAL：epfd 不是一个 epoll 模型对应的文件描述符，或传入的 maxevents 值小于等于 0。

---

（3）epoll 工作原理

A. 红黑树 && 就绪队列

当某一进程调用 epoll_create 函数，Linux 内核会创建一个 eventpoll 结构体，即 epoll 模型，eventpoll 结构体中的成员 rbr、rdlist 与 epoll 的使用方式密切相关。

struct eventpoll{
	...
	//红黑树的根节点，这棵树中存储着所有添加到epoll中的需要监视的事件
	struct rb_root rbr;
	//就绪队列中则存放着将要通过epoll_wait返回给用户的满足条件的事件
	struct list_head rdlist;
	...
}

• epoll 模型中的红黑树本质就是告诉内核，需要监视哪些文件描述符上的哪些事件，调用 epll_ctl 函数就是在对这颗红黑树进行增删改操作。
• epoll 模型中的就绪队列本质就是告诉内核，哪些文件描述符上的哪些事件已就绪，调用 epoll_wait 函数就是从就绪队列中获取已就绪的事件。

在 epoll 中，对于每一个事件都有一个对应的 epitem 结构体，红黑树和就绪队列中的节点分别是基于 epitem 结构中的 rbn 成员和 rdllink 成员的，epitem 结构中的成员 ffd 记录的是指定的文件描述符值，event 成员记录的就是该文件描述符对应的事件。

struct epitem{
	struct rb_node rbn;       //红黑树节点
	struct list_head rdllink; //双向链表节点
	struct epoll_filefd ffd;  //事件句柄信息
	struct eventpoll *ep;     //指向其所属的eventpoll对象
	struct epoll_event event; //期待发生的事件类型
}

• 对于 epitem 结构中 rbn 成员而言，ffd 与 event 的含义是：需要监视 ffd 上的 event 事件是否就绪。
• 对于 epitem 结构中的 rdlink 成员而言，ffd 与 event 的含义是：ffd 上的 event 事件已就绪。

注意：红黑树是一种二叉搜索树，必须有键值 key，文件描述符就可以天然的作为红黑树 key 值调用 epoll_ctl 向红黑树中新增节点时，若设置了 EPOLLONESHOT 选项，监听完这次事件后，若还需继续监听该文件描述符则需重新将其添加到 epoll 模型中，本质就是当设置了 EPOLLONESHOT 选项的事件就绪时，操作系统会自动将其从红黑树中删除。
若调用 epoll_ctl 向红黑树中新增节点时没设置 EPOLLONESHOT，那么该节点插入红黑树后就会一直存在，除非用户调用 epoll_ctl 将该节点从红黑树中删除。

---

B. 回调机制

所有添加到红黑树中的事件，都与设备（网卡）驱动程序建立回调方法，该回调方法在内核中被称为 ep_poll_callback。

• 对于 select 和 poll 而言，操作系统在监视多个文件描述符上的事件是否就绪时，需让操作系统主动对这多个文件描述符进行轮询检测，这会增加操作系统的负担。
• 对于 epoll 而言，操作系统不需主动进行事件的检测，当红黑树中监视的事件就绪时，会自动调用对应回调方法，将就绪的事件添加到就绪队列中。
• 当用户调用 epoll_wait 函数获取就绪事件时，只需关注底层就绪队列是否为空，若不为空则将就绪队列中的就绪事件拷贝给用户。
• 采用回调机制最大的好处：不再需要操作系统主动对就绪事件进行检测，当事件就绪时会自动调用对应的回调函数进行处理。

注意：只有添加到红黑树中的事件才会与底层建立回调方法，因此只有红黑树中对应的事件就绪时，才会执行对应的回调方法将其添加到就绪队列。
当不断有监视的事件就绪时，会不断调用回调方法向就绪队列中插入节点，而上层也会不断调用 epoll_wait 函数从就绪队列中获取节点，即典型的生产者消费者模型。
由于就绪队列可能被多个执行流同时访问，因此必须要使用互斥锁进行保护，eventpoll 结构中的 lock和 mtx 就是用于保护临界资源的，因此epoll本身是线程安全的 eventpoll 结构中的 wq（wait queue）即等待队列，当多个执行流想同时访问同一个 epoll 模型时，就需在该等待队列下进行等待。