多路IO复用服务器——select模型和poll模型

文章目录

一、多路IO复用服务器是什么？
二、使用原理
三、种类
四、select模型
五、select模型优缺点
六、poll模型
总结

一、多路IO复用服务器是什么？

服务器要与客户端完成tcp连接，并保持连接维护可用sock。
每个都需要准备一个进程管一个sock，代价太大，不能让进程等待数据。
解决办法：监听sock，设置sock事件管理（sock事件：读、写、异常）
监听事件触发->事件触发->处理事件->处理完毕

二、使用原理

用一种技术来帮忙监听sock，搞一个进程使用IO复用技术监听所有可监听的sock，监听与辨别就绪（客户端还是服务端），然后处理就绪。
主要特点是recv和accept不再是阻塞，监听功能交给了IO复用，它只负责读取就可以了。
lO复用技术有名多路IO转接技术，可以帮助开发者监听大量的sock。可以单进程实现一对多。
如果此模型在读取处理请求时无法建立新连接，连接时依然无法读取数据。

三、种类

IO复用技术有很多种：select、poll、epoll。详细认识一下select模型（其他的差不多）

四、select模型

要想使用select模型，就先得建立一个监听集合。select模型的监听集合是fd_set类型，存储所有监听的sock。大小固定为1024。集合里每一位对应一个sock。服务器最开始有个serverfd的sock。
监听数量要的是maxfd+1，并且记得**+3**（监听集合对应文件描述符表：最开始应该会有0，1，2（标准输入，标注输出、标准出错））
所以要执行时时刻记录最大的描述符 maxfd。
监听集合里面设置的是0或1代表是否监听。
调用select函数，但其实它也是一个阻塞监听函数，使用的是轮询监听。参数是监听数量、监听事件选择（以集合为单位批处理），监听阻塞函数，工作模式（NULL代表阻塞监听）。返回值是int类型，就绪码。
监听集合里的是一个传入传出参数，传入代表监听谁，传出代表谁就绪了。
当监听的sock就绪，select会修改监听集合改为就绪集合传出，便于用户判断就绪的sock。将就绪sock保留为1，没就绪清0。
单进程需要一个数组存储sock。
serverfd就绪->建立tcp->将新的sock设置到监听集合中，并将它放入sock数组。
clientfd就绪->读取数据处理并响应->如果客户端断开将此sock从数组中删除，将监听取消。

监听集合（就绪集合）下一次不能再次使用。监听集合当就绪后会被修改，所以用户要将传入和传出分离。

如果就绪的数量 >1 产生异常，因为就绪的sock存储在oset中，用户处理完就绪后(建立连接读取完数据)，将刚刚处理完毕的sock在oset中设置0 ，避免因为oset不变导致异常判断的问题。

五、select模型优缺点

优点：

使用比较简单，了解监听集合以及IO复用机制即可使用帮助用户完成少量sock的网络事件监听。
跨平台兼容性比较好，在各个系统语言均有select支持。
select支持微妙级定时，可以满足一些特定需求。

缺点：

select无法满足大监听需求，最大监听数1024(fd set)。
轮询监听(CPU)，虽则轮询数量的增大， O处理性能(CPU)呈线性下降。
select监听到就绪后只返回就绪的数量，需要用户自行遍历查找就绪的sock。
需要用户进行传入传出分离设置。
随着select的持续使用，会有庞大的拷贝开销与挂载开销。（select每轮使用都需要将新的监听拷贝到内核空间，但是监听集合中大量的项以前已经拷贝过，重复且没有意义的拷贝开销）
监听的数量比较少，其次设置监听不灵活，无法针对不同的sock设置不同的监听。