Netty源码分析—Linux网络IO模型简介
Linux网络IO模型简介
Linux的内核将所有外部设备都看做成一个文件来操作,对一个文件的读写操作也会调用到内核提供的系统命令,返回一个fd(file discriptor 文件描述符)。而对一个socket的读写也会有相应的描述符,称为socket fd(socket描述符),描述符就是一个数字,它指向内核中的一个结构体(文件路径,数据区等一些属性),根据UNIX网络编程对I/O模型的分类,UNIX提供了5中I/O模型,分别如下。
阻塞IO模型
在内核将数据准备好之前,系统调用会一直等待所有的套接字Socket传来数据,默认的是阻塞的方式。
Java中socket.read()方式最终会调用底层操作系统的recfrom方法,os会判断来自网络的数据是否准备好,当数据报准备好了之后,os就会将数据从内核空间拷贝到用户空间(因为我们的用户程序只能获取用户空间的内存,无法直接获取内核空间的内存)。拷贝完之后socket.read()就会解除阻塞,并得到网络数据的结果。
BIO中的阻塞,就得阻塞在这2个地方
- OS等待数据报通过网络发送过来,如果建立连接之后数据一一直没有发送过来,就会白白的浪费线程的资源
- 将数据从内核空间拷贝到用户空间
在这两个时候,我们的线程会一直阻塞,啥事情都干不了
非阻塞IO模型
每次应用程序询问内核是否有数据报准备好,当有数据报准备好的时候,就进行拷贝数据报的操作,从内核拷贝到用户空间,和拷贝完成范围的这段时间,应用进程是阻塞的,但在没有数据报准备好的时候,并不会阻塞程序,内核直接返回为准备好的信号,等待应用进程的下一次询问。但是轮询的方式对于CPU来说是较大的浪费,一般只有在特定的场景下才会使用。
从图中可以看到,非阻塞IO的recvfrom()调用会立即得到一个返回结果,这个结果是关于数据报是否准备皓的,我们可以根据返回的结果继续执行不同的逻辑。而阻塞IO的recvfrom调用,如果无数据报准备好,那么就一定会被阻塞住。虽然非阻塞IO比阻塞IO少了一段阻塞的过程,但是事实上非阻塞IO也是低效的,因为我们不得不使用轮的方式去询问OS: 我的数据准备好没有?
BIO不会在拷贝数据之前阻塞,但是会在将数据从内核空间拷贝到用户空间的时候阻塞,一定要注意这个地方,Non - Blocking还是会阻塞的。
IO复用模型
Linux提供select/poll。进程通过将一个或者多个fd传递给select系统调用,阻塞发生在select/poll操作之后。select/poll可以帮我们监视多个fd是否处于就绪状态,他们顺序扫描fd是否就绪,但是支持的fd的数量有限,因为它的使用也受到了一些制约。
Linux还提供了一个epoll的系统调用,epoll使用基于时间驱动的方式代替顺序扫描,因此性能更高,当有fd就绪的时候,立即回调函数rollback。
信号驱动IO模型
首先开启 套接口 信号驱动IO功能,并通过系统调用sigaction执行一个信号处理函数(此系统调用立即返回,进程继续工作,他是非阻塞的)。当数据准备就绪的时候,就为该进程生成一个SIGIO信号,通过信号回调通知应用程序recvfrom来读取数据,并通知主循环函数来处理数据
异步IO模型
告知内核启动某个操作,并让内核在整个操作完成之后(包括将数据从内核复制到用户自己的缓冲区)通知我们。这种模型与信号驱动模型的区别就是,信号驱动IO由内核通知我们何时可以开始一个IO操作。异步IO模型由内核通知我们IO操作何时完成。
从这无种IO模型的结构可以看出 阻塞程度:阻塞IO > 非阻塞IO > io多路复用 > 信号驱动IO > 异步IO ,效率也是由低到高的。
IO多路复用技术
Java NIO的核心类库,多路复用器Selector就是基于epoll的多路复用技术的实现
在IO编程过程中,当需要同时处理多个客户端接入请求的时候,可以利用多线程或者IO多路复用技术处理,IO多路复用技术通过吧多个IO阻塞复用到一个select的阻塞上,从而使得系统在单线程的情况下也可以同时处理多个客户端请求,IO多路复用的最大优势是系统开销小,系统不需要创建额外的进程或者线程,也不需要维护这些线程和线程的运行,降低了系统的维护工作量,节省了系统资源,IO多路复用的主要应用场景如下:
服务器需要同时处理多个监听状态或者多个连接状态的套接字
服务器需要同时处理多个网络协议中的套接字
目前支持IO多路复用的系统调用有select,pselect,poll,epoll,在Linux网络编程的过程中,很长一段时间都是用select做轮询和网络事件通知,然而select的一些固有缺陷导致了它的应用受到了很大的限制,最终linux选择了epoll.epoll与select的原理比较类似,为了克服select的缺点,epoll做了很多改进。
1.支持一个进程打开的socket描述符fd不受限制(仅仅受限于操作系统的最大文件句柄数)
2.IO效率不会随着FD数目的增加而线性下降
3.epoll的API更加简单
值得说明的是,用来克服select/epoll缺点的方法不只有epoll,epoll只是Linux的一种实现方案。
select / epoll的区别
IO多路复用的机制
多路复用是同步非阻塞IO,他是利用单独的线程(内核级别)统一检测所有的socket,一旦有某个Socket有了IO数据,则启动相应的Application处理,在Select和poll中轮询socket句柄的方式来实现检测socket是否有IO数据到达,这种方式是由开销的,epoll则改进了这种方式,底层调用notify机制,即Reactor方式来检测,Java NIO也是采用这种机制,这里需要注意,其实多路复用还是有阻塞的(这个阻塞并非定义上的阻塞,这里是指Socket无IO数据的时候还是被wait,此外当使用select函数copy IO数据进入Application buffer ,application还是会被阻塞的)
select / epoll的区别
select
1.每次调用select,都要把fd集合从用户态拷贝到内核态,这个开销在fd很多的时候会很大
2.同时每次调用select都需要在内核遍历传递进来所有fd,这个开销在fd很多的时候也很大
3.select支持的文件描述符太小了,默认是1024poll
4.它没有最大连接数的限制,原因是他是居于链表来存储的,但是同样有一个缺点:大量的fd的数组被整体复制与用户态和内核态地址空间之间,而不管这样的复制是不是有意义epoll
5. epoll 会为每个fd指定一个回调函数,当设备就绪的时候,唤醒等待队列上的等待者,就会调用这个回调函数
epoll所支持的FD上限是最大可以打开文件的数目