概念

1．从IO到NIO到Netty经历

https://www.jianshu.com/p/a4e03835921a

2．netty是什么

异步事件驱动程序,用于快速开发高性能服务端和客户端
封装了jdk底层BIO和NIO模型,提供高度可用的API,Netty底层IO模型随意切换，而这一切只需要做微小的改动，改改参数，Netty可以直接从NIO模型变身为IO模型

自带编码解码器解决拆包粘包问题,用户只用关心业务逻辑
Netty底层对线程，selector做了很多细小的优化，精心设计的reactor线程模型做到非常高效的并发处理
自带协议栈,无需用户关心(什么是协议栈,协议栈就是我自带了很多种协议,netty都帮你实现了,对于使用者来说我们不用关心这些事情.)

使用JDK自带的NIO需要了解太多的概念，编程复杂，一不小心bug横飞
Netty解决了JDK的很多包括空轮询在内的bug
自带各种协议栈让你处理任何一种通用协议都几乎不用亲自动手
Netty社区活跃，遇到问题随时邮件列表或者issue
Netty已经历各大rpc框架，消息中间件，分布式通信中间件线上的广泛验证，健壮性无比强大

3．4种IO对比

4．选择Netty理由

曾经有两个项目组同时用到了NIO编程技术,一个项目组选择了自己开发NIO服务端,直接使用JDK原生的API,结果两个多月过去了,他们的NIO服务端始终无法稳定,问题频出.由于NIO通信是它们的核心组件之一,因此项目的进度受到了严重的影响,
另一个项目组直接使用Netty作为NIO服务端,业务的定制开发工作量非常小,测试表明,功能和性能都完全达标,项目组几乎没有在NIO服务端上花费额外的时间和精力,项目进展也非常顺利.
这两个项目组的不同遭遇告诉我们:开发出高质量的NIO程序并不是一个简单的事情,除去NIO固有的复杂性和BUG不谈,作为一个NIO服务端,需要能够处理网络的闪断,客户端的重复接入,客户端的安全认证,消息的编解码,半包读写等情况.如果你没有足够的NIO编程经验积累,一个NIO框架的稳定旺旺需要半年甚至更长的时间,更为糟糕的是,一旦在生产环境中发生问题,往往会导致跨节点的服务调用中断,严重的可能会导致整个集群环境都不可用,需要重启服务器,这种非正常停机会带来巨大的损失.
从可维护角度看,由于NIO采用了异步非阻塞编程模型,而且是一个IO线程处理多条链路,它的调试和跟踪非常麻烦,特别是生产环境中的问题,我们无法进行有效的调试和跟踪,往往只能靠一些日志来辅助分析,定位难度很大.

5．Netty优点

1. API使用简单,开发门槛低
   2. 功能强大,预置了多种编解码功能,支持多种主流协议
   3. 定制能力强,可以通过ChannelHandler对通信框架进行灵活地扩展
   4. 性能高,通过与其他业界主流的NIO框架对比,Netty的综合性能最优;
   5. 成熟,稳重,Netty修复了已经发现的所有的JDK NIO BUG ,业务开发人员不需要再为NIO的bug而烦恼
   6. 社区活跃,版本迭代周期短,发现的bug可以被及时修复,同时,更多的新功能会加入,
   

   6．不选择Java原生NIO编程的原因

