Netty 实战

1 Netty 版本选择

Netty 请选择使用4.x版本，不要用5.x ，5.x已经废弃

<!-- https://mvnrepository.com/artifact/io.netty/netty-all -->
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-all</artifactId>
    <version>4.1.113.Final</version>
</dependency>

2 Netty 模版代码

2.1 Server

        new ServerBootstrap()
                //.group(new NioEventLoopGroup())
                .group(new NioEventLoopGroup(1), new NioEventLoopGroup())
                .channel(NioServerSocketChannel.class)
                .childHandler(new ChannelInitializer<NioSocketChannel>() {
                    @Override
                    protected void initChannel(NioSocketChannel ch) throws Exception {
                        ch.pipeline().addLast("ChannelInboundHandler1", new ChannelInboundHandlerAdapter() {
                            @Override
                            public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
                                //流转到下一个InHandler
                                // super.channelRead(ctx, msg) 也是调用ctx.fireChannelRead(msg)
                                ctx.fireChannelRead(msg);
                            }
                        });
                    }
                }).bind(5989).sync();
    }

• ServerBootstrap， Server服务启动器
• group， 创建 NioEventLoopGroup，可以简单理解为 `线程池 + Selector，如果两个参数，第一个为parentGroup 可以理解为监听客户端的连接事件，第二个childGroup，负责处理客户端NioSocketChannel 的读写。
• channel, 选择 Scoket 实现类，其中 NioServerSocketChannel 表示基于 NIO 的服务器端ServerSocketChannel的实现。
• childHandler，是接下来添加的处理器都是给 SocketChannel 用的，而不是给 ServerSocketChannel。ChannelInitializer 处理器（每个客户端接入时 执行且只执行一次），它的作用是待客户端 SocketChannel 建立连接后，执行 initChannel 以便添加更多的处理器。
• ch.pipeline().addLast，添加消息处理器，入站的消息 按Handler在pipeline的里的顺序从头到尾依次处理。出站的消息从尾（也可能是当前Handler）到头依次处理
• bind ServerSocketChannel 绑定的监听端口

2.2 Client

Channel channel = new Bootstrap()
                .group(new NioEventLoopGroup())
                .channel(NioSocketChannel.class) 
                .handler(new ChannelInitializer<Channel>() {
                    @Override
                    protected void initChannel(Channel channel) throws Exception {
                        channel.pipeline().addLast(new StringEncoder());
                    }
                }).connect("127.0.0.1", 8080)
                .sync()
                .channel();

• group 创建 NioEventLoopGroup
• channel, 选择 Scoket 实现类，NioSocketChannel 表示基于 NIO 的客户端实现
• handler 添加 SocketChannel 的处理器，ChannelInitializer 处理器（仅执行一次），它的作用是待客户端 SocketChannel 建立连接后，执行 initChannel 以便添加更多的处理器
• ch.pipeline().addLast，添加消息处理器，入站消息 按Handler在pipeline的里的顺序从头到尾依次处理。出站的消息从尾（也可能是当前Handler）到头依次处理
• connect 指定要连接的服务器和端口，connect 是异步的，方法返回一个ChannelFuture，
  • 调用ChannelFuture 的 sync 方法同步等待 connect 建立连接完毕
  • 调用ChannelFuture 的addListener 方法 ，连接完成执行异步回调
• sync Netty 中很多方法都是异步的，如 connect，这时需要使用 sync 方法等待 connect 建立连接完毕
• 获取 channel 对象，它即为通道抽象，可以进行数据读写操作

3 组件

3.1 EventLoop、EventLoopGroup

3.1.1 EventLoop

EventLoop 本质是一个单线程执行器（同时维护了一个 Selector），里面有 run 方法处理 Channel 上源源不断的 io 事件。

继承关系

• 继承自 j.u.c.ScheduledExecutorService 因此包含了线程池中所有的方法
• 另一条线是继承自 netty 自己的 OrderedEventExecutor，
  • 提供了 boolean inEventLoop(Thread thread) 方法判断一个线程是否属于此 EventLoop
  • 提供了 parent 方法来看看自己属于哪个 EventLoopGroup

3.1.2 EventLoopGroup

EventLoopGroup 是一组 EventLoop，Channel 一般会调用 EventLoopGroup 的 register 方法来绑定其中一个 EventLoop，后续这个 Channel 上的 io 事件都由此 EventLoop 来处理（保证了 io 事件处理时的线程安全）
继承关系

• 继承自 netty 自己的 EventExecutorGroup ，next 方法获取集合中下一个 EventLoop
• 实现了 Iterable 接口提供遍历 EventLoop 的能力

3.2 Channel

channel 的主要方法

• close() 可以用来关闭 channel
• closeFuture() 用来处理 channel 的关闭
  • sync 方法作用是同步等待 channel 关闭
  • addListener 方法是 channel 关闭后执行回调
• pipeline() 方法添加处理器
• write() 方法将数据写入
• writeAndFlush() 方法将数据写入并刷出

3.2.1 ChannelFuture

ChannelFuture channelFuture = new Bootstrap()
    .group(new NioEventLoopGroup())
    .channel(NioSocketChannel.class)
    .handler(new ChannelInitializer<Channel>() {
        @Override
        protected void initChannel(Channel ch) {
            ch.pipeline().addLast(new StringEncoder());
        }
    })
    .connect("127.0.0.1", 8080); // 1

channelFuture.sync().channel().writeAndFlush(new Date() + ": hello world!");

1 处返回的是 ChannelFuture 对象
注意 connect 方法是异步的，意味着不等连接建立，方法执行就返回了。因此 channelFuture 对象中不能【立刻】获得到正确的 Channel 对象
ChannelFuture 的两个重要方法

• channelFuture.sync() ，同步等待连接完成
• channelFuture.addListener 连接建立后异步回调

 channelFuture.addListener((ChannelFutureListener) future -> {
    System.out.println(future.channel()); 
});

3.2.2 CloseFuture

 // 获取 CloseFuture 对象， 1) 同步处理关闭， 2) 异步处理关闭
        ChannelFuture closeFuture = channel.closeFuture();
        //1) 同步处理关闭
        closeFuture.sync();
        // 2) 异步处理关闭
        closeFuture.addListener(new ChannelFutureListener() {
            @Override
            public void operationComplete(ChannelFuture future) throws Exception {
                log.debug("处理关闭之后的操作");
                //group.shutdownGracefully();
            }
        });

3.3 ChannelHandler

ChannelHandler 用来处理 Channel 上的各种事件，分为入站、出站两种。所有 ChannelHandler 被连成一串，就是 Pipeline

• 入站处理器通常是 ChannelInboundHandlerAdapter 的子类，主要用来读取客户端数据，写回结果
• 出站处理器通常是 ChannelOutboundHandlerAdapter 的子类，主要对写回结果进行加工

Handler的执行顺序

new ServerBootstrap()
    .group(new NioEventLoopGroup())
    .channel(NioServerSocketChannel.class)
    .childHandler(new ChannelInitializer<NioSocketChannel>() {
        protected void initChannel(NioSocketChannel ch) {
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(1);
                    ctx.fireChannelRead(msg); // 1
                }
            });
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(2);
                    ctx.fireChannelRead(msg); // 2
                }
            });
            ch.pipeline().addLast(new ChannelInboundHandlerAdapter(){
                @Override
                public void channelRead(ChannelHandlerContext ctx, Object msg) {
                    System.out.println(3);
                    ctx.channel().write(msg); // 3
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(4);
                    ctx.write(msg, promise); // 4
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(5);
                    ctx.write(msg, promise); // 5
                }
            });
            ch.pipeline().addLast(new ChannelOutboundHandlerAdapter(){
                @Override
                public void write(ChannelHandlerContext ctx, Object msg, 
                                  ChannelPromise promise) {
                    System.out.println(6);
                    ctx.write(msg, promise); // 6
                }
            });
        }
    })
    .bind(8080);

 服务器端打印：
1
2
3
6
5
4

可以看到，ChannelInboundHandlerAdapter 是按照 addLast 的顺序执行的，而 ChannelOutboundHandlerAdapter 是按照 addLast 的逆序执行的。ChannelPipeline 的实现是一个 ChannelHandlerContext（包装了 ChannelHandler） 组成的双向链表

• 入站处理器中，ctx.fireChannelRead(msg) 是 调用下一个入站处理器
  • 如果注释掉 1 处代码，则仅会打印 1
  • 如果注释掉 2 处代码，则仅会打印 1 2
• 3 处的 ctx.channel().write(msg) 会 从尾部开始触发 后续出站处理器的执行
  • 如果注释掉 3 处代码，则仅会打印 1 2 3
• 类似的，出站处理器中，ctx.write(msg, promise) 的调用也会 触发上一个出站处理器
  • 如果注释掉 6 处代码，则仅会打印 1 2 3 6
• ctx.channel().write(msg) vs ctx.write(msg)
  • 都是触发出站处理器的执行
  • ctx.channel().write(msg) 从尾部开始查找出站处理器
  • ctx.write(msg) 是从当前节点找上一个出站处理器
  • 3 处的 ctx.channel().write(msg) 如果改为 ctx.write(msg) 仅会打印 1 2 3，因为节点3 之前没有其它出站处理器了
  • 6 处的 ctx.write(msg, promise) 如果改为 ctx.channel().write(msg) 会打印 1 2 3 6 6 6… 因为 ctx.channel().write() 是从尾部开始查找，结果又是节点6 自己
  • 服务端 pipeline 触发的原始流程，图中数字代表了处理步骤的先后次序
    

3.2.1 常用的 ChannelInboundHandlerAdapter

3.2.1.1 LineBasedFrameDecoder

以 换行分隔符（ \n 或 \r\n ）为结尾进行分割

• 构造函数

/**
 * @param maxLength  解码帧的最大长度。如果帧长度超过此值，则抛出异常
 */
 public LineBasedFrameDecoder(final int maxLength) {
        this(maxLength, true, false);
    }
//更多构造函数见源码    

• 输入 ByteBuf

• 输出 ByteBuf ,每遇到换行符 就将换行符之前的数据 单独调用ctx.fireChannelRead 传递给下一个ChannelHandler，多行数据会调用多次ctx.fireChannelRead

• 使用方法

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

3.2.1.2 DelimiterBasedFrameDecoder

以 指定的分隔符 为结尾进行分割

• 构造函数

 /**
 * @param maxFrameLength  解码帧的最大长度。如果帧长度超过此值，则抛出异常
 * @param delimiter  分隔符
 */
   public DelimiterBasedFrameDecoder(int maxFrameLength, ByteBuf delimiter) {
       this(maxFrameLength, true, delimiter);
   }

• 输入 ByteBuf
• 输出 ByteBuf, 每遇到指定的分隔符 就将分隔符之前的数据 单独调用ctx.fireChannelRead 传递给下一个ChannelHandler，多条数据会调用多次ctx.fireChannelRead
• 使用方法

//以 F0F1 为分隔符
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024, ByteBufAllocator.DEFAULT.buffer().writeBytes("F0F1".getBytes(StandardCharsets.UTF_8))));

3.2.1.3 LengthFieldBasedFrameDecoder

是一个根据在接收到的 ByteBuf 消息中 长度值 对这个消息动态的切分的解码器。在需要解码二进制消息并且在消息头中包含代表这条消息的整体长度或消息体长度的字段的情况下非常有用。

• 配置参数
  类拥有许多配置参数，所以它可以用来解析任何包含长度字段的消息，包含长度字段的消息在自定义的客户端-服务端协议之间非常常见。常用的配置参数有：

  • ByteOrder byteOrder ： 这个二进制消息是大端模式[默认]/小端模式，如果和实际数据不同，length 字段数值解析错误

  • int maxFrameLength ： 这个二进制消息最大长度

  • int lengthFieldOffset ： 这个二进制消息长度字段位于消息的偏移位置

  • int lengthFieldLength ： 这个二进制消息长度的字段的字节长度

  • int lengthAdjustment: 长度调整，添加到长度字段数值的补偿值
    取值计算公式为： 长度字段后面数据长度X-长度字段数值Y
    当长度字段的值代表 长度字段后边数据的长度时 为0

  • int initialBytesToStrip ：传递给下一个ChannelHandler跳过(删除)指定长度的字节，一般用于跳过消息头，只将消息体保留，
    如果非0，则传递给下一个Handler的Bytebuf ，将从整个消息中剔除前 initialBytesToStrip 个字节

  • boolean failFast ：快速失败，当消息的长度超过maxFrameLength时立即抛出TooLongFrameException异常

• 构造函数

public LengthFieldBasedFrameDecoder(
          int maxFrameLength,
          int lengthFieldOffset, int lengthFieldLength) {
      this(maxFrameLength, lengthFieldOffset, lengthFieldLength, 0, 0);
  }
 public LengthFieldBasedFrameDecoder(
         int maxFrameLength,
         int lengthFieldOffset, int lengthFieldLength,
         int lengthAdjustment, int initialBytesToStrip) {
     this(
             maxFrameLength,
             lengthFieldOffset, lengthFieldLength, lengthAdjustment,
             initialBytesToStrip, true);
 }
public LengthFieldBasedFrameDecoder(
            int maxFrameLength, int lengthFieldOffset, int lengthFieldLength,
            int lengthAdjustment, int initialBytesToStrip, boolean failFast) {
        this(
                ByteOrder.BIG_ENDIAN, maxFrameLength, lengthFieldOffset, lengthFieldLength,
                lengthAdjustment, initialBytesToStrip, failFast);
    }
public LengthFieldBasedFrameDecoder(
            ByteOrder byteOrder, int maxFrameLength, int lengthFieldOffset, int lengthFieldLength,
            int lengthAdjustment, int initialBytesToStrip, boolean failFast) {

• 输入 ByteBuf
• 输出 ByteBuf ,每解析出一条数据，就 单独调用ctx.fireChannelRead 传递给下一个ChannelHandler，多条数据会调用多次ctx.fireChannelRead

1. 使用示例
   1). 示例1 长度字段偏移量为0，长度字段代表长度字段后面的数据长度
   消息的长度字段数值是0x000C(12)，代表Actual Content的字节数。
   lengthFieldOffset = 0 （这个二进制消息长度的字段位于消息的最开始，故偏移量为0）
   lengthFieldLength = 2 （如题，2个bytes长度字段）
   lengthAdjustment = 0 (12（长度调整，12(长度字段之后的数据长度即 Actual Content) -12（长度字段数值[0x000C]） = 0)
   initialBytesToStrip = 0 ( 不跳过任何数据，保留完整消息)
   initialBytesToStrip = 2 ( 跳过Length字段,只保留Actual Content）
   此Handler处理后的消息即下个Handler收到消息变为

                                 initialBytesToStrip = 0        initialBytesToStrip = 2 
BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)        AFTER DECODE (12 bytes)
+--------+----------------+      +--------+----------------+    +----------------+
| Length | Actual Content |----->| Length | Actual Content |--->| Actual Content |
| 0x000C | "HELLO, WORLD" |      | 0x000C | "HELLO, WORLD" |    | "HELLO, WORLD" |  
+--------+----------------+      +--------+----------------+    +----------------+

2). 示例2 长度字段偏移量为0，长度字段代表整个消息长度
消息的长度字段数值是0x000E (14)，代表整个消息长度
lengthFieldOffset = 0 （这个二进制消息长度的字段位于消息的最开始，故偏移量为0）
lengthFieldLength = 2 （（如题，2个bytes长度字段）
lengthAdjustment = -2 (长度调整， 12（长度字段之后的数据长度即Actual Content） -14（长度字段数值[0x000E] = -2 )
initialBytesToStrip = 0 ( 不跳过任何数据，保留完整消息)
initialBytesToStrip = 2 ( 跳过Length字段,只保留Actual Content）
此Handler处理后的消息即下个Handler收到消息变为

                                 initialBytesToStrip = 0        initialBytesToStrip = 2 
BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)        AFTER DECODE (12 bytes)
+--------+----------------+      +--------+----------------+    +----------------+
| Length | Actual Content |----->| Length | Actual Content |--->| Actual Content |
| 0x000E | "HELLO, WORLD" |      | 0x000E | "HELLO, WORLD" |    | "HELLO, WORLD" |  
+--------+----------------+      +--------+----------------+    +----------------+

3). 示例3 长度字段偏移量为2，长度字段代表后面的数据长度
消息的长度字段数值是0x00000C (12)，代表Actual Content长度
lengthFieldOffset = 2 （这个二进制消息长度的字段位于消息的第三个字节，故偏移量为Header1 的字节数2）
lengthFieldLength = 3 （如题，长度字段为3）
lengthAdjustment =0 (长度调整，12（长度字段之后的数据长度即Actual Content)12-12(长度字段数值[0x000C]) = 0)
initialBytesToStrip = 0 (不跳过消息头，保留完整消息)
initialBytesToStrip = 5 (跳过Header 1 +Length 字段 ，只保留 Actual Content )
此Handler处理后的消息即下个Handler收到消息变为

                                              initialBytesToStrip = 0                     initialBytesToStrip = 5 
BEFORE DECODE (17 bytes)                      AFTER DECODE (17bytes)                      AFTER DECODE (12 bytes)
+----------+----------+----------------+      +----------+----------+----------------+    +----------------+
| Header 1 |  Length  | Actual Content |----->| Header 1 |  Length  | Actual Content |--->|  Actual Content|
|  0xCAFE  | 0x00000C | "HELLO, WORLD" |      |  0xCAFE  | 0x00000C | "HELLO, WORLD" |    | "HELLO, WORLD" |
+----------+----------+----------------+      +----------+----------+----------------+    +----------------+

4). 示例4 长度字段偏移量为0，长度字段和Actual Content之间有数据（Header1） ， 长度字段代表 Actual Content 长度但不是长度字段之后所有数据的长度（未包括Header数据长度）
消息的长度字段数值是0x00000C (12)，代表Actual Content长度
lengthFieldOffset = 0 （这个二进制消息长度的字段位于消息的最开始，故偏移量为0）
lengthFieldLength = 3 （如题，长度字段为3）
lengthAdjustment =2 (14（长度字段 后面数据长度 Header1+ Actual Content） - 12（长度数值12[0x000C]） = 2)
initialBytesToStrip = 0 不跳过消息头 保留完整消息
initialBytesToStrip =5 ( 跳过 Length+Header1 字段，仅保留Actual Content）
initialBytesToStrip =3(跳过 Length 字段,保留 Header1+ Actual Content)
此Handler处理后的消息即下个Handler收到消息变为

                                              initialBytesToStrip = 0                     initialBytesToStrip = 5 
BEFORE DECODE (17 bytes)                      AFTER DECODE (17bytes)                      AFTER DECODE (12 bytes)
+----------+----------+----------------+    +----------+----------+----------------+     +----------------+
|  Length  | Header 1 | Actual Content |--->|  Length  | Header 1 | Actual Content | --->| Actual Content | --->
| 0x00000C |  0xCAFE  | "HELLO, WORLD" |    | 0x00000C |  0xCAFE  | "HELLO, WORLD" |     | "HELLO, WORLD" |
+----------+----------+----------------+    +----------+----------+----------------+     +----------------+

initialBytesToStrip = 3
AFTER DECODE (14 bytes) 
+----------+----------------+
| Header 1 | Actual Content |
|  0xCAFE  | "HELLO, WORLD" |
+----------+----------------+ 

5). 示例5 长度字段偏移量为1，长度字段和真是消息内容之间有数据（HDR2 ） ， 长度字段代表 Actual Content 长度但不是长度字段之后所有数据的长度（未包括 HDR2 数据长度）
消息的长度字段数值是0x00000C (12)，代表Actual Content长度
lengthFieldOffset = 1 (这个二进制消息长度的字段位于消息的第1个字段HDR1之后，故偏移量为HDR1的字节数1）
lengthFieldLength = 2 （如题，2bytes为长度字段）
lengthAdjustment =1 (长度调整 ,13(长度字段 后面数据长度 HDR2 +Actual Content)-12(长度数值12[0x000C])=1，)
initialBytesToStrip = 0 ( 不跳过消息头，保留完整消息)
initialBytesToStrip =3 ( 跳过HDR1 +Length ，保留HDR2 + Actual Content )
此Handler处理后的消息即下个Handler收到消息变为

                                             initialBytesToStrip = 0                     initialBytesToStrip = 0 
BEFORE DECODE (17 bytes)                     AFTER DECODE (17bytes)                      AFTER DECODE (13bytes) 
+------+--------+------+----------------+   +------+--------+------+----------------+    +------+----------------+
| HDR1 | Length | HDR2 | Actual Content |-->| HDR1 | Length | HDR2 | Actual Content |--> | HDR2 | Actual Content |
| 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |   | 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |    | 0xFE | "HELLO, WORLD" |
+------+--------+------+----------------+   +------+--------+------+----------------+    +------+----------------+

6). 示例6 长度字段偏移量为1，长度字段和真是消息内容之间有数据（HDR2 ） ， 长度字段代表 整个消息长度但不是长度字段之后数据的长度
消息的长度字段数值是0x0010 (16)，代表 整个消息长度
lengthFieldOffset = 1 (这个二进制消息长度的字段位于消息的第1个字段HDR1之后，故偏移量为HDR1的字节数1）
lengthFieldLength = 2 （如题，2bytes为长度字段）
lengthAdjustment = -3 (（长度调整,13(长度字段 后面数据长度 HDR2+Actual Content）) - 16（长度字段数值16 [0x0010]） = -3)
initialBytesToStrip = 3 ( 跳过HDR1 + Length,保留HDR2 +Actual Content)
此Handler处理后的消息即下个Handler收到消息变为

                                             initialBytesToStrip = 3     nitialBytesToStrip = 0
 BEFORE DECODE (16 bytes)                    AFTER DECODE (13bytes)     AFTER DECODE (16bytes)   
+------+--------+------+----------------+   +------+----------------+   +------+--------+------+----------------+ 
| HDR1 | Length | HDR2 | Actual Content |-->| HDR2 | Actual Content |-->| HDR1 | Length | HDR2 | Actual Content |
| 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |   | 0xFE | "HELLO, WORLD" |   | 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |
+------+--------+------+----------------+   +------+----------------+   +------+--------+------+----------------+ 

3.2.1.4 StringDecoder

将收到到ByteBuf转化为String,

• 使用前提
  1、保证上一个Handler的处理结果为Bytebuf
  2、保证之前的Handler已经将数据分割成一条消息（即无粘包、半包现象）
• 输入 ByteBuf
• 输出：String
• 构造函数

 public StringDecoder() {
        this(Charset.defaultCharset());
    }
 //Creates a new instance with the specified character set.   
 public StringDecoder(Charset charset) {
     this.charset = ObjectUtil.checkNotNull(charset, "charset");
 }
   

• 使用方法

 ch.pipeline().addLast(new StringDecoder());

3.2.1.5 SimpleChannelInboundHandler

只处理特定类型消息的 Handler

• 输入 指定类型的数据
• 输出类型 无要求
• 使用方法，自定义的代码逻辑在 channelRead0 方法中

ch.pipeline().addLast(new SimpleChannelInboundHandler<Message>() {
 @Override
 protected void channelRead0(ChannelHandlerContext ctx, Message msg) throws Exception {
     //处理逻辑

     //如果需要向后续传递msg 处理
     ctx.fireChannelRead(msg);
 }
});

3.2.2 In&Out Handler

3.2.2.1 LoggingHandler

记录所有事件的日志

  /**
     * Creates a new instance whose logger name is the fully qualified class
     * name of the instance with hex dump enabled.
     */
   public LoggingHandler() {
        this(DEFAULT_LEVEL);
    }
    /**
     * Creates a new instance whose logger name is the fully qualified class
     * name of the instance.
     *
     * @param format Format of ByteBuf dumping
     */
    public LoggingHandler(ByteBufFormat format) {
        this(DEFAULT_LEVEL, format);
    }

    /**
     * Creates a new instance whose logger name is the fully qualified class
     * name of the instance.
     *
     * @param level the log level
     */
    public LoggingHandler(LogLevel level) {
        this(level, ByteBufFormat.HEX_DUMP);
    }
 //更多构造函数见源代码

• 使用方法

ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));

3.2.2.2 ByteToMessageCodec

Bytebuf 与 特定类型对象互转

• 使用方法

    //自定义类实现ByteToMessageCodec,Message为需要转化的类型
    public static class CustomMessageCodec extends ByteToMessageCodec<Message>{
        @Override
        protected void encode(ChannelHandlerContext ctx, Message msg, ByteBuf out) throws Exception {
            //out write
            //todo msg 转ByteBuf
        }
        @Override
        protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
            //in read
            //todo Bytebuf 转
        }
    }
    //
    ch.pipeline().addLast(new CustomMessageCodec ());
    

3.2.2.3 MessageToMessageCodec

自定义类编解码。通常和ByteToMessageCodec一样，用于 Bytebuf 与 特定类型对象互转

• 使用方法

 public class CustomMessageToMessageCode extends MessageToMessageCodec<ByteBuf, Message> {
    @Override
    protected void encode(ChannelHandlerContext ctx, Message msg, List<Object> out) throws Exception {
        //out write
        ByteBuf byteBuf = ctx.alloc().buffer();
        //todo Message 转 ByteBuf
        out.add(byteBuf);
    }

    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf msg, List<Object> out) throws Exception {
        //in  read
        //todo ByteBuf 转 Message
        Message message=null;
        out.add(message);
        //释放ByteBuf
        ReferenceCountUtil.release(msg);
    }
}
//
    ch.pipeline().addLast(new CustomMessageToMessageCode());
    

3.4 ByteBuf

是对字节数据的封装

3.4.1 创建

ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer(10);
log(buffer);

上面代码创建了一个默认的 ByteBuf（池化基于直接内存的 ByteBuf），初始容量是 10

输出

read index:0 write index:0 capacity:10

其中 log 方法参考如下

private static void log(ByteBuf buffer) {
    int length = buffer.readableBytes();
    int rows = length / 16 + (length % 15 == 0 ? 0 : 1) + 4;
    StringBuilder buf = new StringBuilder(rows * 80 * 2)
        .append("read index:").append(buffer.readerIndex())
        .append(" write index:").append(buffer.writerIndex())
        .append(" capacity:").append(buffer.capacity())
        .append(NEWLINE);
    appendPrettyHexDump(buf, buffer);
    System.out.println(buf.toString());
}

3.4.2 直接内存 vs 堆内存

可以使用下面的代码来创建池化基于堆的 ByteBuf

ByteBuf buffer = ByteBufAllocator.DEFAULT.heapBuffer(10);

也可以使用下面的代码来创建池化基于直接内存的 ByteBuf

ByteBuf buffer = ByteBufAllocator.DEFAULT.directBuffer(10);

• 直接内存创建和销毁的代价昂贵，但读写性能高（少一次内存复制），适合配合池化功能一起用
• 直接内存对 GC 压力小，因为这部分内存不受 JVM 垃圾回收的管理，但也要注意及时主动释放

3.4.3 池化 vs 非池化

池化的最大意义在于可以重用 ByteBuf，优点有

• 没有池化，则每次都得创建新的 ByteBuf 实例，这个操作对直接内存代价昂贵，就算是堆内存，也会增加 GC 压力
• 有了池化，则可以重用池中 ByteBuf 实例，并且采用了与 jemalloc 类似的内存分配算法提升分配效率
• 高并发时，池化功能更节约内存，减少内存溢出的可能

池化功能是否开启，可以通过下面的系统环境变量来设置

-Dio.netty.allocator.type={unpooled|pooled}

• 4.1 以后，非 Android 平台默认启用池化实现，Android 平台启用非池化实现
• 4.1 之前，池化功能还不成熟，默认是非池化实现

3.4.4 组成

ByteBuf 由四部分组成,最开始读写指针都在 0 位置

3.4.5 写入

方法列表，省略一些不重要的方法

方法签名	含义	备注
writeBoolean(boolean value)	写入 boolean 值	用一字节 01|00 代表 true|false
writeByte(int value)	写入 byte 值
writeShort(int value)	写入 short 值
writeInt(int value)	写入 int 值	Big Endian，即 0x250，写入后 00 00 02 50
writeIntLE(int value)	写入 int 值	Little Endian，即 0x250，写入后 50 02 00 00
writeLong(long value)	写入 long 值
writeChar(int value)	写入 char 值
writeFloat(float value)	写入 float 值
writeDouble(double value)	写入 double 值
writeBytes(ByteBuf src)	写入 netty 的 ByteBuf
writeBytes(byte[] src)	写入 byte[]
writeBytes(ByteBuffer src)	写入 nio 的 ByteBuffer
int writeCharSequence(CharSequence sequence, Charset charset)	写入字符串

注意

• 这些方法的未指明返回值的，其返回值都是 ByteBuf，意味着可以链式调用
• 网络传输，默认习惯是 Big Endian(大端字节序，高位在前)
  先写入 4 个字节

buffer.writeBytes(new byte[]{1, 2, 3, 4});
log(buffer);

结果是

read index:0 write index:4 capacity:10
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04                                     |....            |
+--------+-------------------------------------------------+----------------+

再写入一个 int 整数，也是 4 个字节

buffer.writeInt(5);
log(buffer);

结果是

read index:0 write index:8 capacity:10
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 00 00 00 05                         |........        |
+--------+-------------------------------------------------+----------------+

还有一类方法是 set 开头的一系列方法，也可以写入数据，但不会改变写指针位置

3.4.6 扩容

再写入一个 int 整数时，容量不够了（初始容量是 10），这时会引发扩容

buffer.writeInt(6);
log(buffer);

扩容规则是

• 如何写入后数据大小未超过 512，则选择下一个 16 的整数倍，例如写入后大小为 12 ，则扩容后 capacity 是 16
• 如果写入后数据大小超过 512，则选择下一个 $2^n$ ，例如写入后大小为 513，则扩容后 capacity 是 $2^{10}=1024$（2^9=512 已经不够了）
• 扩容不能超过 max capacity 会报错

结果是

read index:0 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 00 00 00 05 00 00 00 06             |............    |
+--------+-------------------------------------------------+----------------+

3.4.7 读取

例如读了 4 次，每次一个字节

System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
System.out.println(buffer.readByte());
log(buffer);

读过的内容，就属于废弃部分了，再读只能读那些尚未读取的部分

1
2
3
4
read index:4 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 05 00 00 00 06                         |........        |
+--------+-------------------------------------------------+----------------+

如果需要重复读取 int 整数 5，怎么办？

可以在 read 前先做个标记 mark

buffer.markReaderIndex();
System.out.println(buffer.readInt());
log(buffer);

结果

5
read index:8 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 06                                     |....            |
+--------+-------------------------------------------------+----------------+

这时要重复读取的话，重置到标记位置 reset

buffer.resetReaderIndex();
log(buffer);

这时

read index:4 write index:12 capacity:16
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 05 00 00 00 06                         |........        |
+--------+-------------------------------------------------+----------------+

还有种办法是采用 get 开头的一系列方法，这些方法不会改变 read index

3.4.8 retain & release

由于 Netty 中有堆外内存的 ByteBuf 实现，堆外内存最好是手动来释放，而不是等 GC 垃圾回收。

• UnpooledHeapByteBuf 使用的是 JVM 内存，只需等 GC 回收内存即可
• UnpooledDirectByteBuf 使用的就是直接内存了，需要特殊的方法来回收内存
• PooledByteBuf 和它的子类使用了池化机制，需要更复杂的规则来回收内存

回收内存的源码实现，请关注下面方法的不同实现

protected abstract void deallocate()

Netty 这里采用了引用计数法来控制回收内存，每个 ByteBuf 都实现了 ReferenceCounted 接口

• 每个 ByteBuf 对象的初始计数为 1
• 调用 release 方法计数减 1，如果计数为 0，ByteBuf 内存被回收
• 调用 retain 方法计数加 1，表示调用者没用完之前，其它 handler 即使调用了 release 也不会造成回收
• 当计数为 0 时，底层内存会被回收，这时即使 ByteBuf 对象还在，其各个方法均无法正常使用

谁来负责 release 呢？

不是我们想象的（一般情况下）

ByteBuf buf = ...
try {
    ...
} finally {
    buf.release();
}

请思考，因为 pipeline 的存在，一般需要将 ByteBuf 传递给下一个 ChannelHandler，如果在 finally 中 release 了，就失去了传递性（当然，如果在这个 ChannelHandler 内这个 ByteBuf 已完成了它的使命，那么便无须再传递）

基本规则是，谁是最后使用者，谁负责 release，详细分析如下

• 起点，对于 NIO 实现来讲，在 io.netty.channel.nio.AbstractNioByteChannel.NioByteUnsafe#read 方法中首次创建 ByteBuf 放入 pipeline（line 163 pipeline.fireChannelRead(byteBuf)）
• 入站 ByteBuf 处理原则
  • 对原始 ByteBuf 不做处理，调用 ctx.fireChannelRead(msg) 向后传递，这时无须 release
  • 将原始 ByteBuf 转换为其它类型的 Java 对象，这时 ByteBuf 就没用了，必须 release
  • 如果不调用 ctx.fireChannelRead(msg) 向后传递，那么也必须 release
  • 注意各种异常，如果 ByteBuf 没有成功传递到下一个 ChannelHandler，必须 release
  • 假设消息一直向后传，那么 TailContext 会负责释放未处理消息（原始的 ByteBuf）
• 出站 ByteBuf 处理原则
  • 出站消息最终都会转为 ByteBuf 输出，一直向前传，由 HeadContext flush 后 release
• 异常处理原则
  • 有时候不清楚 ByteBuf 被引用了多少次，但又必须彻底释放，可以循环调用 release 直到返回 true

TailContext 释放未处理消息逻辑

// io.netty.channel.DefaultChannelPipeline#onUnhandledInboundMessage(java.lang.Object)
protected void onUnhandledInboundMessage(Object msg) {
    try {
        logger.debug(
            "Discarded inbound message {} that reached at the tail of the pipeline. " +
            "Please check your pipeline configuration.", msg);
    } finally {
        ReferenceCountUtil.release(msg);
    }
}

具体代码

// io.netty.util.ReferenceCountUtil#release(java.lang.Object)
public static boolean release(Object msg) {
    if (msg instanceof ReferenceCounted) {
        return ((ReferenceCounted) msg).release();
    }
    return false;
}

3.4.9 slice

• slice(相当于slice(buf.readerIndex(), buf.readableBytes())
• slice(int index, int length) 指定起始位置和长度
• 切片后的新 ByteBuf 并没有分配新的内存存储数据，还是使用原始 ByteBuf 的内存
• 切片返回的ByteBuf 拥有独立readerIndex，writerIndex，新的ByteBuf 的readerIndex 等于0，writerIndex 为length-1，maxCapacity 为length, 因此新的ByteBuf不能再调用writeXX 往里写新数据

3.4.9 duplicate

• 新 ByteBuf 并没有分配新的内存存储数据，还是使用原始 ByteBuf 的内存
• 新老的ByteBuf所有属性值都相同， 新ByteBuf 拥有独立readerIndex，writerIndex

3.4.10 copy

• copy(相当于copy(buf.readerIndex(), buf.readableBytes())
• copy(int index, int length) 指定起始位置和长度
• 新 ByteBuf 重新分配内存分配数据，拷贝[index,index+length)之间的数据到新的ByteBuf 的[0,length)中
• 新的ByteBuf 的readerIndex 等于0，writerIndex 为length-1，maxCapacity 为 Integer.MAX_VALUE

3.4.10 CompositeByteBuf

CompositeByteBuf 是一个组合的 ByteBuf，它内部维护了一个 Component 数组，每个 Component 管理一个 ByteBuf，记录了这个 ByteBuf 相对于整体偏移量等信息，代表着整体中某一段的数据。

• 优点，对外是一个虚拟视图，组合这些 ByteBuf 不会产生内存复制
• 缺点，复杂了很多，多次操作会带来性能的损耗

CompositeByteBuf buf3 = ByteBufAllocator.DEFAULT.compositeBuffer();
// true 表示增加新的 ByteBuf 自动递增 write index, 否则 write index 会始终为 0
buf3.addComponents(true, buf1, buf2);

3.4.10 Unpooled

Unpooled 是一个工具类，类如其名，提供了非池化的 ByteBuf 创建、组合、复制等操作

4 Netty 连接管理

4.1 服务端 客户端 接入、断开、异常断开

        socketChannel.pipeline().addLast(new ChannelInboundHandlerAdapter() {
           //客户端接入
           @Override
           public void channelActive(ChannelHandlerContext ctx) throws Exception {
               //处理接入逻辑
               super.channelActive(ctx);
           }

           //客户端正常断开
           @Override
           public void channelInactive(ChannelHandlerContext ctx) throws Exception {
               //处理断开逻辑
               super.channelInactive(ctx);
           }

           @Override
           public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
             //客户端异常断开（杀死进程） 会抛出 Connection reset，exceptionCaught后会回调 channelInactive
             if(cause.getMessage().contains("Connection reset")){
                    }
           }
       });

如果pipeline 中 带有exceptionCaught的ChannelHandler 之前 有 LoggingHandler，连接异常断开 会打印一条错误日志

10:18:53.126 [nioEventLoopGroup-3-7] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0x57122f3c, L:/192.168.5.227:60000 - R:/192.168.5.227:63162] EXCEPTION: java.net.SocketException: Connection reset
java.net.SocketException: Connection reset
	at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
	at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:254)
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840)

4.2 空闲检测

原因

• 网络设备出现故障，例如网卡，机房等，底层的 TCP 连接已经断开了，但应用程序没有感知到，仍然占用着资源。
• 公网网络不稳定，出现丢包。如果连续出现丢包，这时现象就是客户端数据发不出去，服务端也一直收不到数据，就这么一直耗着
• 应用程序线程阻塞，无法进行数据读写

问题

• 假死的连接占用的资源不能自动释放
• 向假死的连接发送数据，得到的反馈是发送超时

服务器端解决

• 怎么判断客户端连接是否假死呢？如果能收到客户端数据，说明没有假死。因此策略就可以定为，每隔一段时间就检查这段时间内是否接收到客户端数据，没有就可以判定为连接假死(注意客户端如果真没发送数据，一样会触发，所以这个方案还需要客户端配合 )

// 用来判断是不是 读空闲时间过长，或 写空闲时间过长
// 5s 内如果没有收到 channel 的数据，会触发一个 IdleState#READER_IDLE 事件
ch.pipeline().addLast(new IdleStateHandler(5, 0, 0));
// ChannelDuplexHandler 可以同时作为入站和出站处理器
ch.pipeline().addLast(new ChannelDuplexHandler() {
    // 用来触发特殊事件
    @Override
    public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception{
        IdleStateEvent event = (IdleStateEvent) evt;
        // 触发了读空闲事件
        if (event.state() == IdleState.READER_IDLE) {
            log.debug("已经 5s 没有读到数据了");
            //ctx.channel().close();
        }
    }
});

5 Netty参数(ChannelOption 项）的含义已及使用的场景

5.1 ChannelOption.SO_BACKLOG

属于 ServerSocketChannal 参数，
ChannelOption.SO_BACKLOG对应的是tcp/ip协议listen函数中的backlog参数，函数listen(int socketfd,int backlog)用来初始化服务端可连接队列，
服务端处理客户端连接请求是顺序处理的，所以同一时间只能处理一个客户端连接，多个客户端来的时候，服务端将不能处理的客户端连接请求放在队列中等待处理，backlog参数指定了队列的大小

1. 第一次握手，client 发送 SYN 到 server，状态修改为 SYN_SEND，server 收到，状态改变为 SYN_REVD，并将该请求放入 sync queue 队列
2. 第二次握手，server 回复 SYN + ACK 给 client，client 收到，状态改变为 ESTABLISHED，并发送 ACK 给 server
3. 第三次握手，server 收到 ACK，状态改变为 ESTABLISHED，将该请求从 sync queue 放入 accept queue

其中

• 在 linux 2.2 之前，backlog 大小包括了两个队列的大小，在 2.2 之后，分别用下面两个参数来控制

• sync queue - 半连接队列

  • 大小通过 /proc/sys/net/ipv4/tcp_max_syn_backlog 指定，在 syncookies 启用的情况下，逻辑上没有最大值限制，这个设置便被忽略

• accept queue - 全连接队列

  • 其大小通过 /proc/sys/net/core/somaxconn 指定，在使用 listen 函数时，内核会根据传入的 backlog 参数与系统参数，取二者的较小值
  • 如果 accpet queue 队列满了，server 将发送一个拒绝连接的错误信息到 client
  • server 端执行accept方法时，会从accpet queue队列提取一个连接处理

  调试
  服务端将 ChannelOption.SO_BACKLOG 设置一个较小值 ，通过在io.netty.channel.nio.NioEventLoop#processSelectedKey 方法打断点阻止accept，然后多个客户端接入即可重现

5.2 ChannelOption.TCP_NODELAY

ChannelOption.TCP_NODELAY参数对应于套接字选项中的TCP_NODELAY,该参数的使用与Nagle算法有关
Nagle算法是将小的数据包组装为更大的帧然后进行发送，而不是输入一次发送一次,因此在数据包不足的时候会等待其他数据的到了，组装成大的数据包进行发送，虽然该方式有效提高网络的有效
负载，但是却造成了延时，而该参数的作用就是禁止使用Nagle算法，使用于小数据即时传输，于TCP_NODELAY相对应的是TCP_CORK，该选项是需要等到发送的数据量最大的时候，一次性发送数据，适用于文件传输。

• 属于 SocketChannal 参数
• 默认值false,即使用Nagle算法，建议改为true
  • 客户端 bootstrap…option(ChannelOption.TCP_NODELAY, true)
  • 服务端 socketChannel.config().setTcpNoDelay(true)

5.3 ChannelOption.SO_SNDBUF和ChannelOption.SO_RCVBUF

ChannelOption.SO_SNDBUF参数对应于套接字选项中的SO_SNDBUF，ChannelOption.SO_RCVBUF参数对应于套接字选项中的SO_RCVBUF这两个参数用于操作接收缓冲区和发送缓冲区的大小，接收缓冲区用于保存网络协议站内收到的数据，直到应用程序读取成功，发送缓冲区用于保存发送数据，直到发送成功。
　　　　不建议修改，而是由操作系统来智能控制这两个参数的大小

6 附录

6.1 粘包、半包

粘包

• 现象，1发送 abc ，2发送 def，接收以下全部接收 abcdef
• 原因
  • 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）
  • 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包
  • Nagle 算法：会造成粘包

半包

• 现象，发送 abcdef，1接收 abc ，2接收 def

• 原因

  • 滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包
  • MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包

本质是因为 TCP 是流式协议，消息无边界

滑动窗口

• TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差
  

• 为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值
  

• 窗口实际就起到一个缓冲区的作用，同时也能起到流量控制的作用

  • 图中深色的部分即要发送的数据，高亮的部分即窗口
  • 窗口内的数据才允许被发送，当应答未到达前，窗口必须停止滑动
  • 如果 1001~2000 这个段的数据 ack 回来了，窗口就可以向前滑动
  • 接收方也会维护一个窗口，只有落在窗口内的数据才能允许接收

MSS 限制

• 链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如

• 以太网的 MTU 是 1500

• FDDI（光纤分布式数据接口）的 MTU 是 4352

• 本地回环地址的 MTU 是 65535 - 本地测试不走网卡

• MSS 是最大段长度（maximum segment size），它是 MTU 刨去 tcp 头和 ip 头后剩余能够作为数据传输的字节数

• ipv4 tcp 头占用 20 bytes，ip 头占用 20 bytes，因此以太网 MSS 的值为 1500 - 40 = 1460

• TCP 在传递大量数据时，会按照 MSS 大小将数据进行分割发送

• MSS 的值在三次握手时通知对方自己 MSS 的值，然后在两者之间选择一个小值作为 MSS

Nagle 算法

• 即使发送一个字节，也需要加入 tcp 头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由
• 该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
  • 如果 SO_SNDBUF 的数据达到 MSS，则需要发送
  • 如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭
  • 如果 TCP_NODELAY = true，则需要发送
  • 已发送的数据都收到 ack 时，则需要发送
  • 上述条件不满足，但发生超时（一般为 200ms）则需要发送
  • 除上述情况，延迟发送