I/O复用：Select /Poll/Epoll
1.select 详解
1.函数原型
通过调用这个函数可以委托内核帮助我们检测若干个文件描述符的状态，其实就是检测这些文件描述符对应的读写缓冲区的状态：
读缓冲区：检测里边有没有数据，如果有数据该缓冲区对应的文件描述符就绪
写缓冲区：检测写缓冲区是否可以写 (有没有容量)，如果有容量可以写，缓冲区对应的文件描述符就绪
读写异常：检测读写缓冲区是否有异常，如果有该缓冲区对应的文件描述符就绪。
#include - 1.nfds：委托内核检测的这三个集合中最大的文件描述符 + 1，内核需要线性遍历这些集合中的文件描述符，这个值是循环结束的条件。
在 Window 中这个参数是无效的，指定为 - 1 即可 - 2.readfds：文件描述符的集合，内核只检测这个集合中文件描述符对应的读缓冲区，传入传出参数，读集合一般情况下都是需要检测的，这样才知道通过哪个文件描述符接收了数据。
- 3.writefds：文件描述符的集合，内核只检测这个集合中文件描述符对应的写缓冲区，传入传出参数，如果不需要使用这个参数可以指定为 NULL。
- 4.exceptfds：文件描述符的集合，内核检测集合中文件描述符是否有异常状态，传入传出参数，如果不需要使用这个参数可以指定为 NULL。
- 5.timeout：超时时长，用来强制解除 select () 函数的阻塞的。
可以设置为：NULL：函数检测不到就绪的文件描述符会一直阻塞。
等待固定时长（秒）：函数检测不到就绪的文件描述符，在指定时长之后强制解除阻塞，函数返回 0
不等待：函数不会阻塞，直接将该参数对应的结构体初始化为 0 即可。 - 6.函数返回值：
大于 0：成功，返回集合中已就绪的文件描述符的总个数
等于 - 1：函数调用失败
等于 0：超时，没有检测到就绪的文件描述符。
一些操作函数：
// 将文件描述符fd从set集合中删除 == 将fd对应的标志位设置为0
void FD_CLR(int fd, fd_set *set);
// 判断文件描述符fd是否在set集合中 == 读一下fd对应的标志位到底是0还是1
int FD_ISSET(int fd, fd_set *set);
// 将文件描述符fd添加到set集合中 == 将fd对应的标志位设置为1
void FD_SET(int fd, fd_set *set);
// 将set集合中, 所有文件文件描述符对应的标志位设置为0, 集合中没有添加任何文件描述符
void FD_ZERO(fd_set *set);
2.select内部原理：
在 select() 函数中第 2、3、4 个参数都是 fd_set 类型，它表示一个文件描述符的集合，都是原值的拷贝（保护原值不被修改），类似于信号集 sigset_t，这个类型的数据有 128 个字节，也就是 1024 个标志位，和内核中文件描述符表中的文件描述符个数是一样的。
sizeof(fd_set) = 128 字节 * 8 = 1024 bit // int [32]
这并不是巧合，而是故意为之。这块内存中的每一个 bit 和 文件描述符表中的每一个文件描述符是一一对应的关系，这样就可以使用最小的存储空间将要表达的意思描述出来了。
下图中的 fd_set 中存储了要委托内核检测读缓冲区的文件描述符集合。
如果集合中的标志位为 0 代表不检测这个文件描述符状态。
如果集合中的标志位为 1 代表检测这个文件描述符状态。
内核在遍历这个读集合的过程中，如果被检测的文件描述符对应的读缓冲区中没有数据，内核将修改这个文件描述符在读集合 fd_set 中对应的标志位，改为 0，如果有数据那么这个标志位的值不变，还是 1。
注：在select中的三个fd_set类型的参数都是原值的拷贝，原值中记录着哪些文件描述符是连着的，哪些文件描述符是没有连接的。
以读数据为例：
在select中，内核扫描文件描述符对应的读缓冲区，对于标志位为0的文件描述符跳过，对于标志位为1的文件描述符，扫描器读缓冲区，如果读缓冲区为空，则将标志位改为0，否则不改变其标志位。一轮扫描过后，所有读缓冲区中有数据的文件描述符的标志位都被置位1了，服务端读取标志位为1的文件描述符对应的缓冲区即可。
3.slelect的处理流程：
1.创建监听的套接字lfd = socket()
2.将lfd与本地的ip和端口绑定bind()
3.将lfd监听listen()
4.创建文件描述集合fd_set,用于存储需要检测读事件的所有文件描述符
- 先FD_ZERO()进行初始化
- 再FD_SET()将监听的文件描述符放入检测的集合中
5.循环调用select(),周期性委托内核对所有文件描述符进行检测，检测的操作即上面提到的select原理
6.select()遍历执行完一次就返回执行状态，文件描述符被修改，处于就绪态的文件描述符的标志位都被置1。
7.通过FD_ISSET()判断集合中的文件描述符是否为1： - 不为1则跳过
- 为1则判断该文件描述符是监听的文件描述符还是已建立通信的文件描述符：
如果是监听的文件描述符，则调用accept()函数建立和该文件描述符通信的客户端的连接，同时将新得到的文件描述符通过FD_SET()放入检测集合中。
如果是已建立通信的文件描述符，则调用通信函数与客户端通信。
如果客户端和服务端断开了连接，调用FD_CLR()将这个文件描述符从检测集合中删除。
4.服务端代码
#include rdset 用于保存要检测的原始数据，这个变量不能作为参数传递给 select 函数，如同上面黄色字体讲的一样，因为在函数内部这个变量中的值会被内核修改，函数调用完毕返回之后，里边就不是原始数据了，大部分情况下是值为 1 的标志位变少了，不可能每一轮检测，所有的文件描述符都是就行的状态。因此需要通过 rdtemp 变量将原始数据传递给内核，select () 调用完毕之后再将内核数据传出，这两个变量的功能是不一样的。
5.客户端代码
#include 6.select的优缺点
缺点：
1.待检测集合（第 2、3、4 个参数）需要频繁的在用户区和内核区之间进行数据的拷贝，效率低。这是需要检测文件描述符对应的读缓冲区，用户态是没有这个权限的，因此要陷入到内核态。
2.内核对于 select 传递进来的待检测集合的检测方式是线性的
- 如果集合内待检测的文件描述符很多，检测效率会比较低。
- 如果集合内待检测的文件描述符相对较少，检测效率会比较高。
3.使用select能够检测的最大文件描述符个数有上限，默认是1024，这是在内核中被写死了的。
7.相关库函数
1.socket()
2.bind()
3.listen()
4.accept()
5.connect()
6.inet_pton()
将“点分十进制” －> “二进制整数”。
2.poll详解
poll通过轮询包含文件操作符的结构体集合，修改结构体中的revents成员，来告诉程序结构体中对应的fd发生了什么。服务器程序通过轮询集合中的结构体，对revents符合要求的进行连接或读取。
1.poll与select机制对比
相同点：
.1.查询方式：内核对应文件描述符的检测也是以线性的方式进行轮询，根据描述符的状态进行处理
2.是否进行有用户态到内核态的拷贝：poll 和 select 检测的文件描述符集合会在检测过程中频繁的进行用户区和内核区的拷贝，它的开销随着文件描述符数量的增加而线性增大，从而效率也会越来越低。
不同点：
1.文件描述符上限：select检测的文件描述符个数上限是1024，poll没有最大文件描述符数量的限制，这是由于在poll中，文件描述符的信息是使用链表来存储的。
2.是否可跨平台：select可以跨平台使用，poll只能在Linux平台使用。
3.文件描述符信息储存方式：select使用位图的方式标记委托内核检测的文件描述符，每个比特位对应一个唯一的文件描述符。poll直接将要检测的文件描述符的信息封装到结构体struct pollfd中，用户态和内核态下都可直接读写结构体变量。
2.函数原型
#include fds: 这是一个 struct pollfd 类型的数组，里边存储了待检测的文件描述符的信息，这个数组中有三个成员：
fd：委托内核检测的文件描述符。
events：委托内核检测的 fd 事件（输入、输出、错误），每一个事件有多个取值。
revents：这是一个传出参数，数据由内核写入，存储内核检测之后的结果。
nfds: 这是第一个参数数组中最后一个有效元素的下标 + 1（也可以指定参数 1 数组的元素总个数）
timeout: 指定 poll 函数的阻塞时长
-1：一直阻塞，直到检测的集合中有就绪的文件描述符（有事件产生）解除阻塞
0：不阻塞，不管检测集合中有没有已就绪的文件描述符，函数马上返回
大于 0：阻塞指定的毫秒（ms）数之后，解除阻塞
函数返回值：
失败： 返回 - 1
成功：返回一个大于 0 的整数，表示检测的集合中已就绪的文件描述符的总个数。
3.服务端代码
poll 和 select 进行 IO 多路转接的处理思路是完全相同的。
#include 4.客户端代码
#include 3.epoll详解
1.I/O复用 I/O转接
IO 多路转接的意思是在一个操作里同时监听多个输入输出源，在其中一个或多个输入输出源可用的时候返回，然后对其的进行读写操作。
2.相比select和poll，epoll的优点
- 1.对于待检测集合select和poll是基于线性方式处理的，epoll是基于红黑树来管理待检测集合的。select和poll每次都会线性扫描整个待检测集合，集合越大速度越慢，epoll使用的是回调机制，效率高，处理效率也不会随着检测集合的变大而下降。
- 2.select和poll工作过程中存在内核/用户空间数据的频繁拷贝问题，在epoll中内核和用户区使用的是共享内存（基于mmap内存映射区实现），省去了不必要的内存拷贝。
- 3.程序猿需要对select和poll返回的集合进行判断才能知道哪些文件描述符是就绪的，通过epoll可以直接得到已就绪的文件描述符集合，无需再次检测
- 4.使用 epoll 没有最大文件描述符的限制，仅受系统中进程能打开的最大文件数目限制。
select/poll 低效的原因之一是将 “添加 / 维护待检测任务” 和 “阻塞进程 / 线程” 两个步骤合二为一。每次调用 select 都需要这两步操作，然而大多数应用场景中，需要监视的 socket 个数相对固定，并不需要每次都修改。epoll 将这两个操作分开，先用 epoll_ctl() 维护等待队列，再调用 epoll_wait() 阻塞进程（解耦）。
3.函数原型
#include 1.epoll_create()
epoll_create() 函数的作用是创建一个红黑树模型的实例，用于管理待检测的文件描述符的集合。返回值为一个文件描述符int epfd。该文件描述符指向红黑树的根节点。
2.epoll_ctrl()
结构体上树，设置监听。
epoll_ctl() 函数的作用是管理红黑树实例上的节点，可以进行添加、删除、修改操作。
// 联合体, 多个变量共用同一块内存
typedef union epoll_data {
void *ptr;
int fd; // 通常情况下使用这个成员, 和epoll_ctl的第三个参数相同即可
uint32_t u32;
uint64_t u64;
} epoll_data_t;
struct epoll_event {
uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
- epfd：epoll_create () 函数的返回值，通过这个参数找到 epoll 实例
- op：这是一个枚举值，控制通过该函数执行什么操作
EPOLL_CTL_ADD：往 epoll 模型中添加新的节点
EPOLL_CTL_MOD：修改 epoll 模型中已经存在的节点
EPOLL_CTL_DEL：删除 epoll 模型中的指定的节点 - fd：文件描述符，即要添加 / 修改 / 删除的文件描述符
- event：epoll 事件，用来修饰第三个参数对应的文件描述符的，指定检测这个文件描述符的什么事件
- events：委托 epoll 检测的事件
EPOLLIN：读事件，接收数据，检测读缓冲区，如果有数据该文件描述符就绪
EPOLLOUT：写事件，发送数据，检测写缓冲区，如果可写该文件描述符就绪
EPOLLERR：异常事件 - data：用户数据变量，这是一个联合体类型，通常情况下使用里边的 fd 成员，用于存储待检测的文件描述符的值，在调用 epoll_wait() 函数的时候这个值会被传出。
3.epoll_wait()
返回就绪的文件描述符。
epoll_wait() 函数的作用是检测创建的 epoll 实例中有没有就绪的文件描述符。
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
函数参数：
- epfd：epoll_create () 函数的返回值，通过这个参数找到 epoll 实例
- events：传出参数，这是一个结构体数组的地址，里边存储了已就绪的文件描述符的信息。
- maxevents：修饰第二个参数，结构体数组的容量（元素个数）
- timeout：如果检测的 epoll 实例中没有已就绪的文件描述符，该函数阻塞的时长，单位 ms 毫秒
0：函数不阻塞，不管 epoll 实例中有没有就绪的文件描述符，函数被调用后都直接返回
大于 0：如果 epoll 实例中没有已就绪的文件描述符，函数阻塞对应的毫秒数再返回
-1：函数一直阻塞，直到 epoll 实例中有已就绪的文件描述符之后才解除阻塞.
函数返回值：
- 成功：
等于 0：函数是阻塞被强制解除了，没有检测到满足条件的文件描述符
大于 0：检测到的已就绪的文件描述符的总个数。对应个数的结构体在第二个参数events中被传出。 - 失败：
- 返回 - 1
4.服务端代码
#include 5.客户端代码
同。
select poll epoll的区别及使用场景
#include 区别：
1.最大连接数：
select：单个进程所能打开的最大连接数有FD_SETSIZE宏定义。
poll：它没有最大连接数的限制，原因是它是基于链表来存储的。
epoll：虽然连接数有上限，但是上限很大。
2.FD剧增后带来的IO效率问题
select：每次调用时select都会对文件描述符进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。
poll：与select相同
epoll：事件驱动I/O，mmap（一种内存映射方法）实现内核与用户空间的消息传递，epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback。
3.消息传递方式
select：每次调用都需要在用户空间和内核空间来回的拷贝文件描述符集合，而且每次调用select需要重新初始化 集合fd_set，内核需要将消息传递到用户空间，都需要内核拷贝动作。
poll：和select相同
epoll：epoll通过mmap，内核和用户空间共享一块内存来实现消息传递。
使用场景 ：
1.连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
2.连接很多，则epoll更快。
epoll的实现机制：
epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：
1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3）调用epoll_wait收集发生的事件的连接
内部结构：
epoll_create方法时，Linux内核会创建一个eventpoll结构体
struct eventpoll{
....
/*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
struct rb_root rbr;
/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
struct list_head rdlist;
....
};
用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中(红黑树的插入时间效率是lgn，其中n为节点数量)，红黑树存储在内核中，用来长久的维护一个装有文件描述符的集合。
所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。
在epoll中，对于每一个事件，都会建立一个epitem结构体
struct epitem{
struct rb_node rbn;//红黑树节点
struct list_head rdllink;//双向链表节点
struct epoll_filefd ffd; //事件句柄信息
struct eventpoll *ep; //指向其所属的eventpoll对象
struct epoll_event event; //期待发生的事件类型
}
当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。
三步曲
第一步：epoll_create()系统调用。此调用返回一个句柄，之后所有的使用都依靠这个句柄来标识。
第二步：epoll_ctl()系统调用。通过此调用向epoll对象中添加、删除、修改感兴趣的事件，返回0标识成功，返回-1表示失败。
第三部：epoll_wait()系统调用。通过此调用收集收集在epoll监控中已经发生的事件。