2. NIO的类库和API繁杂,使用麻烦,你需要熟练掌握Selector,ServerSocketChannel,SocketChannel,ByteBuffer等.
   2. 需要具备其他的额外技能做铺垫,例如熟悉Java多线程编程,这是因为NIO编程涉及到Reactor模式,你必须对多线程和网络编程非常熟悉,才能编写出高质量的NIO程序.
   3. 可靠性能力补齐,工作量和难度都非常大,例如客户端面临断连重连,网络闪退,半包读写,失败缓存,网络拥塞和异常码流的处理等问题,NIO编程的特点是功能开发相对容易,但是可靠性能力补齐的工作量和难度都非常大.
   4. JDK NIO的BUG 例如 epoll bug ,它会导致Selector空轮询,最终导致CPU 100%
   
   

   7．Netty运用场景

   
   高性能的,异步事件驱动非阻塞式NIO框架,它提供了对外TPC,UDP和文件传输支持,最关键的是通过Future-Listener机制
   Future-Listener就是一种异步监听回调机制,这种机制保证了延迟度几乎没有,只要你完成执行完之后状态立马返回,比如说我们的微博,你发送信息过去,它没有点开看,那么状态基本上是未读,当你发送对象点开微博的时候立马就返回已读信息.
   
   1分布式进程通信
   例如: hadoop、dubbo、akka等具有分布式功能的框架，底层RPC通信都是基于netty实现的，这些框架使用的版本通常都还在用netty3.x
   
   2、游戏服务器开发
   最新的游戏服务器有部分公司可能已经开始采用netty4.x 或 netty5.x
   
   

   8．为什么不用Netty5

   
   
   1. netty5 中使用了 ForkJoinPool，增加了代码的复杂度，但是对性能的改善却不明显
   2. 多个分支的代码同步工作量很大
   3. 作者觉得当下还不到发布一个新版本的时候
   4. 在发布版本之前，还有更多问题需要调查一下，比如是否应该废弃 exceptionCaught， 是否暴露EventExecutorChooser等等。
   
   

   9．为什么Netty使用NIO而不是AIO？

   
   
   Netty不看重Windows上的使用，在Linux系统上，AIO的底层实现仍使用EPOLL，没有很好实现AIO，因此在性能上没有明显的优势，而且被JDK封装了一层不容易深度优化。
   AIO还有个缺点是接收数据需要预先分配缓存, 而不是NIO那种需要接收时才需要分配缓存, 所以对连接数量非常大但流量小的情况, 内存浪费很多。
   据说Linux上AIO不够成熟，处理回调结果速度跟不上处理需求，有点像外卖员太少，顾客太多，供不应求，造成处理速度有瓶颈。
   作者原话：
   Not faster than NIO (epoll) on unix systems (which is true)
   
   
   
   
   

    Channel

   Channel相当于网络通讯的Socket,Netty把Socket抽象成了Channel,Channel是一个接口.
   
   Channel 是 NIO 基本的结构。它代表了一个用于连接到实体如硬件设备、文件、网络套接字或程序组件,能够执行一个或多个不同的 I/O 操作（例如读或写）的开放连接。
   现在,把 Channel 想象成一个可以“打开”或“关闭”,“连接”或“断开”和作为传入和传出数据的运输工具。
   
   
   
   一个Channel里面有一个ChannelPipeline,一个ChannelPipeline包含两个以上Context.
   
   基本的I/O 操作（bind()、connect()、read()和write()）依赖于底层网络传输所提供的原语。在基于Java 的网络编程中，其基本的构造是类Socket。Netty 的Channel 接口所提供的API，被用于所有的I/O 操作。大大地降低了直接使用Socket 类的复杂性。此外，Channel 也是拥有许多预定义的、专门化实现的广泛类层次结构的根。
   由于Channel 是独一无二的，所以为了保证顺序将Channel 声明为java.lang.Comparable 的一个子接口。因此，如果两个不同的Channel 实例都返回了相同的散列码，那么AbstractChannel 中的compareTo()方法的实现将会抛出一个Error。
   
   Channel 的生命周期状态
   ChannelUnregistered ：Channel 已经被创建，但还未注册到EventLoop
   ChannelRegistered ：Channel 已经被注册到了EventLoop
   ChannelActive ：Channel 处于活动状态（已经连接到它的远程节点）。它现在可以接收和发送数据了
   ChannelInactive ：Channel 没有连接到远程节点
   当这些状态发生改变时，将会生成对应的事件。这些事件将会被转发给ChannelPipeline 中的ChannelHandler，其可以随后对它们做出响应。
   
   最重要Channel 的方法
   eventLoop： 返回分配给Channel 的EventLoop
   pipeline： 返回分配给Channel 的ChannelPipeline
   isActive： 如果Channel 是活动的，则返回true。活动的意义可能依赖于底层的传输。例如，一个Socket 传输一旦连接到了远程节点便是活动的，而一个Datagram 传输一旦被打开便是活动的。
   localAddress： 返回本地的SokcetAddress
   remoteAddress： 返回远程的SocketAddress
   write： 将数据写到远程节点。这个数据将被传递给ChannelPipeline，并且排队直到它被冲刷
   flush： 将之前已写的数据冲刷到底层传输，如一个Socket
   writeAndFlush： 一个简便的方法，等同于调用write()并接着调用flush()
   

    EventLoop和EventLoopGroup

   
   
   回想一下我们在NIO中是如何处理我们关心的事件的？在一个while循环中select出事件，然后依次处理每种事件。我们可以把它称为事件循环，这就是EventLoop。interface io.netty.channel. EventLoop 定义了Netty 的核心抽象，用于处理网络连接的生命周期中所发生的各种事件而已。
   
   EventLoop可以理解成为只有一个线程的线程池,线程池除了有线程以外,还会有阻塞队列,EventLoop继承了ScheduleExecutorService,所以还可以执行定时任务.
   一个任务或者一个事件被提交给了EventLoop去处理的时候,不一定会马上处理,有可能会马上处理,有可能会进入内部的阻塞队列,当我们创建channel的时候, 每一个EventLoop要处理一个channel,也就是所谓的socket,所以第一步要把channel注册到EventLoop上面去.
   
   EventLoopGroup 是一个线程池组,每当一个channel注册进来的时候,EventLoopGroup会从它内部重写取出一个EventLoop专门处理channel.
   
   一个channel的所有生命周期是由在注册的时候所指定的EventLoop来管,不会说中间替换的情况.不会说跨线程处理的情况,所以就不需要考虑线程安全问题.
   
   一个EventLoop在它的生命周期内只和一个Thread来绑定,一个EventLoop可以处理很多Channel,但是一个Channel只会对应一个EventLoop(由这个EventLoop来处理.)
   
   
   io.netty.util.concurrent 包构建在JDK 的java.util.concurrent 包上。而，io.netty.channel 包中的类，为了与Channel 的事件进行交互，扩展了这些接口/类。一个EventLoop 将由一个永远都不会改变的Thread 驱动，同时任务（Runnable 或者Callable）可以直接提交给EventLoop 实现，以立即执行或者调度执行。
   
   根据配置和可用核心的不同，可能会创建多个EventLoop 实例用以优化资源的使用，并且单个EventLoop 可能会被指派用于服务多个Channel。
   Netty的EventLoop在继承了ScheduledExecutorService的同时，只定义了一个方法，parent()。在Netty 4 中，所有的I/O操作和事件都由已经被分配给了EventLoop的那个Thread来处理。

   任务调度

   偶尔，你将需要调度一个任务以便稍后（延迟）执行或者周期性地执行。例如，你可能想要注册一个在客户端已经连接了5 分钟之后触发的任务。一个常见的用例是，发送心跳消息到远程节点，以检查连接是否仍然还活着。如果没有响应，你便知道可以关闭该Channel 了。

   线程管理

   在内部，当提交任务到如果（当前）调用线程正是支撑EventLoop 的线程，那么所提交的代码块将会被（直接）执行。否则，EventLoop 将调度该任务以便稍后执行，并将它放入到内部队列中。当EventLoop下次处理它的事件时，它会执行队列中的那些任务/事件。
   

   线程的分配

   服务于Channel 的I/O 和事件的EventLoop 则包含在EventLoopGroup 中。
   异步传输实现只使用了少量的EventLoop（以及和它们相关联的Thread），而且在当前的线程模型中，它们可能会被多个Channel 所共享。这使得可以通过尽可能少量的Thread 来支撑大量的Channel，而不是每个Channel 分配一个Thread。EventLoopGroup 负责为每个新创建的Channel 分配一个EventLoop。在当前实现中，使用顺序循环（round-robin）的方式进行分配以获取一个均衡的分布，并且相同的EventLoop可能会被分配给多个Channel。
   一旦一个Channel 被分配给一个EventLoop，它将在它的整个生命周期中都使用这个EventLoop（以及相关联的Thread）。请牢记这一点，因为它可以使你从担忧你的ChannelHandler 实现中的线程安全和同步问题中解脱出来。
   
   需要注意，EventLoop 的分配方式对ThreadLocal 的使用的影响。因为一个EventLoop 通常会被用于支撑多个Channel，所以对于所有相关联的Channel 来说，ThreadLocal 都将是一样的。这使得它对于实现状态追踪等功能来说是个糟糕的选择。然而，在一些无状态的上下文中，它仍然可以被用于在多个Channel 之间共享一些重度的或者代价昂贵的对象，甚至是事件。
   

   2．ChannelFuture 接口

   
   Netty 中所有的I/O 操作都是异步的。因为一个操作可能不会立即返回，所以我们需要一种用于在之后的某个时间点确定其结果的方法。为此，Netty 提供了ChannelFuture 接口，其addListener()方法注册了一个ChannelFutureListener，以便在某个操作完成时（无论是否成功）得到通知。
   可以将ChannelFuture 看作是将来要执行的操作的结果的占位符。它究竟什么时候被执行则可能取决于若干的因素，因此不可能准确地预测，但是可以肯定的是它将会被执行。
   
   异步通知
   
   ChannelFuture的作用是用来保存Channel异步操作的结果。
   我们知道，在Netty中所有的I/O操作都是异步的。这意味着任何的I/O调用都将立即返回，而不保证这些被请求的I/O操作在调用结束的时候已经完成。取而代之地，你会得到一个返回的ChannelFuture实例，这个实例将给你一些关于I/O操作结果或者状态的信息。
   对于一个ChannelFuture可能已经完成，也可能未完成。当一个I/O操作开始的时候，一个新的future对象就会被创建。在开始的时候，新的future是未完成的状态－－它既非成功、失败，也非被取消，因为I/O操作还没有结束。如果I/O操作以成功、失败或者被取消中的任何一种状态结束了，那么这个future将会被标记为已完成，并包含更多详细的信息（例如：失败的原因）。请注意，即使是失败和被取消的状态，也是属于已完成的状态。
   每个 Netty 的 outbound I/O 操作都会返回一个 ChannelFuture;这样就不会阻塞。这就是 Netty 所谓的“自底向上的异步和事件驱动”。
   下面这张图来自于官方文档，用于说明各种状态的关系：
   
   各种各样的方法被提供，用来检查I/O操作是否已完成、等待完成，并寻回I/O操作的结果。 它的 addListener 方法注册了一个 ChannelFutureListener ，当操作完成时，可以被通知（不管成功与否）。
   
   sync()
   等待ChannelFuture直到完成为止,如果失败就抛异常,抛出失败的原因
   

    ChannelHandler、ChannelPipeline、ChannelHandlerContext

