从BIO到NIO再到Netty

1、BIO

Java BIO就是传统的 socket编程。

BIO(blocking I/O) ： 同步阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，可以通过线程池机制改善(实现多个客户连接服务器)。

一个简单的socket通信示例：基于TCP协议的Socket通信

2、NIO

Java NIO 全称java non-blocking IO 或(New IO)，是同步非阻塞的。

1. NIO 三大核心：Channel(通道)，Buffer(缓冲区), Selector(选择器)
2. NIO是面向缓冲区编程的。数据读取到一个缓冲区中，需要时可在缓冲区中前后移动，这就增加了处理过程中的灵活性，使用它可以提供非阻塞式的高伸缩性网络
3. Java NIO非阻塞模式，可设置为非阻塞模式。

2.1、缓存区Buffer

缓冲区（Buffer）：缓冲区本质上是一个可以读写数据的内存块，可以理解成是一个数组，该对象提供了一组方法，可以更轻松地使用内存块，缓冲区对象内置了一些机制，能够跟踪和记录缓冲区的状态变化情况。Channel 提供从网络读取数据的渠道，但是读取或写入的数据都必须经由 Buffer。

2.2、通道Channel

NIO中的所有IO都是从 Channel（通道） 开始的：

1. 通道可以读也可以写
2. 通道可以异步读写
3. 通道总是基于缓冲区Buffer来读写

2.3、选择器Selector

可以用一个线程，处理多个的客户端连接，就会使用到NIO的Selector(选择器). Selector 能够检测多个注册的服务端通道上是否有事件发生，如果有事件发生，便获取事件然后针对每个事件进行相应的处理。这样就可以只用一个单线程去管理多个通道，也就是管理多个连接和请求。

2.3、基于NIO的socket通信示例

示例：NIO ServerSocketChannel配合使用Selector简单案例

3、Netty

3.1 Netty简介

Netty 是由 JBOSS 提供的一个 Java 开源框架。Netty 提供异步的、基于事件驱动的网络应用程序框架，用以快速开发高性能、高可靠性的网络 IO 程序。 Netty 是一个基于 NIO 的网络编程框架，使用Netty 可以帮助你快速、简单的开发出一 个网络应用，相当于简化和流程化了 NIO 的开发过程。 作为当前最流行的 NIO 框架，Netty 在互联网领域、大数据分布式计算领域、游戏行业、 通信行业等获得了广泛的应用，知名的 Elasticsearch 、Dubbo 框架内部都采用了 Netty。

具备如下有点：

1. 设计优雅，提供阻塞和非阻塞的 Socket；提供灵活可拓展的事件模型；提供高度可定制的线程模
   型。
2. 具备更高的性能和更大的吞吐量，使用零拷贝技术最小化不必要的内存复制，减少资源的消耗。
3. 提供安全传输特性。
4. 支持多种主流协议；预置多种编解码功能，支持用户开发私有协议。

3.2 线程模型

• 传统阻塞 I/O 服务模型
• Reactor 模型
  根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现
  • 单 Reactor 单线程
  • 单 Reactor 多线程
  • 主从 Reactor 多线程

3.2.1 传统阻塞 I/O 服务模型

采用阻塞 IO 模式获取输入的数据, 每个连接都需要独立的线程完成数据的输入 , 业务处理和数据返回工作.

存在的问题：

1. 当并发数很大，就会创建大量的线程，占用很大系统资源
2. 连接创建后，如果当前线程暂时没有数据可读，该线程会阻塞在 read 操作，造成线程资源浪费

3.2.2 Reactor 模型

Reactor 模式，通过一个或多个输入同时传递给服务处理器的模式 , 服务器端程序处理传入的多个请求,并将它们同步分派到相应的处理线程， 因此 Reactor 模式也叫 Dispatcher模式. Reactor 模式使用IO 复用监听事件, 收到事件后，分发给某个线程(进程), 这点就是网络服务器高并发处理关键.

3.2.2.1 单 Reactor 单线程

优点:

1. 模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点:

1. 性能问题: 只有一个线程，无法完全发挥多核 CPU 的性能。
2. 可靠性问题: 线程意外终止或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

3.2.2.2 单 Reactor多线程

优点:

1. 可以充分的利用多核 cpu 的处理能力

缺点:

1. 多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行， 在高并发场景容易出现性能瓶颈

3.2.2.3 主从 Reactor 多线程

优点:

1. MainReactor 线程与 SubReactor 线程的数据交互简单职责明确，MainReactor 线程只需要接收新连接，SubReactor 线程完成后续的业务处理
2. MainReactor 线程与 SubReactor 线程的数据交互简单， MainReactor 线程只需要把新连接传给 SubReactor 线程，SubReactor 线程无需返回数据
3. 多个 SubReactor 线程能够应对更高的并发请求

缺点:

1. 这种模式的缺点是编程复杂度较高。但是由于其优点明显，在许多项目中被广泛使用，包括Nginx、Memcached、Netty 等。这种模式也被叫做服务器的 1+M+N 线程模式，即使用该模式开发的服务器包含一个（或多个，1 只是表示相对较少）连接建立线程+M 个 IO 线程+N 个业务处理线程。这是业界成熟的服务器程序设计模式。

3.3、简单案例

基于Netty的简易群聊

3.4、Netty中粘包与拆包

3.4.1、粘包与拆包介绍

粘包和拆包是TCP网络编程中不可避免的，无论是服务端还是客户端，当我们读取或者发送消息的时候，都需要考虑TCP底层的粘包/拆包机制。

TCP是个“流”协议，所谓流，就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
粘包和拆包有大概如下几种情况：

1. 服务端分两次读取到了两个独立的数据包，没有粘包和拆包；
2. 服务端一次接收到了两个数据包，被称为TCP粘包；
3. 如果数据包比较大, 服务端分两次读取到了两个数据包，这被称为TCP拆包
4. 如果两次发送的数据包都比较大，服务端可能分多次才能接收完成数据，期间会产生粘包与拆包

TCP粘包和拆包产生的原因：
数据从发送方到接收方需要经过操作系统的缓冲区，而造成粘包和拆包的主要原因就在这个缓冲区上。粘包可以理解为缓冲区数据堆积，导致多个请求数据粘在一起，而拆包可以理解为发送的数据大于缓冲区，进行拆分处理。

3.4.2、粘包和拆包的解决方案

• 固定长度的拆包器 FixedLengthFrameDecoder，每个应用层数据包的都拆分成都是固定长度的大小
• 行拆包器 LineBasedFrameDecoder，每个应用层数据包，都以换行符作为分隔符，进行分割拆分
• 分隔符拆包器 DelimiterBasedFrameDecoder，每个应用层数据包，都通过自定义的分隔符，进行分割拆分
• 基于数据包长度的拆包器 LengthFieldBasedFrameDecoder，将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度

代码实现：

• LineBasedFrameDecoder解码器

ch.pipeline().addLast(new LineBasedFrameDecoder(2048));

ctx.writeAndFlush(Unpooled.copiedBuffer("你好呀,我是Netty客户端"+i+"\n", CharsetUtil.UTF_8));

• DelimiterBasedFrameDecoder解码器

ByteBuf byteBuf = Unpooled.copiedBuffer("$".getBytes(StandardCharsets.UTF_8));
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(2048, byteBuf));

ctx.writeAndFlush(Unpooled.copiedBuffer("你好呀,我是Netty客户端"+i+"$", CharsetUtil.UTF_8));