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

原创
2021/01/18 09:00
阅读数 6.8K


本文是Netty系列笔记第2篇

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

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


看完本文,可以回答这三个问题:

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

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

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

1.掌握五种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模型区别的“关键钥匙”就在它们身上。

2.五种I/O模型详解

2.1 同步阻塞I/O, BIO

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

典型应用:
阻塞socket、Java BIO


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

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

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

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

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

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

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

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

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

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

2.2 同步非阻塞I/O, NIO

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

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


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

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

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

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

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

“关键钥匙”分析:

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

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

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

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

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

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

2.3 多路复用IO

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

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

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

典型应用:
select、poll、epoll三种方案
Java 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的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接。

2.4 信号驱动I/O

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


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

“关键钥匙”分析:

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

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

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

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

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

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

2.5 异步I/O,AIO

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

典型应用:
JAVA7 AIO、高性能服务器


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

用户进程发起I/O请求后,立刻就可以开始去做其它的事。而另一方面,从kernel的角度,当它收到一个请求之后,首先它会立刻返回,所以不会对用户进程产生任何block。然后,kernel会等待数据准备完成,然后将数据拷贝到用户内存,当这一切都完成之后,kernel会给用户进程发送一个signal,告诉它I/O操作完成了。

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

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

“关键钥匙”分析:

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

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

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

3. 同步=阻塞?异步=非阻塞?

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

3.1 阻塞I/O 与 非阻塞I/O

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

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

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

3.2 同步I/O 与 异步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操作阻塞。

4. Netty采用了哪种I/O模型呢?

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)》


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


往期热门笔记合集推荐:


原创:阿丸笔记(微信公众号:aone_note),欢迎 分享,转载请保留出处。

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

                                                                              觉得不错,就点个  再看 吧👇



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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
12 收藏
0
分享
返回顶部
顶部