netty学习分享 二

操作系统IO模型与实现原理

阻塞IO 模型

netty学习分享 二_第1张图片

应用程序调用一个IO函数,导致应用程序阻塞,等待数据准备好。如果数据没有准备好,一直等待….数据准备好了,从内核拷贝到用户空间,IO函数返回成功指示。

当调用recv()函数时,系统首先查是否有准备好的数据。如果数据没有准备好,那么系统就处于等待状态。当数据准备好后,将数据从系统缓冲区复制到用户空间,然后该函数返回。在套接应用程序中,当调用recv()函数时,未必用户空间就已经存在数据,那么此时recv()函数就会处于等待状态。

非阻塞IO模型

netty学习分享 二_第2张图片

我们把一个SOCKET接口设置为非阻塞就是告诉内核,当所请求的I/O操作无法完成时,不要将进程睡眠,而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好,如果没有准备好,继续测试,直到数据准备好为止。在这个不断测试的过程中,会大量的占用CPU的时间。上述模型绝不被推荐。

把SOCKET设置为非阻塞模式,即通知系统内核:在调用Windows Sockets API时,不要让线程睡眠,而应该让函数立即返回。在返回时,该函数返回一个错误代码。图所示,一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时,内核数据还没有准备好。因此,该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时,数据已经准备好,被复制到应用程序的缓冲区中,recv()函数返回成功指示,应用程序开始处理数据。

IO复用模型

netty学习分享 二_第3张图片

主要是通过select和epoll;对一个IO端口,两次调用,两次返回,比阻塞IO并没有什么优越性;关键是能实现同时对多个IO端口进行监听;

I/O复用模型会用到select、poll、epoll函数,这几个函数也会使进程阻塞,但是和阻塞I/O所不同的的,这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作,多个写操作的I/O函数进行检测,直到有数据可读或可写时,才真正调用I/O操作函数。

