多路IO复用服务器——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模型优缺点

优点：

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

缺点：

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

六、poll模型

几乎与select一模一样。但是使用频率远低于select模型。

优点：

1. 监听事件的种类丰富，对监听与就绪进行了传入传出分离， 无需用户分离。
2. poll 支持用户自定义长度结构体数组作为集合，突破了1024限制（然而没解决轮询，没啥大用）

缺点：

1. 轮询问题，拷贝开销与挂载开销，只返回就绪数量用户自行遍历查询就绪，poll只支持毫秒级别定时。
2. 在某些特定的Linux版本才可以使用。

---

总结

IO复用技术其实就是一种sock监听技术。