标题索引
追溯IO原因
网络数据流
网络IO模型
IO模型举例
追溯IO原因
从事项目多年来，有个问题一直困扰着我，但因种种原因一直没有翻阅资料去释怀，随着项目经历的增加、年龄的增长和责任的使命促使我去诠释这个困扰我多年的问题，这个问题就是"网络IO模型"，希望这个问题能够给知识库项目的建设添砖加瓦，希望这个问题能够给后续兄弟们带来启发和避免行走不必要的弯路，希望这个问题促进我对“有物为证”的理解更上一层。
网络数据流
客户端发起一个http请求，服务器端处理响应http请求，这一过程在服务器端以网络IO的角度，经历了哪些阶段，具体可参考下图：
图1-1网络进程IO流程图
如上图当服务器接受到一个http请求时，具体操作流程如下：
1.用户空间进程通过reveform函数接收等待接收数据包，并将接收到的数据包在内核通过四表五链检查网络状态，若通过网络检查，则提交给用户空间http进程；
2.http进程解析请求，并发起系统调用read函数，到达内核空间；
3.内核空间执行read函数读取磁盘内容，并将此内容加载至内存；
4.内核空间提交给用户空间http进程，告知数据已经read完毕；
5.用户空间http进程根据请求报文进行构建响应报文；
6.构建完http响应报文后，通知内核空间构建网络封装；
7.内核空间再次通过四表五链网络状态，通过网卡发送构建好的http的响应报文。
此为服务器构建网络数据包触发IO的过程，根据此过程进行分析IO模型，若在高并发的情况下，在哪一步可以实现多IO并存，哪一步可以实现IO的优化。
单纯根据流程可得信息如下，
1.单进程接收响应数据报文调用receform函数时，与此同时不执行其他函数调用，此时严重影响效率；
2.当内核空间执行read函数后提交给用户空间进行http封装，最后调用内核空间进行网络封装构建并发送报文；
网络IO模型
根据上述的流程可以将一次IO逻辑意义上处于两种形态，在这两种形态上进行优化IO才可进行优化整体的性能，此两种形态在Linux网络编程中定义如下：
第一种：Waiting for the data to be ready
等待数据准备，逻辑意义上是内核网络驱动等待接收网络数据包，即上述案例中第1步，表现在内核形态，同时也是数据流可得信息的第1步，在用户空间封装完毕后如何通知内核层再次进行网络报文的构建，在此状态下诞生两种状态同步(synchronous)和异步(asynchronous)，同步为进程自已主动等待函数执行成功并返回消息后才能继续执行其他函数，异步为函数执行完成后主动通知进程进行执行其他还是，最后进行内核空间对网络IO进行解封装。
第二种：Copying the data from the kernel to the process
将数据从内核拷贝到进程中，逻辑意义上是内核空间调用并执行系统调用函数后将执行的结果反馈给用户空间，让用户空间进行构建响应报文，即上述案例中第4步，同时也是数据流可得信息的第2步，用户空间的进程能否执行其他函数，从而提升整体性能。在此状态下诞生两种状态，阻塞(blocking)和非阻塞(nonblocking)，阻塞状态为指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，即进程调用函数后被挂起，直到函数返回结果后才能执行其他操作，非阻塞状态指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成，最终的调用结果返回之前，调用者不会被挂起，即进程在执行函数后，无需等待执行结果，仍可继续执行其他函数。
因此通过组合形成如下模型：
1、阻塞IO模型
同步阻塞IO模型具体如下图
图2-1 阻塞IO模型图
在同步阻塞IO模型中，
2.非阻塞IO模型
同步阻塞IO模型具体如下图
图2-2 非阻塞IO模型图
3.IO多路复用模型
IO多路复用模型如下图
图2-3 IO多路复用模型图
4.