没搞清楚网络I/O模型？那怎么入门Netty

本文是Netty系列笔记第2篇

Netty是网络应用框架，所以从最本质的角度来看，是对网络I/O模型的封装使用。

因此，要深刻理解Netty的高性能，也必须从网络I/O模型说起。

看完本文，可以回答这三个问题：

• 五种I/O模型是什么？核心区别在哪里？

• 同步=阻塞？异步=非阻塞？

• Netty的高性能，是采用了哪种I/O模型？

Unix系统下的五种基本I/O模型大家应该都有所耳闻，分为：

• blocking I/O（同步阻塞IO,BIO）

• nonblocking I/O(同步非阻塞IO，NIO)

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

• signal driven I/O（信号驱动I/O）

• asynchronous I/O（异步I/O，AIO）

每种I/O的特性如何，尤其是同步/非同步、阻塞/非阻塞的区别，其实很多人并不能准确地进行区分。

所以，我们先把最核心的“钥匙”告诉大家，带着这把“钥匙”再来看I/O模型的关键问题，就能手到擒来了。

当一次网络IO发生时，主要涉及到三个对象：

• 发起此次IO操作的Process或者Application

• 系统内核kernel。用户进程无法直接操作I/O设备，必须通过系统内核kernel与I/O设备交互。

• I/O设备，包括网络、磁盘等。本文主要针对网络。

真正的I/O过程，主要分为两个阶段：

• 等待数据准备阶段。

• 数据拷贝阶段。数据准备完毕，从内核kernel拷贝到进程process中

以一个socket上的输入操作为例。

第一步通常涉及等待数据从网络中到达。当所等待分组到达时，它被复制到内核中的某个缓冲区。

第二步就是把数据从内核缓冲区复制到用户态缓冲区。

这里，我们先记住这两个阶段，掌握所有I/O模型区别的“关键钥匙”就在它们身上。

我们一般使用最多的，最基础的I/O模型就是同步阻塞I/O。

典型应用：
阻塞socket、Ja va BIO

我们来解读一下BIO的过程：

• 应用进程向内核发起 I/O 请求，发起调用的线程一直阻塞，等待内核返回结果。

• 数据准备完毕，从内核kernel拷贝到用户态内存（仍旧阻塞），然后kernel返回结果，用户进程process结束阻塞，重新运行。

“关键钥匙”分析：
BIO的特点就是在IO执行的两个阶段都被阻塞了。

所以，我们日常使用BIO模型的时候，提高性能的方式，就是采用多线程。

在一般的场景中，多线程模型下的BIO是成本较低、收益较高的方式。但是，如果在高并发的场景下，过多的创建线程，会严重占据系统资源，降低系统对外界响应效率。

那是不是可以考虑使用“线程池”或者“连接池”呢？

一定程度上可以。“池化”的目的在于减少创建和销毁线程的频率，让空闲的线程重新承担新的执行任务，维持一个合理的线程数量，可以很好的降低系统开销。

但是，“池化”技术只能一定程度上缓解了频繁调用IO接口带来的资源占用。如果“池”上限100，而我们需要1000的IO，那并不能解决性能问题，这是由于BIO模型本身的限制决定的。

所以，需要非阻塞I/O来尝试解决这个问题。

BIO的阻塞问题，让我们考虑使用非阻塞的NIO模型。

典型应用：
socket的非阻塞模式

应用进程向内核发起 I/O 请求后，如果kernel中的数据还没有准备好，不再会“阻塞”等待结果，而是会立即返回。

从用户进程角度讲 ，它发起一个IO操作后，并不需要等待，而是马上就得到了一个结果。

用户进程判断结果是一个error时，它就知道数据还没有准备好，于是它开始发起轮训操作。

直到kernel中的数据准备好了，一旦用户再轮训过来，就马上将数据拷贝到了用户内存，然后返回。

所以，在非阻塞式IO中，用户进程其实是需要不断地主动询问kernel数据准备好了没有。

“关键钥匙”分析：

非阻塞NIO模型相比于BIO的显著差异在于，在“数据等待”阶段，不再“阻塞”，立即返回。

但是在“数据拷贝”阶段，仍然是“阻塞”的。

虽然非阻塞模型避免了“数据等待”阶段的阻塞，但是，采用轮询方式，会导致系统上下文切换开销很大，会大幅度推高CPU 占用率。

因此，单独使用非阻塞 I/O 模型的效率并不高。而且随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。

我们可以看到，轮训的目的只是检测“数据是否已经就绪”，而操作系统提供了更为高效的检测接口，

例如select()多路复用模式，可以一次检测多个连接是否活跃。

多路复用实现了一个线程处理多个 I/O 句柄的操作，有些地方也称这种IO方式为事件驱动IO(event driven IO)。

• 多路 指的是多个数据通道

• 复用 指的是使用一个或多个固定线程来处理每一个 Socket。

典型应用：
select、poll、epoll三种方案
Ja va NIO

多个的进程的IO可以注册到一个复用器（selector）上，然后用一个进程调用select，select会监听所有注册进来的IO。

如果selector所有监听的IO在内核缓冲区都没有可读数据，select调用进程会被阻塞；同时，kernel会“监视”所有select负责的socket，如果任何一个socket中的数据准备好了，select就会返回；

然后select调用进程可以自己或通知另外的进程（注册进程）来再次发起读取IO，然后process将数据从kernel拷贝到用户进程，读取内核中准备好的数据。

可以看到，多个进程注册IO后，只有一个select调用进程被阻塞。

多路复用解决了同步阻塞 I/O 和同步非阻塞 I/O 的问题，是一种非常高效的 I/O 模型。我们可以直观看到，这个模型的好处在于单个process就可以同时处理多个网络连接的IO。

“关键钥匙”分析：

