五种网络IO模式

阻塞IO
小明同学急用开水，打开水时发现开水龙头没水，他一直等待直到装满水然后离开。这一过程就可以看成是使用了阻塞IO模型，因为如果水龙头没有水，他也要等到有水并装满杯子才能离开去做别的事情。很显然，这种IO模型是同步的。
在linux 中，默认情况下所有的socket都是blocking IO, 一个典型的读操作流程：

非阻塞IO
小明同学又一次急用开水，打开水龙头后发现没有水，因为还有其它急事他马上离开了，过一会他又拿着杯子来看看……在中间离开的这些时间里，小明同学离开了装水现场(回到用户进程空间)，可以做他自己的事情。这就是非阻塞IO模型。但是它只有是检查无数据的时候是非阻塞的，在数据到达的时候依然要等待复制数据到用户空间(等着水将水杯装满)，因此它还是同步IO。
当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。
所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。
典型的非阻塞IO模型一般如下：
设置非阻塞常用方式：
方式一: 创建socket 时指定

int s = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, IPPROTO_TCP);

方式二: 在使用前通过如下方式设定

fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, 0) | O_NONBLOCK);

IO多路复用
有一天，学校里面优化了热水的供应，增加了很多水龙头，这个时候小明同学再去装水，舍管阿姨告诉他这些水龙头都还没有水，你可以去忙别的了，等有水了告诉他。于是等啊等(select调用中)，过了一会阿姨告诉他有水了。
这里有两种情况：

情况1: 阿姨只告诉来水了，但没有告诉小明是哪个水龙头来水了，要自己一个一个去尝试。(select/poll 场景)

情况2: 舍管阿姨会告诉小明同学哪几个水龙头有水了，小明同学不需要一个个打开看(epoll 场景)

当用户进程调用了select，那么整个进程就会被block，而同时，kernel会 “监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从kernel拷贝到用户进程。

所以，IO多路复用的特点是通过一种机制，一个进程能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入就绪状态，select()函数就可以返回。

这里需要使用两个system call（select 和 recvfrom），而blocking IO只调用了一个system call（recvfrom）。但是，用select的优势在于它可以同时处理多个connection。
如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用mutil-threading + blocking IO的web server性能更好，可能延迟还更大。select/epoll 的优势并不是对于单个连接能处理得更好，而是在于能同时处理更多的连接。