一 基本概念

用户空间和内核空间

在Linux/Unix中，对于一次读取IO的操作，数据并不会直接拷贝到应用程序的缓冲区(用户空间)，它首先会被拷贝到操作系统内核的缓冲区(内核空间)中，然后才会从操作系统内核的缓冲区拷贝到应用程序的缓冲区。

嵌入式进阶教程分门别类整理好了，看的时候十分方便，由于内容较多，这里就截取一部分图吧。

需要的朋友转发本文+关注+私信【内核】即可领取

同步和异步

同步：发出一个功能调用时，在没有得到结果之前，该调用就不返回，也就是必须一件一件事做，等前一件做完了才能做下一件事。

异步：调用发出后，一般不会马上得到结果，而是在调用的部件完成后，通过状态、通知和回调来通知调用者：状态——监听被调用者的状态(轮询)，调用者需要每隔一定时间检查一次，效率会很低；通知——当被调用者执行完成后，发出通知告知被调用者，无需消耗太多性能；回调——当被调用者执行完成后，会调用被调用者提供的回调函数

同步和异步的区别：请求发出后，如果要等待结果才能继续操作的就是同步，否则是异步；在网络IO模型里，拷贝数据时进程是阻塞的就是同步的，否则是异步的。

阻塞和非阻塞

阻塞：调用结果返回之前，当前线程会被挂起(线程进入非可执行状态，在这个状态下，OS不会给线程分配时间片，即线程暂停运行)，调用结果返回后线程进入就绪态。

非阻塞：调用结果返回之前，该函数不会阻塞当前线程，而会立刻返回。

阻塞和非阻塞的区别：调用立即返回的就是非阻塞，否则就是阻塞的。

阻塞和同步的区别：同步调用在结果返回之前，线程并没有进入挂起状态，OS还会给它分配占用CPU的时间片；阻塞调用在结果返回之前，线程处于挂起状态，OS不会再为其分配占用CPU的时间片，直到结果返回后，线程进入就绪状态在可能继续运行。

在网络编程中，阻塞和非阻塞发生在第一阶段(准备数据阶段)；同步和异步发生在第二阶段(准备好的数据从内核缓冲区拷贝到用户进程缓冲区阶段)

基于上面两种阶段的不同情况，才有了下面几种网络IO模型。

二 五种网络IO模型

阻塞IO(blocking IO)

在 linux 中，默认情况下所有的 socket 都是 blocking，一个典型的读操作流程:

程序发起read调用后，内核会从网络IO获取数据，一开始没拿到数据时，程序是阻塞的，内核等待数据，这是第一个阶段；数据准备好之后，内核把数据从内核缓冲区复制到用户缓冲区，并通知程序，程序恢复就绪状态，这是第二个阶段。

阻塞IO的特点就是两个阶段程序都是阻塞的。几乎所有的IO接口都是阻塞型的，显然不符合实际的生产需求，因为这样效率太低了。

在阻塞模型里提高效率的办法就是使用多线程，比如一个监听套接字，在调用accept后创建新的线程与客户端进行通信，这样就不会影响其他客户端的请求响应了。但线程数量终归有限，可以用非阻塞模型来进一步提高效率。

非阻塞IO(nonblocking IO)

程序调用IO接口时，如果数据没有准备好，会立即获得一个返回结果，如果内核数据准备好了，当程序再次调用接口，就能马上获得数据。这个模型需要程序主动轮询。

使用fcntl(fd, F_SETFL, O_NONBLOCKING)将套接字设置为非阻塞。以recv为例，非阻塞的返回有下面几种结果：

• 1. 返回大于0，表示获得数据，返回值是收到的字节数
• 2. 返回0，表示连接已经断开
• 3. 返回-1且errno是EAGAIN，表示数据还在准备中
• 4. 返回-1且errno不是EAGAIN，表示遇到系统错误

非阻塞模型可以仅用单线程就能完成多个连接的数据请求操作，但是占用cpu较高，轮询效率不高，操作系统提供了更高效的多路复用模型的接口select()。

I/O多路复用(I/O multiplexing)

select，poll以及大名鼎鼎的epoll就是IO多路复用模型，其特点就在于单个系统调用可以同时处理多个网络连接的IO，它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。

当用户进程调用了select/poll/epoll，整个进程会被阻塞，而同时，kernel会“监视”所有select/poll/epoll负责的socket，当任何一个socket中的数据准备好了，select/poll/epoll就会返回。这个时候用户进程再调用recvfrom操作，将数据从内核缓冲区拷贝到用户进程缓冲区。

多路复用模型与阻塞模型的比较：单线程的多路复用模型可以达到多线程的阻塞模型的效果，但是多路复用使用了两个系统调用select()和read()， 而阻塞模型只调用一个read()。 select的优势就是能同时处理多个连接的请求，在少量连接的情况下，单线程多路复用模型的效率不如多线程阻塞模型。

但这个模型依旧有着很多问题。首先 select()接口并不是实现“事件驱动”的最好选择。 因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。 很多操作系统提供了更高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了poll。

如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体量庞大，则对整个模型是灾难性的，降低了事件探测的及时性。

有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号(signal) 等技术以支持异步响应，这使得这些库存成为构建事件驱动模型的不二选择。

阻塞，非阻塞，多路复用都属于同步的。

Linux 内核从 2.6 开始，也引入了支持异步响应的 IO 操作，如 aio_read, aio_write，这就是异步 IO。

异步 IO(Asynchronous I/O)

用户进程发起aio_read操作之后，立刻就可以开始去做其它的事，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何阻塞，然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

异步 IO 是真 正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器的实现至关重要。

信号驱动 IO(signal driven I/O， SIGIO)

首先我们允许套接口进行信号驱动 I/O,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。当数据报准备好读取时，内核就为该进程产生一个 SIGIO 信号。我们随后既可以在信号处理函数中调用 read 读取数据报，并通知主循环数据已准备好待处理，也可以即通知主循环，让它来读取数据报。无论如何处理 SIGIO 信号，这种模型的优势在于等待数据报到达(第一阶段)期间，进程可以继续执行，不被阻塞。免去了 select 的阻塞与轮询，当有活跃套接字时，由注册的handler 处理。