IO模型

同步阻塞IO模型

同步阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞
用户线程通过系统调用read发起IO读操作，由用户控件转到内核空间，内核等到数据包到达后，然后将接受的数据拷贝至用户空间，完成read操作
用户需要等待read将数据读取到buffer后，才继续处理接受的数据，整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能够做任何事情，对CPU的资源利用率不够
同步非阻塞IO模型
用户线程发起IO请求时立即返回，但并未读取到任何数据，用户线程需要不断的发起IO请求，知道数据到达后，才真正读取到数据，继续执行，即“轮询机制”
整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但为了等到数据，仍需要不断的轮询、重复请求，消耗了大量的CPU资源
是比较浪费CPU的方式，一般很少世界使用该模型，而是在其他io模型中使用费阻塞IO这一特性
IO多路复用模型
多个连接公用一个等待机制，本模型会阻塞进程，但进程是阻塞在select或poll这两个系统调用上，而不是阻塞在真正的IO操作上
用户首先将需要进行IO操作添加到select中，继续执行做其他的工作(异步)，同事等待select系统调用返回，当数据到达时，IO被激活，select函数返回，用户线程正式发起read请求，读取数据并继续执行
从流程上看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，升值还多了添加监视IO，以及调用select函数的额外操作，效率更差，并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已有IO操作准备就绪，即可达到在同一个线程内同事处理多个IO请求的目的，而不像阻塞IO那种，一次只能监控一个IO
虽然上述方式允许单线程内处理多个IO请求，但每个IO请求的过程还是阻塞的(在select函数上阻塞)，平均时间甚至比同步阻塞IO模型还要长，如果用户线程只是注册自己需要的IO请求，然后去做自己的事情，等到数据到来时在进行处理，则可以提供CPU的利用率
IO多路复用时常见的IO模型，但是其异步程序还不够"彻底"，因它使用了会阻塞线程的select系统调用，因此IO多路复用只能称为异步阻塞IO模型，而非真正的异步IO

多路IO复用
IO多路复用是指内核一旦发现进程指定的一个或多个IO条件准备读取，就通知该进程

适用场合：

当同时处理多个套接字时，(一般指交互式输入和网络套接口)，必须使用I/O复用
当一个客户端同时处理多个套接字时，此情况很少出现
当一个TCP服务器既要处理监听套接字，又要处理已连接套接字，一般使用IO多路复用(常见)
当一个服务器既要处理TCP又要处理UDP，一般使用IO多路复用
当一个服务器要处理多个服务或多个协议，一般使用IO多路复用

信号驱动IO模型：signal-driven IO【不常见】--------半异步
用户进程可以通过sigaction系统调用注册一个信号处理程序，然后主程序可以继续向下执行，当有IO准备就绪时，由内核发出一个SIGIO信号处理程序执行，然后将用户进程所需要的从内核控件拷贝至用户空间
该模型的有事在于等待数据包到达期间进程不被阻塞，用户主程序可以继续执行，只要等待来自信号处理函数的通知

异步IO模型
异步IO与信号驱动IO最主要区别：

　　信号驱动IO是由内核通知何时可以进行IO操作，而异步IO则是由内核告诉用户线程IO操作何时完成，信号驱动IO当内核通知出发信号处理程序时，信号处理程序还需要阻塞在从讷河空间缓冲区拷贝数据到用户空间缓冲区这个阶段，而异步IO直接是在第二阶段完成后，内核直接通知用户线程可以进行后续操作了
相对于IO多路复用模型，异步IO并不常用，不少高并发程序使用“IO多路复用模型+多线程任务”处理架构基本可以满足需求，目前操作系统对异步IO的支持本非特别完善，更多的是采用IO多路复用模型模拟异步IO的方式(IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到 用户指定的缓冲区中)

IO模型的具体实现：
　　【*】select：Linux实现对应IO复用模型,BSD4.2最早实现(跨平台也支持Windows)
　　【*】poll：Linux实现对应IO复用模型,system V unix最早实现(改进版的select)
　　【*】epoll：Linux实现对应IO复用模型，具有信号驱动IO模型的某些特性
　　kqueue：Freebsd实现对应IO复用模型，具有信号驱动当IO模型某些特性
　　/dev/poll：SUN的Solaris实现对应IO复用模型,具有信号驱动IO模型的某些特性
　　【*】Iocp：Windows实现对应第5种(异步IO)模型