LV06-03-网络编程-07-多路复用IO-04-总结
本文主要是网络编程——多路复用IO中的select、poll和epoll的总结的相关笔记，若笔记中有错误或者不合适的地方，欢迎批评指正😃。
点击查看使用工具及版本
| Windows | windows11 |
| Ubuntu | Ubuntu16.04的64位版本 |
| VMware® Workstation 16 Pro | 16.2.3 build-19376536 |
| SecureCRT | Version 8.7.2 (x64 build 2214) - 正式版-2020年5月14日 |
| 开发板 | 正点原子 i.MX6ULL Linux阿尔法开发板 |
| uboot | NXP官方提供的uboot，NXP提供的版本为uboot-imx-rel_imx_4.1.15_2.1.0_ga(使用的uboot版本为U-Boot 2016.03) |
| linux内核 | linux-4.15(NXP官方提供) |
| STM32开发板 | 正点原子战舰V3(STM32F103ZET6) |
点击查看本文参考资料
| 参考方向 | 参考原文 |
| --- | --- |
一、select、poll和epoll对比
1. 用户态将文件描述符传入内核的方式
select：创建3个文件描述符集并拷贝到内核中，分别监听读、写、异常动作。这里受到单个进程可以打开的fd数量限制，由FD_SETSIZE设置，默认是最大是1024。poll：将传入的struct pollfd结构体数组拷贝到内核中进行监听，poll克服了select模型的最大并发数限制。epoll：执行epoll_create，会在内核的高速cache区中，建立一颗红黑树以及就绪链表(该链表存储已经就绪的文件描述符)。接着用户执行的epoll_ctl函数，添加文件描述符会在红黑树上增加相应的结点。
2. 内核态检测文件描述符读写状态的方式
select：采用轮询方式，遍历所有fd，最后返回一个描述符读写操作是否就绪的mask掩码，根据这个掩码给fd_set赋值。poll：同样采用轮询方式，查询每个fd的状态，如果就绪则在等待队列中加入一项并继续遍历。epoll：采用事件回调机制。在执行epoll_ctl的add操作时，不仅将文件描述符放到红黑树上，而且也注册了回调函数；内核在检测到某文件描述符可读/可写时会调用回调函数，该回调函数将文件描述符放在就绪链表中。
3. 找到就绪的文件描述符并传递给用户态的方式
select：将之前传入的fd_set拷贝传出到用户态并返回就绪的文件描述符总数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判断。poll：将之前传入的fd数组拷贝传出用户态，并返回就绪的文件描述符总数。用户态并不知道是哪些文件描述符处于就绪态，需要遍历来判断。epoll：epoll_wait只用观察就绪链表中有无数据即可，最后将链表的数据返回给数组, 并返回就绪的数量。内核，将就绪的文件描述符，放在传入的数组中。然后，依次遍历，处理即可。这里返回的文件描述符，是通过mmap()，让内核和用户空间，共享同一块内存实现传递的，减少了不必要的拷贝。
4. 重复监听的处理方式
select：将新的监听文件描述符集合拷贝传入内核中，继续上边的步骤。poll：将新的struct pollfd结构体数组拷贝传入内核中，继续上边的步骤。epoll：无需重新构建红黑树，直接沿用已存在的即可。
5. 时间复杂度
select：O(n)，随着连接数n的增大而增大。poll：O(n)，随着连接数n的增大而增大。epoll：O(1)，不会随着连接数n的增大而增大。
二、epoll更高效？
select和poll的动作基本一致，只是poll采用链表来进行文件描述符的存储，而select采用fd标注位来存放，所以select会受到最大连接数的限制，而poll不会。
select、poll、epoll虽然都会返回就绪的文件描述符数量, 但是select和poll并不会明确指出是哪些文件描述符就绪，而epoll会。这就意味着系统调用返回后，调用select和poll的程序需要遍历监听的整个文件描述符找到是哪个文件描述符处于就绪，而epoll则直接处理即可（直接监听到了哪些文件描述符就绪）。
select、poll都需要将有关文件描述符的数据结构拷贝进内核，最后再拷贝出来。而epoll创建的有关文件描述符的数据结构本身就存于内核态中，系统调用返回时利用 mmap() 文件映射内存加速与内核空间的消息传递：即 epoll 使用 mmap() 减少复制开销。
select、poll采用 轮询 的方式来检查文件描述符是否处于就绪态，而epoll采用回调机制。造成的结果就是，随着fd的增加，select和poll的效率会线性降低，而epoll不会受到太大影响，除非活跃的socket很多。
epoll的边缘触发模式效率高，系统不会充斥大量不关心的就绪文件描述符。
最后，虽然epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。