1．ChannelHandler 接口

从应用程序开发人员的角度来看，Netty 的主要组件是ChannelHandler,程序员的主要工作就是写各种ChannelHandler和应用各种ChannelHandler.它充当了所有处理入站和出站数据的应用程序逻辑的容器。

ChannelHandler 的方法是由网络事件触发的。事实上，ChannelHandler 可专门用于几乎任何类型的动作，例如将数据从一种格式转换为另外一种格式(比如网络传输的是0101串儿,我们这个0101串儿转化成JavaBean的话,我们就要自己定义实现一个ChannelHandler,我们在这个ChannelHandler就可以给0101串儿转化成JavaBean)，例如各种编解码，或者处理转换过程中所抛出的异常。

举例来说，ChannelInboundHandler 是一个你将会经常实现的子接口。这种类型的ChannelHandler 接收入站事件和数据，这些数据随后将会被你的应用程序的业务逻辑所处理。当你要给连接的客户端发送响应时，也可以从ChannelInboundHandler 直接冲刷数据然后输出到对端。应用程序的业务逻辑通常实现在一个或者多个ChannelInboundHandler 中。
这种类型的ChannelHandler 接收入站事件和数据，这些数据随后将会被应用程序的业务逻辑所处理。

ChannelHandler 的生命周期

一个ChannelHandler作用主要是放到ChannelPipeline里面去,在ChannelHandler被添加到ChannelPipeline 中或者被从ChannelPipeline 中移除时都会触发相应的事件。

这些方法中的每一个都接受一个ChannelHandlerContext 参数。

handlerAdded 当把ChannelHandler 添加到ChannelPipeline 中时被调用
handlerRemoved 当从ChannelPipeline 中移除ChannelHandler 时被调用
exceptionCaught 当处理过程中在ChannelPipeline 中发生异常的时候调用

Netty 定义了下面两个重要的ChannelHandler 子接口：
ChannelInboundHandler——当有数据被接收的时候,这个handler就会被调用
ChannelOutboundHandler——当有数据流出的时候,这个handler就会被调用

ChannelHandler的适配器

有一些适配器类可以将编写自定义的ChannelHandler 所需要的工作降到最低限度，因为它们提供了定义在对应接口中的所有方法的默认实现。因为你有时会忽略那些不感兴趣的事件，所以Netty提供了抽象基类ChannelInboundHandlerAdapter 和ChannelOutboundHandlerAdapter。
你可以使用ChannelInboundHandlerAdapter 和ChannelOutboundHandlerAdapter类作为自己的ChannelHandler 的起始点。这两个适配器分别提供了ChannelInboundHandler和ChannelOutboundHandler 的基本实现。通过扩展抽象类ChannelHandlerAdapter，它们获得了它们共同的超接口ChannelHandler 的方法。
ChannelHandlerAdapter 还提供了实用方法isSharable()。如果其对应的实现被标注为Sharable，那么这个方法将返回true，表示它可以被添加到多个ChannelPipeline。

SimpleChannelHandler

处理消息接收和写

messageReceived接收消息
hannelConnected新连接，通常用来检测IP是否是黑名单
channelDisconnected链接关闭，可以再用户断线的时候清楚用户的缓存数据等

channelDisconnected与channelClosed的区别？

channelDisconnected只有在连接建立后断开才会调用
channelClosed无论连接是否成功都会调用关闭资源

| package com.server;

