ChannelPipeline

• 基于Netty的网路应用程序中根据业务需求会使用Netty已经提供的Channelhandler
  或者自行开发ChannelHandler，这些ChannelHandler都放在ChannelPipeline中统一
  管理，事件就会在ChannelPipeline中流动，并被其中一个或者多个ChannelHandler处理
  

• ChannelPipeline提供了ChannelHandler链的容器，并定义了在该链上传播入站(也就是从网络到业务处理)
  和出站(也就是从业务处理到网络)，各种事件流的API，代码中的ChannelHandler都是放在ChannelPipeline中的。

• 使得事件流经ChannelPipeline是ChannelHandler的工作，它们是在应用程序的初始化或者引导阶段被安装的。
  这些ChannelHandler对象接收事件、执行它们所实现的处理逻辑，并将数据传递给链中的下一个ChannelHandler,
  而且Channelhandler对象也完全可以拦截事件不让事件继续传递。它们的执行顺序是由它们被添加的顺序所决定的。

• ChannelPipeline上的方法。
  既然ChannelPipeline以双向链表的形式进行维护管理Handler，自然也提供了对应的方法在ChannelPipeline中
  增加或者删除、替换handler.
  addFist、addBefore、addAfter、addLast将一个ChannelHandler添加到ChannelPipeline中。
  remove将一个ChannelHandler从ChannelPipeline中移除
  replace将ChannelPipeline中的一个ChannelHandler替换为另一个ChannelHandler
  get通过类型或者名称返回ChannelHandler
  context返回和ChannelHandler绑定的ChannelHandlerContext
  names返回ChannelPipeline中所有ChannelHandler的名称
  ChannelPipeline的API公开了用于调用入站和出站操作的附加方法

ChannelHandler

• ChannelPipeline中的ChannelHandler.
  入站和出站ChannelHandler被安装到同一个ChannelPipeline中，ChannelPipeline以双向链表的形式进行维护管理。如上图，在网络上传递的数据，要求加密，但是加密后密文比较大，需要压缩后再传输，而且按照业务要求，需要检查报文中携带的用户信息是否合法，于是图中实现了，解压(入)Handler、压缩(出)Handler、解密(入)Handler、加密(出)Handler
  授权(入)Handler.
• 如果一个消息或者任何其他入站事件被读取，那么它会从ChannelPipeline的头部开始流动，但是只被处理入站事件的Handler处理，也就是解压(入)Handler、解密(入)Handler、授权(入)Handler，最终，数据将会到达ChannelPipeline的尾端，届时，所有的处理就都结束了
• 数据的出站运动(即正在被写的数据)在概念上也是一样的。在这种情况下，数据将从链的尾端开始流动，但是制备处理出站的Handler处理，也就是加密(出)Handler、压缩(出)Handler，直到它到达链的头部为止。在这之后，出站数据将会到达网络传输层，也就是Socket

![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/1a8a8f18927140ff867fe4725a77e99d.png

• Netty能区分入站事件的Handler和出站的Handler，并确保数据只会在具有相同定向的两个ChannelHandler之间传递在编写Netty应用程序时要注意，分属出站和入站不同的Handler，在业务没有特殊要求的情况下是无所谓顺序的，比如压缩(出)Handler可以放在解压(入)Handler和解密(入)Handler中间，也可以放在解密(入)Handler和授权之间

• 而同属一个方向的Handler则是有顺序的，因为上一个Handler处理的结果往往是下一个Handler的要求的输入。比如入站处理，对于收到的数据，只有先解压才能得到密文，才能解密，只有解密后才能拿到明文中的用户信息进行授权检查，所以解压-解密-授权这个，三个入站Handler的顺序就不能乱