Linux下的I/O模型以及各自的优缺点

其实关于这方面的知识，我阅读的是《UNIX网络编程:卷一》，书里是以UNIX为中心展开描述的，根据这部分知识，在网上参考了部分资料。以Linux为中心整理了这篇博客。

UNIX 网络编程（第2版）第1卷：套接口API和X／Open 传输接口API PDF 

UNIX网络编程卷1:套接字联网API(第3版) 中文高清带完整书签 PDF 

Linux的I/O模型

和Unix的I/O模型基本一致，Linux下一共有5种I/O模型[1]

阻塞式I/O模型；

非阻塞式I/O模型；

I/O复用式模型；

信号驱动动式I/O模型

异步I/O模型

上面这个列表，算是绝大部分关于Linux I/O模型博客中都会贴出来的。

在上述５种I/O模型中，前4种，其实都可以划分为同步I/O方式，只有最有一种异步I/O模型才使用异步I/O方式。
为什么这么划分呢，就得仔细看看这5种I/O模型到底是什么。

行文须知

下文中对各个模型的描述，都是使用数据报(UDP)套接字作为例子进行说明的。
因为UDP相对与TCP来说比较简单——要么整个数据报已经收到，要么还没有——而对于TCP来说，套接字低水位标记等额外变量开始起作用,导致整个概念变得复杂。（加粗字体的内容在写这篇博客时，并没有搞清楚是什么，可能后续会陆续搞懂）

一、阻塞式I/O

通常我们使用的I/O都是阻塞式I/O，在编程时使用的大多数也是阻塞式I/O。在默认情况下，所有的套接字(socket)都是阻塞的。下图解释了阻塞式I/O模型的流程

上图中，我们说从调用recvfrom开始到它返回的整段时间内是被阻塞的，recvfrom成功返回后，引用程序才开始处理数据报。

阻塞式I/O的优缺点

优点：
阻塞式I/O很容易上手，一般程序按照read-process的顺序进行处理就好。通常来说我们编写的第一个TCP的C/S程序就是阻塞式I/O模型的。并且该模型定位错误，在阻塞时整个进程将被挂起，基本不会占用CPU资源。
缺点:
该模型的缺点也十分明显。作为服务器，需要处理同时多个的套接字，使用该模型对具有多个的客户端并发的场景时就显得力不从心。
当然也有补救方法，我们使用多线程技术来弥补这个缺陷。但是多线程在具有大量连接时，多线程技术带来的资源消耗也不容小看：

如果我们现在有1000个连接时，就需要开启1000个线程来处理这些连接，于是就会出现下面的情况

线程有内存开销，假设每个线程需要512K的存放栈，那么1000个连接就需要月512M的内存。当并发量高的时候，这样的内存开销是无法接受的。

线程切换有CPU开销，这个CPU开销体现在上下文切换上，如果线程数越多，那么大多数CPU时间都用于上下文切换，这样每个线程的时间槽会非常短，CPU真正处理数据的时间就会少了非常多。

二、非阻塞式I/O

有阻塞I/O，那么也会有非阻塞I/O，在上文说过默认情况下，所有的套接字都是阻塞的，那么通过设置套接字的NONBLOCK(一般在open(),socket()等调用中设置)标志或者设置recv、send等输入输出函数的MSG_DONTWAIT标志就可以实现非阻塞操作。
那我们来看看非阻塞I/O模型的运行流程吧

可以看到，前三次recvfrom时没有数据可以返回，此时内核不阻塞进程，转而立即返回一个EWOULDBLOCK错误。第四次调用recvfrom时已经有一个数据报准备好了，此时它将被复制到应用进程的缓冲区，于是recvfrom调用成功返回。
当一个应用进程像这样对一个非阻塞描述符循环调用recvfrom时，我们称之为轮询(polling)

非阻塞式I/O的优缺点

优点：
这种I/O方式也有明显的优势，即不会阻塞在内核的等待数据过程，每次发起的I/O请求可以立即返回，不用阻塞等待。在数据量收发不均，等待时间随机性极强的情况下比较常用。
缺点
轮询这一个特征就已近暴露了这个I/O模型的缺点。轮询将会不断地询问内核，这将占用大量的CPU时间，系统资源利用率较低。同时，该模型也不便于使用，需要编写复杂的代码。

三、I/O复用模型

上文中说到，在出现大量的链接时，使用多线程+阻塞I/O的编程模型会占用大量的内存。那么I/O复用技术在内存占用方面，就有着很好的控制。
当前的高性能反向代理服务器Nginx使用的就是I/O复用模型(epoll),它以高性能和低资源消耗著称，在大规模并发上也有着很好的表现。
那么，我们就来看一看I/O复用模型的面目吧