- IO模型介绍
- 阻塞IO
- 非阻塞
- 多路复用
- 异步
- IO模型比较分析
- selectors
阻塞IO:之前写的所有的socket,recv,accput都是
阻塞原理:
其实多数时间多用到了等待数据那里.
非阻塞IO:当你需要数据时,你给系统要系统知道没有数据,但他会反馈给你,没有数据,代码继续向下走
多路复用: 有好几种机制: select,poll(比select稍微好点,也是轮询,底层数据做了优化),epoll(最好的在windows上没有存在于linx上有,不使用轮询,采用的是回调函数机制.)
简单来说:多个conn复用着同一个线程操作
是操作系统提供给你的,对于你来说,是一个代理,帮助你监听所有的通信对象,是否有数据来到操作系统中,一旦有,就通知你,你再来根据通知来接收相应的数据,而你就不需要,一直循环着问每一个对象是否有信息来,而是阻塞等待,任意一个来,我就就接收.
select监听数据的过程:
用户进程创建socket对象，拷贝监听的fd到内核空间，每一个fd会对应一张系统文件表，内核空间的fd响应到数据后，就会发送信号给用户进程数据已到； 用户进程再发送系统调用，比如（accept）将内核空间的数据copy到用户空间，同时作为接受数据端内核空间的数据清除，这样重新监听时fd再有新的数据又可以响应到了（
发送端因为基于TCP协议所以需要收到应答后才会清除）。
优点:
相比其他模型，使用select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。
如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值
缺点:
首先select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。
#很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，…。
#如果需要实现更高效的服务器程序，类似epoll这样的接口更被推荐。遗憾的是不同的操作系统特供的epoll接口有很大差异，
#所以使用类似于epoll的接口实现具有较好跨平台能力的服务器会比较困难。 #其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的原理图:
异步IO:(最好的机制)