import org.jboss.netty.channel.ChannelHandlerContext;
import org.jboss.netty.channel.ChannelStateEvent;
import org.jboss.netty.channel.ExceptionEvent;
import org.jboss.netty.channel.MessageEvent;
import org.jboss.netty.channel.SimpleChannelHandler;
/**

• 消息接受处理类
  

• @author -琴兽-
  
  /
  public class HelloHandler extends SimpleChannelHandler {
  
  /**
  

  • 接收消息
    /
    @Override
    public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
    /网络传输不是直接传字节流的,netty是用ChannelBuffer封装了起来/
    // ChannelBuffer message = (ChannelBuffer) e.getMessage();
    // String s = new String(message.array());//转成数组再转成String 才能打印
    // System.out.println(s);
    
    String s = (String) e.getMessage();
    System.out.println(s);
    
    
    
    /向客户端回写数据/
    // ChannelBuffer channelBuffer = ChannelBuffers.copiedBuffer(“hi”.getBytes());
    // ctx.getChannel().write(channelBuffer);
    
    
    //回写数据
    ctx.getChannel().write(“hi”);
    super.messageReceived(ctx, e);
    }
    
    /*
    
  • 捕获异常
    /
    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) throws Exception {
    System.out.println(“exceptionCaught”);
    super.exceptionCaught(ctx, e);
    }
    
    /*
    
  • 新连接
    
  • 使用方法:
    
  • 服务器有些客人是用正常的服务端访问,有些人是写服务器,比如我们程序员,不停的写
    
  • 如果一秒钟发送的消息很多,就会使得我服务器压力变大,就会搞崩服务器,
    
    
    /
    @Override
    public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {
    System.out.println(“channelConnected”);
    super.channelConnected(ctx, e);
    }
    
    /*
    
  • 必须是链接已经建立，关闭通道的时候才会触发
    
  • 这里可以检测玩家下线清空 玩家缓存.
    /
    @Override
    public void channelDisconnected(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {
    System.out.println(“channelDisconnected”);
    super.channelDisconnected(ctx, e);
    }
    
    /*
    
  • channel关闭的时候触发
    /
    @Override
    public void channelClosed(ChannelHandlerContext ctx, ChannelStateEvent e) throws Exception {
    System.out.println(“channelClosed”);
    *super.channelClosed(ctx, e);
    }
    } | | —- |

  
  
  

  ChannelInboundHandler 接口

  处理入站数据以及各种状态变化
  
  下面列出了接口 ChannelInboundHandler 的生命周期方法。这些方法将会在数据被接收时或者与其对应的Channel 状态发生改变时被调用。正如我们前面所提到的，这些方法和Channel 的生命周期密切相关。
  
  channelRegistered 当Channel 已经注册到它的EventLoop 并且能够处理I/O 时被调用
  channelUnregistered 当Channel 从它的EventLoop 注销并且无法处理任何I/O 时被调用
  channelActive 当Channel 处于活动状态时被调用；Channel 已经连接/绑定并且已经就绪
  channelInactive 当Channel 离开活动状态并且不再连接它的远程节点时被调用
  channelReadComplete 当Channel上的一个读操作完成时被调用
  channelRead 当从Channel 读取数据时被调用
  ChannelWritabilityChanged
  当Channel 的可写状态发生改变时被调用。可以通过调用Channel 的isWritable()方法来检测Channel 的可写性。与可写性相关的阈值可以通过Channel.config().setWriteHighWaterMark()和Channel.config().setWriteLowWaterMark()方法来设置
  userEventTriggered 当ChannelnboundHandler.fireUserEventTriggered()方法被调用时被调用。
  
  

  SimpleChannelInboundHandler

| package com;

import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;
import io.netty.handler.codec.http.websocketx.TextWebSocketFrame;

public class WebSocketHandler extends SimpleChannelInboundHandler {
/*

* 覆盖了 channelRead0() 事件处理方法。
* 每当从服务端读到客户端写入信息时，
* 其中如果你使用的是 Netty 5.x 版本时，
* 需要把 channelRead0() 重命名为messageReceived()<br />
*/<br />

@Override
protected void channelRead0(ChannelHandlerContext ctx, TextWebSocketFrame msg) throws Exception {
System.out.println(“收到消息: “ + msg.text());
ctx.channel().writeAndFlush(new TextWebSocketFrame(“我已经收到了 “));

}

/*

* 覆盖channelActive 方法在channel被启用的时候触发（在建立连接的时候）
* 覆盖了 channelActive() 事件处理方法。服务端监听到客户端活动
*/<br />

public void channelActive(ChannelHandlerContext ctx) throws Exception {

   **_
  _super**.channelActive(ctx);<br />

}

/*

* 每当从服务端收到新的客户端连接时,触发这个方法
*/<br />

@Override
public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
System.out.println(“handlerAdded!!!”);
}

/*

* (non-Javadoc)<br />
* .覆盖了 handlerRemoved() 事件处理方法。
* 每当从服务端收到客户端断开时
*/<br />

@Override
public void handlerRemoved(ChannelHandlerContext ctx) throws Exception {
System.out.println(“handlerRemoved!!!”);
}

/*

* exceptionCaught() 事件处理方法是当出现 Throwable 对象才会被调用，
* 即当 Netty 由于 IO 错误或者处理器在处理事件时抛出的异常时。
* 在大部分情况下，捕获的异常应该被记录下来并且把关联的 channel 给关闭掉。
* 然而这个方法的处理方式会在遇到不同异常的情况下有不同的实现，
* 比如你可能想在关闭连接之前发送一个错误码的响应消息。
*/<br />

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
throws Exception {

  _super**.exceptionCaught(ctx, cause);<br />

}

} | | —- |

ChannelOutboundHandler 接口

处理出站数据并且允许拦截所有的操作。

出站操作和数据将由ChannelOutboundHandler 处理。它的方法将被Channel、Channel-
Pipeline 以及ChannelHandlerContext 调用。
所有由ChannelOutboundHandler 本身所定义的方法：
bind(ChannelHandlerContext,SocketAddress,ChannelPromise)
当请求将Channel 绑定到本地地址时被调用
connect(ChannelHandlerContext,SocketAddress,SocketAddress,ChannelPromise)
当请求将Channel 连接到远程节点时被调用
disconnect(ChannelHandlerContext,ChannelPromise)
当请求将Channel 从远程节点断开时被调用
close(ChannelHandlerContext,ChannelPromise) 当请求关闭Channel 时被调用
deregister(ChannelHandlerContext,ChannelPromise)
当请求将Channel 从它的EventLoop 注销时被调用
read(ChannelHandlerContext) 当请求从Channel 读取更多的数据时被调用
flush(ChannelHandlerContext) 当请求通过Channel 将入队数据冲刷到远程节点时被调用
write(ChannelHandlerContext,Object,ChannelPromise) 当请求通过Channel 将数据写到远程节点时被调用

ChannelInboundHandlerAdapter和SimpleChannelInboundHandler的使用区分

一般用netty来发送和接收数据都会继承SimpleChannelInboundHandler和ChannelInboundHandlerAdapter这两个抽象类，那么这两个到底有什么区别呢？
在客户端的业务Handler继承的是SimpleChannelInboundHandler，而在服务器端继承的是ChannelInboundHandlerAdapter。
最主要的区别就是SimpleChannelInboundHandler在接收到数据后会自动释放掉数据占用的Bytebuffer资源(自动调用Bytebuffer.release()),也就是说,消息被读取后,会自动释放资源.
而为何服务器端(ChannelInboundHandlerAdapter)不能用呢，因为我们想让服务器把客户端请求的数据发送回去，而服务器端有可能在channelRead方法返回前还没有写完数据，因此不能让它自动release(释放数据)。

2．ChannelPipeline 接口