多路复用I/O，select阶段，对于多路socket的“数据等待”阶段而言，是“非阻塞”。

对单个socket的“数据拷贝”阶段，也是“阻塞”。

这里需要特别注意！！！！

其实如果处理的IO数不多的情况下，使用多路复用IO的web server不一定比使用 池化+BIO 的web server性能更好，可能延迟还更大。
考虑极端情况下，只有一个IO，多路复用需要 2 次系统调用（select + recvfrom），而BIO只需要 1 次系统调用（recvfrom）。

所以，多路复用IO的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

在使用信号驱动 I/O 时，当数据准备就绪后，内核通过发送一个 SIGIO 信号通知应用进程，应用进程就可以开始读取数据了。

信号驱动I/O模型的最大特点，就是不需要process进程不断轮训内核是否已经准备就绪。

“关键钥匙”分析：

信号驱动I/O在"数据等待"阶段“非阻塞”。

当数据准备完成后，信号通知process，process开始“数据拷贝”阶段，这里仍然是“阻塞”的。

信号驱动 I/O 有几个缺陷：
1）在大量 IO 操作时可能会因为信号队列溢出导致没法通知。

2）信号驱动 I/O 尽管对于处理 UDP 套接字来说有用，信号通知意味着到达一个数据报，或者返回一个异步错误。
但是，对于 TCP 而言，信号驱动的 I/O 方式不太好用。因为导致信号通知的情况有非常多种，每一个来进行判别会消耗很大资源。

所以信号驱动I/O模式用得非常少。

而且尤其需要注意，在“数据拷贝”阶段，它仍然是“阻塞”的。

真正的异步I/O，就是AIO。

典型应用：
JA VA7 AIO、高性能服务器

根据前面四个模型的分析，相信大家已经能明显看懂这个模型的运行方式了。

用户进程发起I/O请求后，便可以立刻去做其他事情。而内核在收到请求后，会立即返回，不会对用户进程造成任何阻塞。接着，内核会等待数据准备完成，再将数据拷贝到用户内存。当这一切完成后，内核会向用户进程发送一个信号，告知其I/O操作已完成。

AIO最重要的一点是从内核缓冲区拷贝数据到用户态缓冲区的过程也是由系统异步完成，应用进程只需要在指定的数组中引用数据即可。

AIO 与信号驱动 I/O 的主要区别：
信号驱动 I/O 由内核通知何时可以开始一个 I/O 操作，而异步 I/O 由内核通知 I/O 操作何时已经完成。

“关键钥匙”分析：

"数据等待"阶段，非阻塞

"数据拷贝”阶段，非阻塞

AIO是真正的异步模型，它不会对请求进程产生任何的阻塞。

日常使用过程中，我们往往把 同步I/O 等同于 阻塞I/O，异步I/O 等同于 非阻塞I/O。
实际上，严格意义来说，这两组概念还是有很大的区别的。

阻塞与非阻塞的区别比较明显，也很好理解。

结合I/O模型来说，阻塞I/O会一直block对应的进程直到操作完成，而非阻塞 IO在kernel 在"等待数据准备"阶段会立刻返回。

所以我们一般认为，阻塞I/O只有BIO，另外四个模型都是属于非阻塞I/O。

先来看看 同步I/O 和 异步I/O 的定义是什么，根据POSIX的定义：

• 同步I/O : A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;

• 异步I/O : An asynchronous I/O operation does not cause the requesting process to be blocked;

两者的区别就在于同步I/O做 "IO operation”的时候会将process阻塞。

那么按照这个定义，我们看看前面每个模型的“关键钥匙”分析部分，可以明显看到，BIO，NIO，IO多路复用、信号驱动IO 四种模型都属于 同步IO。

为何这么说呢？原因在于，它们处于IO的第二阶段，也就是真正执行“数据拷贝”的阶段时，统统都是“阻塞”状态。就拿NIO来说吧，当执行recvfrom这个系统调用的时候，要是kernel的数据尚未准备就绪，此时进程是不会被block的。然而，一旦kernel中的数据准备妥当，recvfrom就会把数据从kernel拷贝到用户内存中，这个时候进程就会被block住啦。

同理，信号驱动IO，当内核中IO数据就绪时以SIGIO信号通知请求进程，请求进程再把数据从内核读入到用户空间，这一步也是阻塞的。

所以，真正的异步I/O只有一个，就是AIO。当进程发起IO操作之后，就直接返回再也不管了，直到kernel发送一个信号，告诉进程说IO完成。在这整个过程中，进程完全没有被阻塞。如定义所说，不会因为IO操作阻塞。

Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 JDK NIO 框架的多路复用器 Selector。

一个多路复用器 Selector 可以同时轮询多个 Channel，采用 epoll 模式后，只需要一个线程负责 Selector 的轮询，就可以接入成千上万的客户端。

更具体的实现方式和模型，我们下一期再展开说明。

对了，一定有同学想问，Netty为什么不采用AIO呢？

因为 AIO 的目的是希望 I/O 线程不阻塞主线程，属于异步 I/O，由内核通知 I/O 操作何时完成。AIO 适用于连接数多的且需要长时间连接的场景。

对于AIO来说，目前操作系统支持程度有限且实现起来复杂。

Netty也尝试过AIO，但是效果不是很理想，最终废弃了。

参考书目：
《UNIX Network Programming(Volume1,3rd)》

如果有任何疑问或者建议，欢迎写留言或者微信和我联系哦～

往期热门笔记合集推荐：

• HBase原理与实战笔记合集

• MySQL实战笔记合集

• Canal/Otter源码与实战笔记合集

• Ja va实战技巧笔记合集

扫描下方二维码可以关注我哦～

本文分享自微信公众号 - 阿丸笔记（aone_note）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。