netty启程之路（一）：Linux的五种网络I/O模型

最近项目不急，闲来经领导提点，学习一下netty框架，再次做些JJYY的东西；

众所周知，netty是目前比较流行的JAVA NIO框架，提到NIO，就不得不从操作系统的I/O模型开始说起：

Linux操作系统上的IO操作是如何完成的？

a. 由应用进程发起IO请求，调用内核指令；

b. 内核指令会返回一个fd（对文件的操作称为文件描述符，对socket的操作称为socket描述符），实际上Linux中的fd就是一个数字，指向内核中的一个结构体；

        c. 等待fd指向的结构体就绪（整个IO操作过程最耗时耗资源的地方就在这里，后面几种IO模型都是针对这里实现的）；

d. 将数据报从内核复制到用户空间；

e. 完成复制通知应用进程处理数据报；

根据网络编程对I/O模型的分类，可以将Linux的I/O模型分为五类：1. 阻塞I/O模型；2. 非阻塞I/O模型；3. 多路复用模型；4. 信号驱动I/O模型；5. 异步I/O模型；

1. 阻塞I/O模型：

阻塞I/O模型是最常用的I/O模型，文件系统在默认情况下都是采用这种I/O模型；在应用进程中调用recvfrom，系统调用会一直等待，直到数据包进入应用进程的缓冲区或者发生错误的时候才会返回，因此被成为阻塞I/O；

这种I/O模型有两个明显的缺点：

第一，当需要的数据迟迟不能返回的时候，应用进程会一直阻塞，增大系统的响应时间，

第二，当IO请求并发量比较大时，会导致大量进程阻塞，增大服务器的资源占用；

阻塞I/O模型的工作流程如下图：

2. 非阻塞I/O模型：

非阻塞I/O模型在recvfrom调用的时候，如果缓冲区中没有数据的话，会直接返回一个EWOULDBLOCK错误，一般情况下会对这个状态进行轮询检查，看内核是否有数据进来，这种I/O模型虽然一定程度上解决了阻塞I/O等待时间过长的问题，但是轮询检查的时候回多次调用recvfrom会增大内核的负担，无法承载大并发量的I/O请求。非阻塞I/O模型的工作流程如下图：

3. 多路复用模型：

多路复用模型的思想是，当用户进程发起IO请求的时候，将请求到的fd交给内核命令select或者poll去监控，select、poll会采用遍历的方式不断扫描持有的fd，当发现有fd已经就绪的时候，回调函数rollback，但是select、poll函数有两个缺点：

第一，不断遍历持有的fd，效率低下，

第二，由于操作系统限制，select、poll函数能管理的fd个数有限制，默认为1024个；

为此，Linux提供了另一个函数epoll，它采用一种事件驱动的方式来回调rollback函数，这种方式比顺序扫描fd的效率更高，另外，epoll可以管理的fd个数不受操作系统的内核限制，它的最大值只与内存大小有关（据说1GB的内存上可以管理10w个fd，没深入研究过，有兴趣的同学可以去研究Linux的内核源码）。这种IO模型实际上也是一种阻塞的IO模型，但是它可以承载大量的IO请求；多路复用模型的工作流程图如下：

4. 信号驱动的I/O模型

信号驱动的IO模型，最开始不会先调用recvfrom函数，而是去调用sigaction函数，这个函数会生成并执行一个信号处理函数，并且马上返回，此时，应用进程可以继续进行工作，在这个阶段是非阻塞的，当请求的数据报准备就绪时，会生成一个SIGIO的信号通知应用进程调用recvfrom函数完成IO操作，这种模型可以让应用进程在内核准备数据的这段时间内可以继续工作，但是在数据报从内核向用户空间复制的这段时间仍然是阻塞的；信号驱动的I/O模型工作流程图：

5. 异步I/O模型

异步I/O模型是由应用程序告知内核需要进行那些操作，由内核来完成所有的操作（包括数据报的准备和向用户空间的复制等），内核完成所有操作之后，通知应用进程开始处理数据报；异步I/O模型的工作流程如下图：

从工作流程上来看，信号驱动的IO模型和异步IO模型，差别在于通知应用进程的时机，信号驱动IO模型的时机是在IO的数据报准备就绪之后，将数据从内核复制到用户空间之前，而异步IO模型是在数据报复制到用户空间完成之后；这里的异步指的是内核进程和应用进程之间的异步；

从驱动方式上来看，信号驱动的IO模型的驱动载体是fd，即数据准备就绪之后触发，而异步IO模型的驱动载体是事件，即当整个操作完成之后触发。