当用户进程调用了select,那么整个进程会被block;而同时,kernel会“监视”所有select负责的socket;当任何一个socket中的数据准备好了,select就会返回。这个时候,用户进程再调用read操作,将数据从kernel拷贝到用户进程。
这个图和blocking IO的图其实并没有太大的不同,事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom),而blocking IO只调用了一个系统调用(recvfrom)。但是,用select的优势在于它可以同时处理多个connection。(select/epoll的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接。

信号驱动IO模型

netty学习分享 二_第4张图片

两次调用,两次返回;

允许套接口进行信号驱动I/O,并安装一个信号处理函数,进程继续运行并不阻塞。当数据准备好时,进程会收到一个SIGIO信号,可以在信号处理函数中调用I/O操作函数处理数据。

异步IO模型

netty学习分享 二_第5张图片

简单进程/线程模型

这是一种非常简单的模式,服务器启动后监听端口,阻塞在accept上,当新网络连接建立后,accept返回新连接,服务器启动一个新的进程/线程专门负责这个连接。从性能和伸缩性来说,这种模式是非常糟糕的,原因在于

  • 进程/线程创建和销毁的时间,操作系统创建一个进程/线程显然需要时间,在一个繁忙的服务器上,如果每秒都有大量的连接建立和断开,采用每个进程/线程处理一个客户连接的模式,每个新连接都要创建创建一个进程/线程,当连接断开时,销毁对应的线程/进程。创建和销毁进程/线程的操作消耗了大量的CPU资源。使用链接池和线程池可以缓解这个问题。
  • 内存占用,主要包含两方面;一个是内核数据结构所占用的内存空间,另外一个是Stack所占用的内存。有些应用的调用栈很深,比如Java应用,经常能看到几十上百层的调用栈。
  • 上下文切换的开销;上下文切换时,操作系统的调度器中断当前线程,选择另外一个可运行的线程在CPU上继续运行。调度器需要保存当前线程的现场信息,然后选择一个可运行的线程,再将新线程的状态恢复到寄存器中。保存和恢复现场所需要的时间和CPU型号有关,选择一个可运行的线程则完全是软件操作,Linux 2.6才开始使用常量时间的调度算法。 以上是上下文切换的直接开销。除此之外还有一些间接开销,比如上下文切换导致相关的缓存失效影响程序的性能,但是此类的很多间接开销很难衡量。

有意思的是,这种模式虽然性能极差,但却依然是我们今天最常见到的模式,很多Web程序都是这样的方式在运行。

select/poll

另外一种方式是使用select/poll,在一个线程内处理多个客户连接。select和poll能够监控多个socket文件描述符,当某个文件描述符就绪,select/soll从阻塞状态返回,通知应用程序可以处理用户连接了。使用这种方式,我们只需要一个线程就可以处理大量的连接,避免了多进程/线程的开销。之所以把select和poll放在一起说,原因在于两者非常相似,性能上基本没有区别,唯一的区别在于poll突破了select 1024个文件描述符的限制,然而当文件描述符数量增加时,poll性能急剧下降,因此所谓突破1024个文件描述符实际上毫无意义。select/poll并不完美,依然存在很多问题:

  1. 每次调用select/poll,都要把文件描述符的集合从用户地址空间复制到内核地址空间
  2. select/poll返回后,调用方必须遍历所有的文件描述符,逐一判断文件描述符是否可读/可写。

这两个限制让select/poll完全失去了伸缩性。连接数越多,文件描述符就越多,文件描述符越多,每次调用select/poll所带来的用户空间到内核空间的复制开销越大。最严重的是当报文达到,select/poll返回之后,必须遍历所有的文件描述符。假设现在有1万个连接,其中只一个连接发送了请求,但是select/poll就要把1万个连接全部检查一遍。

epoll

epoll是如何提供一个高性能可伸缩的IO多路复用机制呢?首先,epoll引入了epoll instance这个概念,epoll instance在内核中关联了一组要监听的文件描述符配置:interest list,这样的好处在于,每次要增加一个要监听的文件描述符,不需要把所有的文件描述符都配置一次,然后从用户地址空间复制到内核地址空间,只需要把单个文件描述符复制到内核地址空间,复制开销从O(n)降到了O(1)。

注册完文件描述符后,调用epoll_wait开始等待文件描述符事件。epoll_wait可以只返回已经ready的文件描述符,因此,在epoll_wait返回之后,程序只需要处理真正需要处理的文件描述符,而不用把所有的文件描述符全部遍历一遍。假设在全部N个文件描述符中,只有一个文件描述符Ready,select/poll要执行N次循环,epoll只需要一次。

epoll出现之后,Linux上才真正有了一个可伸缩的IO多路复用机制。基于epoll,能够支撑的网络连接数取决于硬件资源的配置,而不再受限于内核的实现机制。CPU越强,内存越大,能支撑的连接数越多。

select、poll、epoll的区别

1、支持一个进程所能打开的最大连接数

select

单个进程所能打开的最大连接数有FD_SETSIZE宏定义,其大小是32个整数的大小(在32位的机器上,大小就是32*32,同理64位机器上FD_SETSIZE为32*64),可以对进行修改,然后重新编译内核,但是性能可能会受到影响。

poll

poll本质上和select没有区别,但是它没有最大连接数的限制,原因是它是基于链表来存储的

epoll

连接数有上限,但是很大,1G内存的机器上可以打开10万左右的连接,2G内存的机器可以打开20万左右的连接

2、FD剧增后带来的IO效率问题

select

因为每次调用时都会对连接进行线性遍历,所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。

poll

同上

epoll

因为epoll内核中实现是根据每个fd上的callback函数来实现的,只有活跃的socket才会主动调用callback,所以在活跃socket较少的情况下,使用epoll没有前面两者的线性下降的性能问题,但是所有socket都很活跃的情况下,可能会有性能问题。

3、消息传递方式

select

内核需要将消息传递到用户空间,都需要内核拷贝动作

poll

同上

epoll

epoll通过内核和用户空间共享一块内存来实现的。

什么是TCP粘包半包?

假设场景:使用程序,用客户端发送100遍消息

假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到的字节数是不确定的,故可能存在以下4种情况。

(1)服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包;

(2)服务端一次接收到了两个数据包,D1和D2粘合在一起,被称为TCP粘包;

(3)服务端分两次读取到了两个数据包,第一次读取到了完整的D1包和D2包的部分内容,第二次读取到了D2包的剩余内容,这被称为TCP拆包;

(4)服务端分两次读取到了两个数据包,第一次读取到了D1包的部分内容D1_1,第二次读取到了D1包的剩余内容D1_2和D2包的整包。

如果此时服务端TCP接收滑窗非常小,而数据包D1和D2比较大,很有可能会发生第五种可能,即服务端分多次才能将D1和D2包接收完全,期间发生多次拆包。

TCP粘包/半包发生的原因

由于TCP协议本身的机制(面向连接的可靠地协议-三次握手机制)客户端与服务器会维持一个连接(Channel),数据在连接不断开的情况下,可以持续不断地将多个数据包发往服务器,但是如果发送的网络数据包太小,那么他本身会启用Nagle算法(可配置是否启用)对较小的数据包进行合并(基于此,TCP的网络延迟要UDP的高些)然后再发送(超时或者包大小足够)。那么这样的话,服务器在接收到消息(数据流)的时候就无法区分哪些数据包是客户端自己分开发送的,这样产生了粘包;服务器在接收到数据库后,放到缓冲区中,如果消息没有被及时从缓存区取走,下次在取数据的时候可能就会出现一次取出多个数据包的情况,造成粘包现象

UDP:本身作为无连接的不可靠的传输协议(适合频繁发送较小的数据包),他不会对数据包进行合并发送(也就没有Nagle算法之说了),他直接是一端发送什么数据,直接就发出去了,既然他不会对数据合并,每一个数据包都是完整的(数据+UDP头+IP头等等发一次数据封装一次)也就没有粘包一说了。

分包产生的原因就简单的多:可能是IP分片传输导致的,也可能是传输过程中丢失部分包导致出现的半包,还有可能就是一个包可能被分成了两次传输,在取数据的时候,先取到了一部分(还可能与接收的缓冲区大小有关系),总之就是一个数据包被分成了多次接收。

更具体的原因有三个,分别如下。

1. 应用程序写入数据的字节大小大于套接字发送缓冲区的大小

2. 进行MSS大小的TCP分段。MSS是最大报文段长度的缩写。MSS是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。所以MSS并不是TCP报文段的最大长度,而是:MSS=TCP报文段长度-TCP首部长度

3. 以太网的payload大于MTU进行IP分片。MTU指:一种通信协议的某一层上面所能通过的最大数据包大小。如果IP层有一个数据包要传,而且数据的长度比链路层的MTU大,那么IP层就会进行分片,把数据包分成托干片,让每一片都不超过MTU。注意,IP分片可以发生在原始发送端主机上,也可以发生在中间路由器上。

解决粘包半包问题

由于底层的TCP无法理解上层的业务数据,所以在底层是无法保证数据包不被拆分和重组的,这个问题只能通过上层的应用协议栈设计来解决,根据业界的主流协议的解决方案,可以归纳如下。

(1)在包尾增加分割符,比如回车换行符进行分割,例如FTP协议;linebase包和delimiter包下,分别使用LineBasedFrameDecoder和DelimiterBasedFrameDecoder

(2)消息定长,例如每个报文的大小为固定长度200字节,如果不够,空位补空格;fixed包下,使用FixedLengthFrameDecoder

(3)将消息分为消息头和消息体,消息头中包含表示消息总长度(或者消息体长度)的字段,通常设计思路为消息头的第一个字段使用int32来表示消息的总长度,LengthFieldBasedFrameDecoder;。

你可能感兴趣的:(java,netty)