网络IO小白的进阶之路3-非阻塞IO

上篇文章 https://blog.csdn.net/qq_38110368/article/details/108206010 提到，单线程阻塞IO 是在等待数据和拷贝数据两个阶段都是阻塞状态，而进程/线程池的方案能处理的连接数，缓解的调用IO也很有限。因此出现非阻塞IO（non-blocking IO）

2. 非阻塞IO

2.1 实现原理

Linux下，可以通过设置socket使其变为non-blocking。当对一个non-blocking socket执行读操作时，流程是这个样子：
图4 非阻塞IO

从图中可以看出，当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个error。从用户进程角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。
所以，在非阻塞式IO中，用户进程其实是需要不断的主动询问kernel数据准备好了没有，和阻塞型接口的显著差异在于，在被调用之后立即返回。
使用如下的函数可以将某句柄fd设为非阻塞状态：
fcntl( fd, F_SETFL, O_NONBLOCK );

下面将给出只用单线程实现方式，虽然是单线程，但能够同时从多个连接中检测数据是否送达，并且接受数据的模型。

图5 使用非阻塞的接收数据模型

在非阻塞状态下，recv() 接口在被调用后立即返回，返回值代表了不同的含义。如在本例中，
recv() 返回值大于 0，表示接受数据完毕，返回值即是接受到的字节数；
recv() 返回 0，表示连接已经正常断开；
recv() 返回 -1，且 errno 等于 EAGAIN，表示 recv 操作还没执行完成；
recv() 返回 -1，且 errno 不等于 EAGAIN，表示 recv 操作遇到系统错误 errno。

可以看到服务器线程可以通过循环调用recv()接口，可以在单个线程内实现对所有连接的数据接收工作。

2.2 弊端

但是上述模型绝不被推荐。因为，循环调用recv()将大幅度推高CPU 占用率，如果要使用此方案，最起码用户态要手动执行sleep()，从而缓解CPU。
此外，在这个方案中recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如select()多路复用模式，可以一次检测多个连接是否活跃。
在下篇文章中，将分享IO复用模式。