重新认识IO以及五种IO模型（理论认识）
目录
一、重新认识IO
1、读取数据
2、写入数据
二、认识五种IO模型
1、场景一：干等式钓鱼
2、场景二：频繁检测式钓鱼
3、场景三：提醒式钓鱼
4、场景四：批量式钓鱼
5、场景五：代理式钓鱼
三、什么时候结束等待？？
最早在学习文件系统的时候，对IO的初步认识是将数据写入到文件以及从文件读取数据。但是学习TCP/IP时了解到，传输层属于内核区，存在接收/发送缓冲区。
因此我们对IO有了一个新的认识，以TCP/IP模型为例，IO过程其实是一个拷贝的过程，读取就是将接收缓冲区里的数据拷贝到应用层，写入就是将应用层的数据拷贝到发送缓冲区。
一、重新认识IO
实际上的IO并不是像最开始那么简单，还需要在上述结论的基础上润润色。
1、读取数据
前面说到，读取数据本质是将接收缓冲区的数据拷贝到用户层，但是如果接收缓冲区里没有数据呢？此时上层就需要先等待接收缓冲区里的数据准备就绪了，再读取数据。
五种IO模型其实就是采用不同的等待方式来等待数据就绪。
2、写入数据
写入数据也是同理，写入数据本质是将应用层的数据拷贝到发送缓冲区。如果发送缓冲区已经满了，此时上层也需要等待发送缓冲区里的剩余空间准备就绪了，然后再拷贝数据到发送缓冲区。
五种IO模型无论是读取还是写入，都有两个过程 等待 和 拷贝。=》 IO过程 = 等待 + 拷贝
二、认识五种IO模型
与IO模型相关的无非就两个话题：改变等待的方式、减少等待时间的比重。改变等待的方式可以直接或者间接影响等待时间的比重；减少等待时间相对于IO过程所花时间的比重 衡量了一个IO过程是否高效。
下面就以五种钓鱼的场景来认识这五种模型。
1、场景一：干等式钓鱼
张三钓鱼的方式很简单，把饵抛下去以后，就死死盯着浮标，一旦浮标动了，就把鱼拉上来。
这种方式其实就是阻塞模型，read接口函数就是典型的阻塞模型，每次只能等待一个文件描述符，在接收缓冲区有足够的数据之前，会一直阻塞等待，此时的read函数也不会有返回值。
2、场景二：频繁检测式钓鱼
李四的钓鱼方式就稍微好一点，把饵抛下去以后，就坐在一边看看书，每隔10s抬头看看浮标有没有动静，如果有动静了就把鱼钓上来。
这种方式就是非阻塞模型，以读数据为例，其实就是通过while循环不断进入检测数据是否就绪，如果没有就绪则继续循环检测；如果数据就绪，就把数据读取到上层。一般不建议使用这种方式，不断检测就意味着要从用户态切换到内核态，然后再切换回来，这对CPU来说是较大的浪费。
3、场景三：提醒式钓鱼
王五把饵抛下去以后，在鱼竿上挂了一个铃铛，然后就坐在一边看书不管不顾，当铃铛响了的时候，就把鱼钓上来。
这种方式就是信号驱动模型。每当内核有数据就绪的时候，主动通知上层来取，发送的信号为第29号信号 SIGIO。这种方式并非最佳方案，有的时候，即便数据就绪了也不一定会发送这个信号，因为接收缓冲区存在水位线的概念，只有当数据达到一定量的时候，才会让上层来取。
4、场景四：批量式钓鱼
赵六有自己的想法，他钓鱼的时候，把20个鱼竿插在了岸边，然后就在岸边轮询，一个一个的看过去，如果有哪个鱼竿的浮标动了，就把鱼钓上来。
这种方式就是多路转接模型。类似于阻塞模型的批量版，但是最关键的是，一次可以等待多个文件描述符，只要有一个文件描述符变为可读状态，就把数据读取到上层。
5、场景五：代理式钓鱼
田七是个老板，不想钓鱼，只想吃鱼，于是就让他的司机去河边钓鱼，同时给他一个空桶，让司机把桶装满了再打电话通知他。
这种方式就是异步IO模型。此时上层就没有参与到IO这个过程，只是在调用接口函数的时候，告诉内核数据准备就绪以后直接放到某个位置。上层只关心数据什么时候准备好，完全不关心数据的获取过程。
三、什么时候结束等待？？
结束等待的时间是 读事件就绪 或者 等事件就绪。
读事件就绪，其实是当接收缓冲区有了足够的数据以后，再让上层去读。缓冲区里有水位线的概念，没有超过水位线，说明数据量较少，此时不会通知上层来取，因为读取一次有成本，需要从用户态切换到内核态，然后再切换回去，频繁切换状态的成本很高。
写事件就绪，其实是当缓冲区里有足够的空间来存放上层拷贝的数据时，再让上层拷贝到缓冲区。
补充：学习TCP协议的时候有个psh标记位，其实就是在告诉对方OS“不要去管什么水位线了，赶紧让上层把数据取走吧”