ChannelPipeline 是ChannelHandler的一个所谓的容器,如果ChannelHandler有多个的话,就需要给多个ChannelHandler串起来放到ChannelPipeline里面去,ChannelHandler就像香肠一样一个一个的挂在ChannelPipeline里面.
所有的ChannelHandler不管是出站还是入站,都需要挂在到ChannelPipeline上面,既然是挂载上面,肯定需要顺序,你可以把ChannelPipeline理解为所谓的链表.
addFirst、addBefore、addAfter、addLast 方法都可以改变顺序,我们挂载ChannelHandler顺序很重要,需要注意顺序,并且非常重要.
假如我们做个网络程序,第一需要所谓的加解密,第二个需要格式化的转换, 我网络上的数据过来了,A Handler负责解密,B Handler负责格式的转换,这样的话肯定是B Handle(格式转换)排在前面,因为网络传输的时候数据都是0101串儿的加密后的密文,转化成0101的明文,再进行格式转换成JavaBean.

当有一个数据从网络上通过socket传递到我们的channel,channel在调用我们ChannelHandler里面的ChannelPipeline的时候,入站的数据和事件都又入站处理器进行处理,Netty在运行过程中会通过你实现的接口来判定在挂载的时候ChannelHandler到底是入站处理器还是出站处理器.

虽然ChannelInboundHandle 和ChannelOutboundHandle 都扩展自ChannelHandler，但是Netty 能区分ChannelInboundHandler实现和ChannelOutboundHandler 实现，并确保数据只会在具有相同定向类型的两个ChannelHandler 之间传递。



ChannelPipeline上的方法
addFirst、addBefore、addAfter、addLast
将一个ChannelHandler 添加到ChannelPipeline 中
remove 将一个ChannelHandler 从ChannelPipeline 中移除
replace 将ChannelPipeline 中的一个ChannelHandler 替换为另一个ChannelHandler
get 通过类型或者名称返回ChannelHandler
context 返回和ChannelHandler 绑定的ChannelHandlerContext
names 返回ChannelPipeline 中所有ChannelHandler 的名称
ChannelPipeline 的API 公开了用于调用入站和出站操作的附加方法。

3．ChannelHandlerContext

当我们把ChannelHandler和ChannelPipeline进行绑定(ChannelHandler添加到ChannelPipeline)的时候,Netty会为我们ChannelHandler自动加一个,ChannelHandlerContext上下文,这一个ChannelHandlerContext代表它们之间的绑定关系,

ChannelHandlerContext的主要功能是管理它所关联的ChannelHandler和在同一个ChannelPipeline中的其他ChannelHandler之间的交互,比如第一个入站处理器把数据交给第二个入站处理器,就由ChannelHandlerContext来调用第二个ChannelHandler.

通过使用作为参数传递到每个方法的ChannelHandlerContext，事件可以被传递给当前ChannelHandler 链中的下一个ChannelHandler。虽然这个对象可以被用于获取底层的Channel，但是它主要还是被用于写出站数据。

ChannelHandlerContext 代表了ChannelHandler 和ChannelPipeline 之间的关联，每当有ChannelHandler 添加到ChannelPipeline 中时，都会创建ChannelHandler-Context。ChannelHandlerContext 的主要功能是管理它所关联的ChannelHandler 和在同一个ChannelPipeline 中的其他ChannelHandler 之间的交互。

ChannelHandlerContext 有很多的方法，其中一些方法也存在于Channel 和Channel-Pipeline 本身上，但是有一点重要的不同。如果调用Channel 或者ChannelPipeline 上的这些方法，它们将沿着整个ChannelPipeline 进行传播。而调用位于ChannelHandlerContext上的相同方法，则将从当前所关联的ChannelHandler 开始，并且只会传播给位于该ChannelPipeline 中的下一个（入站下一个，出站上一个）能够处理该事件的ChannelHandler。

ChannelHandlerContext 的API
alloc 返回和这个实例相关联的Channel 所配置的ByteBufAllocator
bind 绑定到给定的SocketAddress，并返回ChannelFuture
channel 返回绑定到这个实例的Channel
close 关闭Channel，并返回ChannelFuture
connect 连接给定的SocketAddress，并返回ChannelFuture
deregister 从之前分配的EventExecutor 注销，并返回ChannelFuture
disconnect 从远程节点断开，并返回ChannelFuture
executor 返回调度事件的EventExecutor
fireChannelActive 触发对下一个ChannelInboundHandler 上的channelActive()方法（已连接）的调用
fireChannelInactive 触发对下一个ChannelInboundHandler 上的channelInactive()方法（已关闭）的调用
fireChannelRead 触发对下一个ChannelInboundHandler 上的channelRead()方法（已接收的消息）的调用
fireChannelReadComplete 触发对下一个ChannelInboundHandler 上的channelReadComplete()方法的调用
fireChannelRegistered 触发对下一个ChannelInboundHandler 上的fireChannelRegistered()方法的调用
fireChannelUnregistered 触发对下一个ChannelInboundHandler 上的fireChannelUnregistered()方法的调用
fireChannelWritabilityChanged 触发对下一个ChannelInboundHandler 上的fireChannelWritabilityChanged()方法的调用
fireExceptionCaught 触发对下一个ChannelInboundHandler 上的fireExceptionCaught(Throwable)方法的调用
fireUserEventTriggered 触发对下一个ChannelInboundHandler 上的fireUserEventTriggered(Object evt)方法的调用
handler 返回绑定到这个实例的ChannelHandler
isRemoved 如果所关联的ChannelHandler 已经被从ChannelPipeline中移除则返回true
name 返回这个实例的唯一名称
pipeline 返回这个实例所关联的ChannelPipeline
read 将数据从Channel读取到第一个入站缓冲区；如果读取成功则触发一个channelRead事件，并（在最后一个消息被读取完成后）通知ChannelInboundHandler 的channelReadComplete
(ChannelHandlerContext)方法
当使用ChannelHandlerContext 的API 的时候，有以下两点：
l ChannelHandlerContext 和ChannelHandler 之间的关联（绑定）是永远不会改变的，所以缓存对它的引用是安全的；
l 如同我们在本节开头所解释的一样，相对于其他类的同名方法，ChannelHandler Context的方法将产生更短的事件流，应该尽可能地利用这个特性来获得最大的性能。

 内置通信传输模式

NIO io.netty.channel.socket.nio 使用java.nio.channels 包作为基础——基于选择器的方式.

