netty常见的面试问题整理

Netty 是什么？

1. Netty 是一个 基于 NIO 的 client-server(客户端服务器)网络编程框架，使用它可以快速简单地开发网络应用程序。
2. 它极大地简化并优化了 TCP 和 UDP 套接字服务器等网络编程,并且性能以及安全性等很多方面甚至都要更好。
3. 支持多种协议 如 FTP，SMTP，HTTP 以及各种二进制和基于文本的传统协议。

为啥不直接用 NIO 呢?

不用 NIO 主要是因为 NIO 的编程模型复杂而且存在一些 BUG，并且对编程功底要求比较高。
而且，NIO 在面对断连重连、包丢失、粘包等问题时处理过程非常复杂。Netty 的出现正是为了解决这些问题

为什么要用 Netty？

• 统一的 API，支持多种传输类型，阻塞和非阻塞的。
• 简单而强大的线程模型（基于NIO并且实现Reactor主从多线程模型）。
• 自带编解码器解决 TCP 粘包/拆包问题。
• 自带各种协议栈。（支持HTTP，和一些二进制传输协议，很容易自定义协议）
• 真正的无连接数据包套接字支持。（支持使用UDP传输）
• 比直接使用 Java 核心 API 有更高的吞吐量、更低的延迟、更低的资源消耗和更少的内存复制。（使用堆外内存，零复制）
• 安全性不错，有完整的 SSL/TLS 以及 StartTLS 支持。
• 社区活跃
• 成熟稳定，经历了大型项目的使用和考验，而且很多开源项目都使用到了 Netty， 比如我们经常接
  触的 Dubbo、RocketMQ 等等。

Netty 应用场景了解么？

1. 作为 RPC 框架的网络通信工具 ： 我们在分布式系统中，不同服务节点之间经常需要相互调用，这个时候就需要 RPC 框架了。不同服务节点的通信是如何做的呢？可以使用 Netty 来做。比如我调用另外一个节点的方法的话，至少是要让对方知道我调用的是哪个类中的哪个方法以及相关参数吧！
2. 实现一个即时通讯系统 ： 使用 Netty 我们可以实现一个可以聊天类似微信的即时通讯系统，这方面的开源项目还蛮多的，可以自行去 Github 找一找。
3. 实现消息推送系统 ：市面上有很多消息推送系统都是基于 Netty 来做的。
4. 实现一个自己的 HTTP 服务器 ：通过 Netty 我们可以自己实现一个简单的 HTTP 服务器

那些开源项目用到了 Netty?

Dubbo、RocketMQ、Elasticsearch、gRPC 等等都用到了 Netty。

介绍一下 Netty 的核心组件？

• Bytebuf（字节容器）：网络通信最终都是通过字节流进行传输的。 ByteBuf 就是 Netty 提供的一个字节容器，其内部是一个字节数组。
• Bootstrap 和 ServerBootstrap（启动引导类）
• Channel： 是 Netty 对网络操作抽象类。Channel可以理解为是socket连接，在客户端与服务端连接的时候就会建立一个Channel。
• EventLoop（事件循环）：实际就是责监听网络事件并调用事件处理器进行相关 I/O 操作（读写）的处理
• ChannelHandler（消息处理器）：是消息的具体处理器，主要负责处理客户端/服务端接收和发送的数据。
• ChannelPipeline（ChannelHandler 对象链表）：负责管理ChannelHandler 的先后执行顺序。
• ChannelFuture（操作执行结果）：Netty 中所有的 I/O 操作都为异步的，我们不能立刻得到操作是否执行成功

Reactor 线程模型

netty基础那篇博客中包含的三种模型

Netty 服务端和客户端的启动过程了解么？

这块需要看一个代码示例，不然靠背不容易理解。

什么是 TCP 粘包/拆包?有什么解决办法呢？

基于 TCP 发送数据的时候，出现了多个字符串“粘”在了一起或者一个字符串被“拆”开的问题。
基本解决思路：

• 使用固定长度约定每次数据的长度，就可以使用固定长度来传输数据和读取数据。
• 在消息中写入消息的长度，然后在根据长度来读取消息
• 使用特殊字符来间隔消息，读取的时候使用特殊字符拆分消息。

Netty 自带的解码器实现了这几个思路：

• LineBasedFrameDecoder : 发送端发送数据包的时候，每个数据包之间以换行符作为分隔
• DelimiterBasedFrameDecoder : 可以自定义分隔符解码器
• FixedLengthFrameDecoder: 固定长度解码器
• LengthFieldBasedFrameDecoder：基于长度字段的解码器，发送的数据中有数据长度相关的信息

自定义序列化编解码器

• 通常情况下，我们使用 Protostuff、Hessian2、json 序列方式比较多

TCP 长连接和短连接了解么？

我们知道 TCP 在进行读写之前，server 与 client 之间必须提前建立一个连接。建立连接的过程，需要我们常说的三次握手，释放/关闭连接的话需要四次挥手。这个过程是比较消耗网络资源并且有时间延迟的。

短连接说的就是 server 端 与 client 端建立连接之后，读写完成之后就关闭掉连接，如果下一次再要互相发送消息，就要重新连接。短连接的优点很明显，就是管理和实现都比较简单，缺点也很明显，每一次的读写都要建立连接必然会带来大量网络资源的消耗，并且连接的建立也需要耗费时间。

长连接说的就是 client 向 server 双方建立连接之后，即使 client 与 server 完成一次读写，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。长连接的可以省去较多的 TCP 建立和关闭的操作，降低对网络资源的依赖，节约时间。对于频繁请求资源的客户来说，非常适用长连接。

Netty 长连接、心跳机制了解么？

在 TCP 保持长连接的过程中，可能会出现断网等网络异常出现，异常发生的时候， client 与 server 之间如果没有交互的话，它们是无法发现对方已经掉线的。为了解决这个问题, 我们就需要引入 心跳机制。

心跳机制的工作原理是: 在 client 与 server 之间在一定时间内没有数据交互时, 即处于 idle 状态时, 客户端或服务器就会发送一个特殊的数据包给对方, 当接收方收到这个数据报文后, 也立即发送一个特殊的数据报文, 回应发送方, 此即一个 PING-PONG 交互。所以, 当某一端收到心跳消息后, 就知道了对方仍然在线, 这就确保 TCP 连接的有效性.

TCP 实际上自带的就有长连接选项，本身是也有心跳包机制，也就是 TCP 的选项：SO_KEEPALIVE。 但是，TCP 协议层面的长连接灵活性不够。所以，一般情况下我们都是在应用层协议上实现自定义心跳机制的，也就是在 Netty 层面通过编码实现。通过 Netty 实现心跳机制的话，核心类是 IdleStateHandler

零复制

netty基础那篇博客中包含零复制和kafka的零复制对比