网络IO模型

前言

  什么是IO？也就是输入输出。
  网络 IO，会涉及到两个系统对象，一个是用户空间调用 IO 的进程或者线程，另一个是内核空间的内核系统，比如发生 IO 操作 read 时，它会经历两个阶段：
  1. 等待数据准备就绪
  2. 将数据从内核拷贝到进程或者线程中。
  因为在以上两个阶段上各有不同的情况，所以出现了多种网络 IO 模型

  无论是用户空间读取数据还是内核读取数据，内核都需要准备数据拷贝到内存再被读。
  五种网络IO模型分别是阻塞式IO、非阻塞式IO、多路复用IO、信号驱动IO和异步IO。

阻塞式IO

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

  当用户进程调用了 read 这个系统调用，kernel(内核) 就开始了 IO 的第一个阶段：准备数据。对于网络 io 来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的数据包），这个时候 kernel 就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当 kernel一直等到数据准备好了，它就会将数据从 kernel 中拷贝到用户内存，然后 kernel 返回结果，用户进程才解除 block 的状态，重新运行起来。
  所以，阻塞IO 的特点就是在 IO 执行的两个阶段（等待数据和拷贝数据两个阶段）都被阻塞了。除非特别指定，几乎所有的 IO 接口 ( 包括 socket 接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。
  一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。当调用accept()函数抽取一个新的连接时，就需要交给另一个进程或者线程来完成后续操作了。(accept()函数会返回一个新的socket，后续的读和写都是对这个新的socket进行操作的)。
  这样似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。
  很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。
  对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

非阻塞式IO

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

  从图中可以看出，当用户进程发出 read 操作时，如果 kernel 中的数据还没有准备好，那么它并不会阻塞用户进程，而是立刻返回一个 error。从用户进程角度讲 ，它发起一个read 操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个 error时，它就知道数据还没有准备好，于是它可以再次发送 read 操作。一旦 kernel 中的数据准备好了，并且又再次收到了用户进程的 system call，那么它马上就将数据拷贝到了用户内存，然后返回，所以，在非阻塞式 IO 中，用户进程其实是需要不断的主动询问 kernel数据准备好了没有。
  在非阻塞状态下，recv() 接口在被调用后立即返回，返回值代表了不同的含义。

* recv() 返回值大于 0，表示接受数据完毕，返回值即是接受到的字节数；
* recv() 返回 0，表示连接已经正常断开；
* recv() 返回 -1，且 errno 等于 EAGAIN，表示 recv 操作还没执行完成；
* recv() 返回 -1，且 errno 不等于 EAGAIN，表示 recv 操作遇到系统错误 errno。

  服务器线程需要通过循环调用 recv()接口，可以在单个线程内实现对所有连接的数据接收工作。但是不推荐。因为，循环调用 recv()将大幅度推高 CPU 占用率。 recv()更多的是起到检测“操作是否完成”的作用，实际操作系统提供了更为高效的检测“操作是否完成“作用的接口，例如 select()多路复用模式，可以一次检测多个连接是否活跃。

多路复用IO

  多路复用也就是我们平时用的select还有epoll等，有些地方也称这种 IO 方式为事件驱动。我们都知道，select/epoll 的好处就在于单个 process 就可以同时处理多个网络连接的 IO。它的基本原理就是 select/epoll 这个 function会不断的轮询所负责的所有 socket，当某个 socket 有数据到达了，就通知用户进程。它的流
程如图：

  当用户进程调用了 select，那么整个进程会被阻塞，而同时，kernel 会“监视”所 有 select 负责的 socket，当任何一个 socket 中的数据准备好了，select 就会返回。这个时候用户进程再调用 read 操作，将数据从 kernel 拷贝到用户进程。
  使用 select 以后最大的优势是用户可以在一个线程内同时处理多个socket 的 IO 请求。用户可以注册多个 socket，然后不断地调用 select 读取被激活的 socket，即可达到在同一个线程内同时处理多个 IO 请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。（如果处理的连接数不是很高的话，使用select/epoll 的 web server 不一定比使用 multi-threading + blocking IO 的 web server 性能更好，可能延迟还更大select/epoll 的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。）
  select()接口可以同时对多个句柄(可以理解为accept返回的新的socket也就是文件描述符)进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。(客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。)
  这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。
  相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。但是select()接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select()接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如linux提供了epoll，BSD提供了kqueue，Solaris提供了/dev/poll，等等。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。
  幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号(signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。

信号驱动IO

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

异步驱动IO

  Linux 下的 asynchronous IO 用在磁盘 IO 读写操作，不用于网络 IO，从内核 2.6 版本才开始引入。Linux 内核从 2.6 开始，也引入了支持异步响应的 IO 操作，如 aio_read, aio_write，这就是异步 IO。

  用户进程发起 read 操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个 asynchronous read 之后，首先它会立刻返回，所以不会对用户进程产生任何 block。然后，kernel 会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel 会给用户进程发送一个 signal，告诉它 read 操作完成了。异步 IO 是真正非阻塞的，它不会对请求进程产生任何的阻塞，因此对高并发的网络服务器实现至关重要。

  non-blocking IO 在执行 read 这个系统调用的时候，如果 kernel 的数据没有准备好，这时候不会 block 进程。但是当 kernel 中数据准备好的时候，read 会将数据从 kernel 拷贝到用户内存中，这个时候进程是被阻塞了，在这段时间内进程是被block的。而 asynchronous IO 则不一样，当进程发起 IO 操作之后，就直接返回再也不理睬了，直到 kernel 发送一个信号，告诉进程说 IO 完成。在这整个过程中,进程完全没有被 block。在non-blocking IO 中，虽然进程大部分时间都不会被 block，但是它仍然要求进程去主动的 check，并且当数据准备完成以后，也需要进程主动的再次调用 recvfrom 来将数据拷贝到用户内存。而 asynchronous IO 则完全不同。它就像是用户进程将整个 IO 操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查 IO 操作的状态，也不需要主动的去拷贝数据。

  同步和异步最主要的区别在于数据从内核区复制到内存这个阶段，同步是阻塞在这个阶段的，需要read之后再把这个数据拷贝到内存再取到自己地方，而异步很畅通直接就到内存上等着信号处理函数来处理。

参考

  本文参考自五种网络IO模型