Epoll io.netty.channel.epoll 由 JNI 驱动的 epoll()和非阻塞 IO。这个传输支持只有在Linux 上可用的多种特性，如SO_REUSEPORT，比NIO 传输更快，而且是完全非阻塞的。将NioEventLoopGroup替换为EpollEventLoopGroup ， 并且将NioServerSocketChannel.class 替换为EpollServerSocketChannel.class 即可。Netty对NIO的Epoll做了特殊的相关优化,需要注意,如果你在代码里面指定了EpollServiceSocketChannel的话,意味着你的代码只能在Linux上面运行,无法在Window上运行.
从性能上讲Epoll要比NIO要高的,因为NIO底层是用的JDK为我们提供的,JDK为了实现一次编译到处运行,JDK把操作系统的某些方面做了一些相关的屏蔽,所以在性能上面会有点欠缺.
在NIO里面统一使用的水平触发,在Epoll使用的是边缘触发,

OIO io.netty.channel.socket.oio 使用java.net 包作为基础——使用阻塞流,你可以理解为就是普通的BIO.

Local io.netty.channel.local 可以在VM 内部通过管道进行通信的本地传输,如果你的两个网络通讯的对端放在同一个虚拟机里面的话,如果你使用Local模式的话,就不会走网卡了,会直接通过Unix的管道直接进行传输.避免了你的数据通过网卡进行流转.一般情况下你在本地测试的时候也可以用Local,不过我感觉没什么用.

Embedded io.netty.channel.embedded Embedded 传输，允许使用ChannelHandler 而又不需要一个真正的基于网络的传输。在测试ChannelHandler 实现时非常有用,主要是用来做测试用的,类似对每个Handler进行单元测试.

 Bootstrap和ServerBootstrap

Bootstrap是服务端和客户端启动必须要用的东西,Bootstrap初始化做了很多的事情.服务端和客户端代表两种不同的网络行为,如果你是监听传过来的连接,你就是服务器端.如果你是尝试去建立连接,这就是客户端.

因此，有两种类型的引导：一种用于客户端（简单地称为Bootstrap），而另一种（ServerBootstrap）用于服务器。


比较Bootstrap 类

区别:
1. ServerBootstrap 将绑定到一个端口，因为服务器必须要监听连接，而Bootstrap 则是由想要连接到远程节点的客户端应用程序所使用.
2. Boostrap只需要一个EventLoopGroup，但是一个ServerBootstrap 则需要两个（也可以是同一个实例）。

ServerBootstrap的EventLoopGroup线程组包含了一组NIO线程,专门用于网络事件的处理,实际上他们是Reactor线程组,使用两个线程组的原因是一个用于服务端接受客户端的连接,另一个用于进行SocketChannel的网络读写.





在引导过程中添加多个ChannelHandler

Netty 提供了一个特殊的ChannelInboundHandlerAdapter 子类：
public abstract class ChannelInitializer ext ends ChannelInboundHandlerAdapter
它定义了下面的方法：
protect ed abstract void initChannel(C ch) throws Exception;
这个方法提供了一种将多个ChannelHandler 添加到一个ChannelPipeline 中的简便方法。你只需要简单地向Bootstrap 或ServerBootstrap 的实例提供你的ChannelInitializer 实现即可，并且一旦Channel 被注册到了它的EventLoop 之后，就会调用你的initChannel()版本。在该方法返回之后，ChannelInitializer 的实例将会从ChannelPipeline 中移除它自己。

 ChannelOption

配置在网络连接的时候各种网络连接的相关属性

ChannelOption的各种属性在套接字选项中都有对应。
1、ChannelOption.SO_BACKLOG
ChannelOption.SO_BACKLOG对应的是tcp/ip协议listen函数中的backlog参数，函数listen(int socketfd,int backlog)用来初始化服务端可连接队列，
服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接，多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，backlog参数指定了队列的大小
2、ChannelOption.SO_REUSEADDR
ChanneOption.SO_REUSEADDR对应于套接字选项中的SO_REUSEADDR，这个参数表示允许重复使用本地地址和端口，
比如，某个服务器进程占用了TCP的80端口进行监听，此时再次监听该端口就会返回错误，使用该参数就可以解决问题，该参数允许共用该端口，这个在服务器程序中比较常使用，比如某个进程非正常退出，该程序占用的端口可能要被占用一段时间才能允许其他进程使用，而且程序死掉以后，内核一需要一定的时间才能够释放此端口，不设置SO_REUSEADDR　　　　就无法正常使用该端口。
3、ChannelOption.SO_KEEPALIVE
Channeloption.SO_KEEPALIVE参数对应于套接字选项中的SO_KEEPALIVE，该参数用于设置TCP连接，当设置该选项以后，连接会测试链接的状态，这个选项用于可能长时间没有数据交流的连接。当设置该选项以后，如果在两小时内没有数据的通信时，TCP会自动发送一个活动探测数据报文。
4、ChannelOption.SO_SNDBUF和ChannelOption.SO_RCVBUF
ChannelOption.SO_SNDBUF参数对应于套接字选项中的SO_SNDBUF，ChannelOption.SO_RCVBUF参数对应于套接字选项中的SO_RCVBUF这两个参数用于操作接收缓冲区和发送缓冲区的大小，接收缓冲区用于保存网络协议站内收到的数据，直到应用程序读取成功，发送缓冲区用于保存发送数据，直到发送成功。
5、ChannelOption.SO_LINGER
ChannelOption.SO_LINGER参数对应于套接字选项中的SO_LINGER,Linux内核默认的处理方式是当用户调用close（）方法的时候，函数返回，在可能的情况下，尽量发送数据，不一定保证会发生剩余的数据，造成了数据的不确定性，使用SO_LINGER可以阻塞close()的调用时间，直到数据完全发送
6、ChannelOption.TCP_NODELAY
ChannelOption.TCP_NODELAY参数对应于套接字选项中的TCP_NODELAY,该参数的使用与Nagle算法有关，Nagle算法是将小的数据包组装为更大的帧然后进行发送，而不是输入一次发送一次,因此在数据包不足的时候会等待其他数据的到了，组装成大的数据包进行发送，虽然该方式有效提高网络的有效负载，但是却造成了延时，而该参数的作用就是禁止使用Nagle算法，使用于小数据即时传输，于TCP_NODELAY相对应的是TCP_CORK，该选项是需要等到发送的数据量最大的时候，一次性发送数据，适用于文件传输。

 ByteBuf

网络数据的基本单位总是字节,Java NIO提供了ByteBuffer作为它的字节容器,但是这个类使用起来过于复杂,而且有些繁琐.
Netty的ByteBuf替代了ByteBuffer,一个强大的实现类,既解决了JDK API 的局限性,又为网络应用程序的开发者提供了更好的API.


