网络-常见JAVA面试知识点

一种是正常的字符串输出。

一种是多个字符串“粘”在了一起，我们定义这种 ByteBuf 为粘包。

一种是一个字符串被“拆”开，形成一个破碎的包，我们定义这种 ByteBuf 为半包。

应用层面使用了Netty，但是对于操作系统来说，只认TCP协议，尽管我们的应用层是按照 ByteBuf 为 单位来发送数据，server按照Bytebuf读取，但是到了底层操作系统仍然是按照字节流发送数据，因此，数据到了服务端，也是按照字节流的方式读入，然后到了 Netty 应用层面，重新拼装成 ByteBuf，而这里的 ByteBuf 与客户端按顺序发送的 ByteBuf 可能是不对等的。因此，我们需要在客户端根据自定义协议来组装我们应用层的数据包，然后在服务端根据我们的应用层的协议来组装数据包，这个过程通常在服务端称为拆包，而在客户端称为粘包

拆包和粘包是相对的，一端粘了包，另外一端就需要将粘过的包拆开，发送端将三个数据包粘成两个 TCP 数据包发送到接收端，接收端就需要根据应用协议将两个数据包重新组装成三个数据包

在没有 Netty 的情况下，用户如果自己需要拆包，基本原理就是不断从 TCP 缓冲区中读取数据，每次读取完都需要判断是否是一个完整的数据包 如果当前读取的数据不足以拼接成一个完整的业务数据包，那就保留该数据，继续从 TCP 缓冲区中读取，直到得到一个完整的数据包。 如果当前读到的数据加上已经读取的数据足够拼接成一个数据包，那就将已经读取的数据拼接上本次读取的数据，构成一个完整的业务数据包传递到业务逻辑，多余的数据仍然保留，以便和下次读到的数据尝试拼接

Netty中，已经造好了许多类型的拆包器，我们直接用就好

1. 数据从磁盘读取到内核的read buffer

2. 数据从内核缓冲区拷贝到用户缓冲区

3. 数据从用户缓冲区拷贝到内核的socket buffer

4. 数据从内核的socket buffer拷贝到网卡接口的缓冲区

第二步和第三步是没有必要的，通过java的FileChannel.transferTo方法，可以避免上面两次多余的拷贝

1. ByteBuf

2. ByteBufHolder

select

poll

epoll

本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间

在 select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一 个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait() 时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制，这正是epoll的魅力所在。)

用一个线程把Accept，读写操作，请求处理的逻辑全干了。如果什么事都没得做，它也不会死循环，它会将线程休眠起来，直到下一个事件来了再继续干活，这样的一个线程称之为NIO线程

Channel：Channel保存了socket连接的有关信息，以及ChannelPipeLine（串起ChannelHandlerContext）/Unsafe（实现底层传输）/EventLoop（对应一个IO线程）/SelectionKey（如果为NIO模式，标识该Channel此时的连接读写事件）等有效信息，NIO服务端负责响应连接的是NioServerSocketChannel，客户端为NioSocketChannel

Buffer：缓冲区，用于和NIO Channel交互，从Channel中读取数据到Buffer，从Buffer将数据写入到Channel

Selector：Selector是Java NIO提供的多路复用器，负责配合操作系统的select/epoll操作将就绪的IO事件分离出来，落地为SelectionKey，我们可以将SelectionKey看做Reactor模式中的资源 实现一个线程就能监听多个Channel（Channel需先register到Selector）的读写等状态，然后触发ChannelPipeLine的fireChannelRead操作（串行ChannelHandlerContext持有的ChannelHandler）/底层Channel的数据写入（数据来源于Buffer）

EventLoop/EventLoopGroup，EventLoopGroup其实就是一个EventLoop线程组，netty中通常有多个EventLoop同时工作，每个EventLoop维护着一个Selector实例（类似单线程Reactor工作）。如果没有显式指定，默认每个EvenLoopGroup中的线程数为可用的CPU内核数*2 通常每个netty服务端有两个EventLoopGroup：bossGroup和workerGroup bossGroup用作Acceptor线程池，负责处理客户端的连接请求，通常一个服务端口对应一个EventLoop线程，根据实际需要配置线程组的线程数量。Acceptor线程通过不断轮询Selector上的Accept事件，将accept的SocketChannel交给另外一个EventLoop线程组。如果系统只有一个服务端端口需要监听，则建议 bossGroup 线程组线程数设置为 1 workerGroup会根据线程组的顺序next一个可用的EventLoop将这个SocketChannel注册到其维护的Selector上，并处理其后续的I/O的事件，是真正负责 I/O 读写操作的线程组，通过 ServerBootstrap 的 group 方法进行设置，用于后续的 Channel 绑定

ChannelPipleline，每个SocketChannel都有一个Pipleline实例，而每个Pipleline中维护了一个ChannelHandler链表队列。Pipleline和ChannelHandler的关系类似servlet和filter过滤器的作用。EventLoop从Selector中分离出就绪的channel以后，会将它传递的消息传输到Pipleline中，通过ChannelHandler处理链进行层层处理，用户可以在Handler中添加自己的业务逻辑。 ChannelPipleline中本身维护着两个不可见的HeadHandler和TailHandler，head靠近网络层，tail靠近用户。netty中有两类事件类型，inbound和outbound。inbound可以理解为从网络数据外部流向内部，如读取消息；outbound为网络数据从内部流向外部，如写消息。Pipleline会根据事件的类型， 自上而下或自下而上调用事件相关联的ChannelHandler对消息进行处理。如读取消息的时候会依次执行HeadHandler、ChannelHandler1...ChannelHandlerN、TailHandler

1、创建ServerBootStrap实例

2、设置并绑定Reactor线程池：EventLoopGroup，EventLoop就是处理所有注册到本线程的Selector上面的Channel

3、设置并绑定服务端的channel

4、5、创建处理网络事件的ChannelPipeline和handler，网络时间以流的形式在其中流转，handler完成多数的功能定制：比如编解码 SSl安全认证

6、绑定并启动监听端口

7、当轮询到准备就绪的channel后，由Reactor线程：NioEventLoop执行pipline中的方法，最终调度并执行channelHandler 

分支主题