IO是Input/Output的缩写。Linix网络编程中有五种IO模型:
首先了解下同步\异步、阻塞\非阻塞的区别
同步和异步是针对的是用户进程与内核的交互方式。
阻塞和非阻塞是针对进程在访问数据的时候,根据IO操作的就绪状态来采取的不同方式。
注意,这里办业务的时候,还是需要我们也参与其中的,这和异步是完全不同的,因此同步\异步、阻塞\非阻塞,是完全不同的两个概念,二者不要混淆
应用程序向操作系统发出IO请求:应用程序发出IO请求给操作系统内核,操作系统内核需要等待数据就绪,这里的数据可能来自别的应用程序或者网络。一般来说,一个IO分为两个阶段:
在Linux系统中,操作系统的IO操作是一个系统调用recvfrom(),即一个系统调用recvfrom包含两步,等待数据就绪和拷贝数据。
在此种方式下,用户进程在发起一个IO操作以后,必须等待IO操作的完成,只有当IO操作完成之后,用户进程才能运行。JAVA传统的BIO属于此种方式。(jdk1.4以前)
img
JAVA NIO(jdk1.4以后引入)
在此种方式下,用户进程发起一个IO操作以后边可返回做其它事情,但是用户进程需要时不时的询问IO操作是否就绪,这就要求用户进程不停的去询问,从而引入不必要的CPU资源浪费。JAVA的NIO就属于同步非阻塞IO
img
redis、nginx、netty;reactor模式
select,epoll;有时也称这种IO方式为事件驱动IO。
select/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。它的基本原理就是select/epoll这个函数会不断的轮询所负责的所有socket,当某个socket有数据到达了,就通知用户进程.
多路复用中,通过select函数,可以同时监听多个IO请求的内核操作,只要有任意一个IO的内核操作就绪,都可以通知select函数返回,再进行系统调用recvfrom()完成IO操作。
这个过程应用程序就可以同时监听多个IO请求,这比起基于多线程阻塞式IO要先进得多,因为服务器只需要少数线程就可以进行大量的客户端通信。
img
在unix系统中,应用程序发起IO请求时,可以给IO请求注册一个信号函数,请求立即返回,操作系统底层则处于等待状态(等待数据就绪),直到数据就绪,然后通过信号通知主调程序,主调程序才去调用系统函数recvfrom()完成IO操作。
信号驱动也是一种非阻塞式的IO模型,比起上面的非阻塞式IO模型,信号驱动式IO模型不需要轮询检查底层IO数据是否就绪,而是被动接收信号,然后再调用recvfrom执行IO操作。
比起多路复用IO模型来说,信号驱动IO模型针对的是一个IO的完成过程, 而多路复用IO模型针对的是多个IO同时进行时候的场景。
img
在此种模式下,整个IO操作(包括等待数据就绪,复制数据到应用程序工作空间)全都交给操作系统完成。数据就绪后操作系统将数据拷贝进应用程序运行空间之后,操作系统再通知应用程序,这个过程中应用程序不需要阻塞
img
如果你在烧水:
img
阻塞、非阻塞、多路IO复用,都是同步IO,异步必定是非阻塞的,所以不存在异步阻塞和异步非阻塞的说法。真正的异步IO需要CPU的深度参与。换句话说,只有用户线程在操作IO的时候根本不去考虑IO的执行,全部都交给CPU去完成,而只需要等待一个完成信号的时候,才是真正的异步IO。所以,fork子线程去轮询、死循环或者使用select、poll、epoll,都不是异步
I/O多路复用就通过一种机制,可以监视多个描述符,一旦某个描述符就绪(一般是读就绪或者写就绪),能够通知程序进行相应的读写操作。但select,poll,epoll本质上都是同步I/O,因为他们都需要在读写事件就绪后自己负责进行读写,也就是说这个读写过程是阻塞的,而异步I/O则无需自己负责进行读写,异步I/O的实现会负责把数据从内核拷贝到用户空间。
多路复用如下面所示:指的其实是在单个线程通过记录跟踪每一个Sock(I/O流)的状态来同时管理多个I/O流
个人的一些理解:
如上图做一个简单的比喻:左边有若干取水器,需要到右边水龙头进行取水操作,每个取水器和水龙头是一一对应的关系,但是中间段是断开的,需要将水管连接上(一个水管相当于一个IO线程),才可以进行取水操作了(注意水龙头不是一直都有水流的,只有当取水器连接上才会触发输水操作)。下面依次对不同的IO模型进行讲解:
1、传统阻塞BIO:每个取水器和水龙头之间都需要一个连接水管,水管连接上触发取水操作,水龙头才会输水。这样有几个取水器就需要几个水管,另外水管接上之后并不会马上就能取到水,之间一直处于阻塞状态,当取水器过多时没有足够的水管来进行连接
线程池模式:水池中存在10根水管,每当取水器有取水请求时,就去水池中拿一根水管使用,水管会根据取水器编号接到相应的水龙头上。当取水器请求过多时,需要不停的进行水管切换。
2、多路复用IO:
select/poll:全部的取水器均复用一根水管,没有多余的水管可用,所有的取水器均接到这一根水管上。(区别是select模式仅支持1024个取水器的接入,而poll不限制取水器个数)。当水龙头有水流过来时,水管会提前收到通知,但不知道是哪个水龙头。则此时水管需要每个水龙头都接上试一下,当发现其中一个水龙头有水流时则将其运到与其相连的取水器中。
epoll部的取水器均复用一根水管,没有多余的水管可用,所有的取水器均接到这一根水管上。(与select/poll区别是:当水龙头有水流过来时,水管就已经知道是哪根水龙头在运水了,直接将水管接上相应的水龙头即可)。
非阻塞忙轮询式
while true
{
for i in fd[]
{
if i has data
read until unavailable
}
}
把所有流从头到尾查询一遍,就可以处理多个流了,但这样做很不好,因为如果所有的流都没有I/O事件,白白浪费CPU时间片
select:服务端一直在轮询、监听如果有客户端链接上来就创建一个连接放到数组A中,继续轮询这个数组,如果在轮询的过程中有客户端发生IO事件就去处理;select只能监视1024个连接(一个进程只能创建1024个文件);而且存在线程安全问题;
while true
{
select(fds[]) //阻塞这里,直到有一个流有I/O事件时,才往下执行,数组的大小只有1024
for i in fds[]
{
if i has data
read until unavailable
}
}
它仅仅知道了,有I/O事件发生了,却并不知道是哪那几个流(可能有一个,多个,甚至全部),我们只能无差别轮询所有流,找出能读出数据,或者写入数据的流,对他们进行操作。所以select具有O(n)的无差别轮询复杂度,同时处理的流越多,无差别轮询时间就越长
poll:在select做了许多修复,比如不限制监测的连接数;但是也有线程安全问题;
poll本质上和select没有区别,它将用户传入的数组拷贝到内核空间,然后查询每个fd对应的设备状态, 但是它没有最大连接数的限制,原因是它是基于链表来存储的.
epoll:也是监测IO事件,但是如果发生IO事件,它会告诉你是哪个连接发生了事件,就不用再轮询访问。而且它是线程安全的,但是只有linux平台支持;
while true
{
active_fds[] = epoll_wait(epollfd)
for i in active_fds[]
{
read or write till
}
}
epoll可以理解为event poll,不同于忙轮询和无差别轮询,epoll会把哪个流发生了怎样的I/O事件通知我们。所以我们说epoll实际上是事件驱动(每个事件关联上fd)的,此时我们对这些流的操作都是有意义的。(复杂度降低到了O(1))