ByteBuf API 的优点：
它可以被用户自定义的缓冲区类型扩展；
通过内置的复合缓冲区类型实现了透明的零拷贝；
容量可以按需增长（类似于JDK 的StringBuilder）；
在读和写这两种模式之间切换不需要调用ByteBuffer 的flip()方法；
读和写使用了不同的索引；
支持方法的链式调用；
支持引用计数；
支持池化。
ByteBuf 维护了两个不同的索引，名称以read 或者write 开头的ByteBuf 方法，将会推进其对应的索引，而名称以set 或者get 开头的操作则不会
如果打算读取字节直到readerIndex 达到和writerIndex 同样的值时会发生什么。在那时，你将会到达“可以读取的”数据的末尾。就如同试图读取超出数组末尾的数据一样，试图读取超出该点的数据将会触发一个IndexOutOf-BoundsException。
可以指定ByteBuf 的最大容量。试图移动写索引（即writerIndex）超过这个值将会触发一个异常。（默认的限制是Integer.MAX_VALUE。）

分配

堆缓冲区
最常用的ByteBuf 模式是将数据存储在JVM 的堆空间中。这种模式被称为支撑数组（backing array），它能在没有使用池化的情况下提供快速的分配和释放。可以由hasArray()来判断检查ByteBuf 是否由数组支撑。如果不是，则这是一个直接缓冲区
直接缓冲区
直接分配在直接内存上的就是直接缓冲区
直接缓冲区是另外一种ByteBuf 模式。
直接缓冲区的主要缺点是，相对于基于堆的缓冲区，它们的分配和释放都较为昂贵。
ByteBufAllocator
Netty 通过interface ByteBufAllocator分配我们所描述过的任意类型的ByteBuf 实例。

可以通过Channel（每个都可以有一个不同的ByteBufAllocator 实例）或者绑定到ChannelHandler 的ChannelHandlerContext 获取一个到ByteBufAllocator 的引用。

Netty提供了两种ByteBufAllocator的实现：PooledByteBufAllocator和Unpooled-ByteBufAllocator。前者池化了ByteBuf的实例以提高性能并最大限度地减少内存碎片。后者的实现不池化ByteBuf实例，并且在每次它被调用时都会返回一个新的实例。
Netty4.1默认使用了PooledByteBufAllocator。
Unpooled 缓冲区
Netty 提供了一个简单的称为Unpooled 的工具类，它提供了静态的辅助方法来创建未池化的ByteBuf
实例。
buffer() 返回一个未池化的基于堆内存存储的ByteBuf
directBuffer()返回一个未池化的基于直接内存存储的ByteBuf
wrappedBuffer() 返回一个包装了给定数据的ByteBuf
copiedBuffer() 返回一个复制了给定数据的ByteBuf
Unpooled 类还可用于ByteBuf 同样可用于那些并不需要Netty 的其他组件的非网络项目。

随机访问索引/顺序访问索引/读写操作

如同在普通的Java 字节数组中一样，ByteBuf 的索引是从零开始的：第一个字节的索引是0，最后一个字节的索引总是capacity() - 1。使用那些需要一个索引值参数(随机访问,也即是数组下标)的方法（的其中）之一来访问数据既不会改变readerIndex 也不会改变writerIndex。如果有需要，也可以通过调用readerIndex(index)或者writerIndex(index)来手动移动这两者。顺序访问通过索引访问
有两种类别的读/写操作：
get()和set()操作，从给定的索引开始，并且保持索引不变；get+数据字长（bool.byte,int,short,long,bytes）
read()和write()操作，从给定的索引开始，并且会根据已经访问过的字节数对索引进行调整。
更多的操作
isReadable() 如果至少有一个字节可供读取，则返回true
isWritable() 如果至少有一个字节可被写入，则返回true
readableBytes() 返回可被读取的字节数
writableBytes() 返回可被写入的字节数
capacity() 返回ByteBuf 可容纳的字节数。在此之后，它会尝试再次扩展直到达到maxCapacity()
maxCapacity() 返回ByteBuf 可以容纳的最大字节数
hasArray() 如果ByteBuf 由一个字节数组支撑，则返回true
array() 如果 ByteBuf 由一个字节数组支撑则返回该数组；否则，它将抛出一个UnsupportedOperationException 异常

可丢弃字节

为可丢弃字节的分段包含了已经被读过的字节。通过调用discardRead-Bytes()方法，可以丢弃它们并回收空间。这个分段的初始大小为0，存储在readerIndex 中，会随着read 操作的执行而增加（get*操作不会移动readerIndex）。
缓冲区上调用discardReadBytes()方法后，可丢弃字节分段中的空间已经变为可写的了。频繁地调用discardReadBytes()方法以确保可写分段的最大化，但是请注意，这将极有可能会导致内存复制，因为可读字节必须被移动到缓冲区的开始位置。建议只在有真正需要的时候才这样做，例如，当内存非常宝贵的时候。

可读字节

ByteBuf 的可读字节分段存储了实际数据。新分配的、包装的或者复制的缓冲区的默认的readerIndex 值为0。

可写字节

可写字节分段是指一个拥有未定义内容的、写入就绪的内存区域。新分配的缓冲区的writerIndex 的默认值为0。任何名称以write 开头的操作都将从当前的writerIndex 处开始写数据，并将它增加已经写入的字节数。

索引管理

调用markReaderIndex()、markWriterIndex()、resetWriterIndex()和resetReaderIndex()来标记和重置ByteBuf 的readerIndex 和writerIndex。
也可以通过调用readerIndex(int)或者writerIndex(int)来将索引移动到指定位置。试图将任何一个索引设置到一个无效的位置都将导致一个IndexOutOfBoundsException。
可以通过调用clear()方法来将readerIndex 和writerIndex 都设置为0。注意，这并不会清除内存中的内容。

查找操作

在ByteBuf中有多种可以用来确定指定值的索引的方法。最简单的是使用indexOf()方法。
较复杂的查找可以通过调用forEach Byte()。
代码展示了一个查找回车符（\r）的例子。

派生缓冲区

派生缓冲区为ByteBuf 提供了以专门的方式来呈现其内容的视图。这类视图是通过以下方法被创建的：
duplicate()；
slice()；
slice(int, int)；
Unpooled.unmodifiableBuffer(…)；
order(ByteOrder)；
readSlice(int)。
每个这些方法都将返回一个新的ByteBuf 实例，它具有自己的读索引、写索引和标记索引。其内部存储和JDK 的ByteBuffer 一样也是共享的。
ByteBuf 复制 如果需要一个现有缓冲区的真实副本，请使用copy()或者copy(int, int)方法。不同于派生缓冲区，由这个调用所返回的ByteBuf 拥有独立的数据副本。

引用计数

引用计数是一种通过在某个对象所持有的资源不再被其他对象引用时释放该对象所持有的资源来优化内存使用和性能的技术。Netty 在第4 版中为ByteBuf引入了引用计数技术， interface ReferenceCounted。

工具类

ByteBufUtil 提供了用于操作ByteBuf 的静态的辅助方法。因为这个API 是通用的，并且和池化无关，所以这些方法已然在分配类的外部实现。
这些静态方法中最有价值的可能就是hexdump()方法，它以十六进制的表示形式打印ByteBuf 的内容。这在各种情况下都很有用，例如，出于调试的目的记录ByteBuf 的内容。十六进制的表示通常会提供一个比字节值的直接表示形式更加有用的日志条目，此外，十六进制的版本还可以很容易地转换回实际的字节表示。
另一个有用的方法是boolean equals(ByteBuf, ByteBuf)，它被用来判断两个ByteBuf实例的相等性。

资源释放

当某个ChannelInboundHandler 的实现重写channelRead()方法时，它要负责显式地释放与池化的ByteBuf 实例相关的内存。Netty 为此提供了一个实用方法ReferenceCountUtil.release()
Netty 将使用WARN 级别的日志消息记录未释放的资源，使得可以非常简单地在代码中发现违规的实例。但是以这种方式管理资源可能很繁琐。一个更加简单的方式是使用SimpleChannelInboundHandler，SimpleChannelInboundHandler 会自动释放资源。
1、对于入站请求，Netty的EventLoo在处理Channel的读操作时进行分配ByteBuf，对于这类ByteBuf，需要我们自行进行释放，有三种方式，或者使用SimpleChannelInboundHandler，或者在重写channelRead()方法使用ReferenceCountUtil.release()或者使用ctx.fireChannelRead继续向后传递；
2、对于出站请求，不管ByteBuf是否由我们的业务创建的，当调用了write或者writeAndFlush方法后，Netty会自动替我们释放，不需要我们业务代码自行释放。

 粘包/半包问题

假设客户端分别发送了两个数据包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包接收完全，期间发生多次拆包。

客户端要向服务端发送请求,发送了两个请求,give me a coffee 和give me a tea 两个请求,正常情况下服务端应该是依次接收两个请求分别处理,但是因为某些原因,服务端可能不会那么顺序的收到两个请求,它两个请求可能是粘在一起的,只是收到一个请求,收到的数据可能是这样的give me a coffeegive me a tea ,也就是两个请求粘在一起了,这样的话服务器就无法去解析这个请求,这种现象就是粘包现象.

还有情况是先收到 give me 然后再收到a coffeegive me a tea ,同样是两个请求,但是服务器也无法解析.这种现象叫做分包现象.分包现象就是一个请求的数据分别在不同的阶段收到.

1．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分片可以发生在原始发送端主机上，也可以发生在中间路由器上。

出现粘包和分包的根本原因是什么?

是我们服务端根本没有办法去区分你请求是否到底是传送了哪些数据,因为服务端和客户端没有商量好.所以粘包和分包出现的原因是因为没有稳定的数据结构.

解决粘包分包问题的话通常会采取两种措施

1. 采用分隔符分隔的方式
比如说我发送请求之后我加上一个下划线(_)的结束符,服务端可能收到数据还是原来的,但是没有关闭,服务端没有接收到预先约定好的结束分隔符前,等待继续接收数据,后面的数据来了,再接着读取,如果读取到了分隔符了,分隔符之前的数据就成为了一个请求投递到业务层去,剩余的部分接着读,直到读到结束分隔符….以此类推…

这种解决方法效率稍微差点,因为要挨个检查

2. 长度+数据的方式
我在写数据的时候,我在数据前面拿四个字节声明一下发送过来的数据到底有多长,所以服务端收到数据之后先读取前面的长度,比如长度为16,那么后面16长度的数据就是第一次请求,如果没达到长度就接着等第二次数据来了,如果数据够了就凑够一个请求投递到业务层去.

2．解决粘包半包问题

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

1. 在包尾增加分隔符(特殊的的字符串)，比如回车换行符进行分割，
2. 消息的固定长度,比如说规定死了每次只发送100个,如果你在收到报文的时候从第0个开始就按照100,100进行切分,如果你收到50个,就等着,等把下一个50个再发送过来你就可以认为是一个完整的报文了.
3. 将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常设计思路为消息头的第一个字段使用int32来表示消息的总长度，LengthFieldBasedFrameDecoder。
比如说你发送100个长度的报文,前面多出两个字节用来告知当前发送的报文的长度, 这样总长度就变成了102个长度的报文了,但是前两个字节标识了当前的报文是多长的.你收到报文的长度了,先读取报文前两个字节,就能得知当前的报文长度是多少了.(最灵活,也是最复杂的.)

 编解码器框架

（一）什么是编解码器

每个网络应用程序都必须定义如何解析在两个节点之间来回传输的原始字节(0101串儿)，客户端传给服务端之后,需要给0101串儿转成我服务端需要的数据格式,服务端也是这样,服务端接收到客户端的0101串儿之后需要转成客户端需要的数据格式.
数据格式的转换逻辑由编解码器处理，编解码器由编码器和解码器组成，它们每种都可以将字节流从一种格式转换为另一种格式。


什么是编码器
将我们的自己定义的相关的业务类型的数据转换成我们适合于传输的格式(一般来讲适合传输的格式就是字节流)
什么是解码器
把网络上的字节流转换成我们应用程序所需要的我们这种消息格式

（二）解码器

ByteToMessageDecoder将字节解码为消息(是入站处理器,)
MessageToMessageDecoder。 将一种消息类型解码为另一种,可能网络传过来的数据将字节解码为消息之后可能还不是我应用程序所需要的消息,可能中间还需要进行一次消息类型的解码才能是我的应用所接受的消息

因为解码器是负责将入站数据从一种格式转换到另一种格式的，所以Netty 的解码器实现了ChannelInboundHandler。
什么时候会用到解码器呢？很简单：每当需要为ChannelPipeline 中的下一个Channel-InboundHandler 转换入站数据时会用到。此外，得益于ChannelPipeline 的设计，可以将多个解码器链接在一起，以实现任意复杂的转换逻辑。

将字节解码为消息

抽象类ByteToMessageDecoder
将字节解码为消息（或者另一个字节序列）是一项如此常见的任务，以至于Netty 为它提供了一个抽象的基类：ByteToMessageDecoder。由于你不可能知道远程节点是否会一次性地发送一个完整的消息，所以这个类会对入站数据进行缓冲，直到它准备好处理。
它最重要方法
decode(ChannelHandlerContext ctx,ByteBuf in,List