maxdoop物联网平台中的粘包和半包解决方案

在网络传输中，粘包和半包应该是最常出现的问题，作为 Java 中最常使用的 NIO 网络框架 Netty，它又是如何解决的呢？今天就让我们来看看。

一、定义
TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，粘包和半包也就会在此时产生。

客户端给服务端发送了两条消息ABC和DEF，服务端这边的接收会有多少种情况呢？有可能是一次性收到了所有的消息ABCDEF，有可能是收到了三条消息AB、CD、EF。

上面所说的一次性收到了所有的消息ABCDEF，类似于粘包。如果客户端发送的包的大小比 TCP 的缓存容量小，并且 TCP 缓存可以存放多个包，那么客户端和服务端的一次通信就可能传递了多个包，这时候服务端从 TCP 缓存就可能一下读取了多个包，这种现象就叫粘包。

上面说的后面那种收到了三条消息AB、CD、EF，类似于半包。如果客户端发送的包的大小比 TCP 的缓存容量大，那么这个数据包就会被分成多个包，通过 Socket 多次发送到服务端，服务端第一次从接受缓存里面获取的数据，实际是整个包的一部分，这时候就产生了半包(半包不是说只收到了全包的一半，是说收到了全包的一部分)。

二、产生原因
其实从上面的定义，我们就可以大概知道产生的原因了。

粘包的主要原因：

发送方每次写入数据 < 套接字(Socket)缓冲区大小
接收方读取套接字(Socket)缓冲区数据不够及时
半包的主要原因：

发送方每次写入数据 > 套接字(Socket)缓冲区大小
发送的数据大于协议的 MTU (Maximum Transmission Unit，最大传输单元)，因此必须拆包
其实我们可以换个角度看待问题：

从收发的角度看，便是一个发送可能被多次接收，多个发送可能被一次接收。
从传输的角度看，便是一个发送可能占用多个传输包，多个发送可能共用一个传输包。
根本原因，其实是

TCP 是流式协议，消息无边界。

(PS ： UDP 虽然也可以一次传输多个包或者多次传输一个包，但每个消息都是有边界的，因此不会有粘包和半包问题。)

三、解决方法
就像上面说的，UDP 之所以不会产生粘包和半包问题，主要是因为消息有边界，因此，我们也可以采取类似的思路。

3.1、改成短连接
将 TCP 连接改成短连接，一个请求一个短连接。这样的话，建立连接到释放连接之间的消息即为传输的信息，消息也就产生了边界。

这样的方法就是十分简单，不需要在我们的应用中做过多修改。但缺点也就很明显了，效率低下，TCP 连接和断开都会涉及三次握手以及四次握手，每个消息都会涉及这些过程，十分浪费性能。

因此，并不推介这种方式。

3.2、封装成帧
封装成帧(Framing)，也就是原本发送消息的单位是缓冲大小，现在换成了帧，这样我们就可以自定义边界了。一般有4种方式：

固定长度

这种方式下，消息边界也就是固定长度即可。

优点就是实现很简单，缺点就是空间有极大的浪费，如果传递的消息中大部分都比较短，这样就会有很多空间是浪费的。

因此，这种方式一般也是不推介的。

分隔符

这种方式下，消息边界也就是分隔符本身。

优点是空间不再浪费，实现也比较简单。缺点是当内容本身出现分割符时需要转义，所以无论是发送还是接受，都需要进行整个内容的扫描。

因此，这种方式效率也不是很高，但可以尝试使用。

专门的 length 字段

这种方式，就有点类似 Http 请求中的 Content-Length，有一个专门的字段存储消息的长度。作为服务端，接受消息时，先解析固定长度的字段（length字段）获取消息总长度，然后读取后续内容。

优点是精确定位用户数据，内容也不用转义。缺点是长度理论上有限制，需要提前限制可能的最大长度从而定义长度占用字节数。

因此，十分推介用这种方式。

其他方式

其他方式就各不相同了，比如 JSON 可以看成是使用{}是否成对。这些优缺点就需要大家在各自的场景中进行衡量了。

四、Netty 中的实现
固定长度的拆包器 FixedLengthFrameDecoder，每个应用层数据包的都拆分成都是固定长度的大小
行拆包器 LineBasedFrameDecoder，每个应用层数据包，都以换行符作为分隔符，进行分割拆分
分隔符拆包器 DelimiterBasedFrameDecoder，每个应用层数据包，都通过自定义的分隔符，进行分割拆分
基于数据包长度的拆包器 LengthFieldBasedFrameDecoder，将应用层数据包的长度，作为接收端应用层数据包的拆分依据。按照应用层数据包的大小，拆包。这个拆包器，有一个要求，就是应用层协议中包含数据包的长度
4.1 FixedLengthFrameDecoder

       对于使用固定长度的粘包和拆包场景，可以使用FixedLengthFrameDecoder，该解码一器会每次读取固定长度的消息，如果当前读取到的消息不足指定长度，那么就会等待下一个消息到达后进行补足。其使用也比较简单，只需要在构造函数中指定每个消息的长度即可。这里需要注意的是，FixedLengthFrameDecoder只是一个解码一器，Netty也只提供了一个解码一器，这是因为对于解码是需要等待下一个包的进行补全的，代码相对复杂，而对于编码器，用户可以自行编写，因为编码时只需要将不足指定长度的部分进行补全即可。下面的示例中展示了如何使用FixedLengthFrameDecoder来进行粘包和拆包处理：

public class EchoServer {
 
  public void bind(int port) throws InterruptedException {
    EventLoopGroup bossGroup = new NioEventLoopGroup();
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    try {
      ServerBootstrap bootstrap = new ServerBootstrap();
      bootstrap.group(bossGroup, workerGroup)
        .channel(NioServerSocketChannel.class)
        .option(ChannelOption.SO_BACKLOG, 1024)
        .handler(new LoggingHandler(LogLevel.INFO))
        .childHandler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {
            // 这里将FixedLengthFrameDecoder添加到pipeline中，指定长度为20
            ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
            // 将前一步解码得到的数据转码为字符串
            ch.pipeline().addLast(new StringDecoder());
            // 这里FixedLengthFrameEncoder是我们自定义的，用于将长度不足20的消息进行补全空格
            ch.pipeline().addLast(new FixedLengthFrameEncoder(20));
            // 最终的数据处理
            ch.pipeline().addLast(new EchoServerHandler());
          }
        });
 
      ChannelFuture future = bootstrap.bind(port).sync();
      future.channel().closeFuture().sync();
    } finally {
      bossGroup.shutdownGracefully();
      workerGroup.shutdownGracefully();
    }
  }
 
  public static void main(String[] args) throws InterruptedException {
    new EchoServer().bind(8080);
  }
}
       上面的pipeline中，对于入栈数据，这里主要添加了FixedLengthFrameDecoder和StringDecoder，前面一个用于处理固定长度的消息的粘包和拆包问题，第二个则是将处理之后的消息转换为字符串。最后由EchoServerHandler处理最终得到的数据，处理完成后，将处理得到的数据交由FixedLengthFrameEncoder处理，该编码器是我们自定义的实现，主要作用是将长度不足20的消息进行空格补全。下面是FixedLengthFrameEncoder的实现代码：

public class FixedLengthFrameEncoder extends MessageToByteEncoder<String> {
  private int length;
 
  public FixedLengthFrameEncoder(int length) {
    this.length = length;
  }
 
  @Override
  protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out)
      throws Exception {
    // 对于超过指定长度的消息，这里直接抛出异常
    if (msg.length() > length) {
      throw new UnsupportedOperationException(
          "message length is too large, it's limited " + length);
    }
 
    // 如果长度不足，则进行补全
    if (msg.length() < length) {
      msg = addSpace(msg);
    }
 
    ctx.writeAndFlush(Unpooled.wrappedBuffer(msg.getBytes()));
  }
 
  // 进行空格补全
  private String addSpace(String msg) {
    StringBuilder builder = new StringBuilder(msg);
    for (int i = 0; i < length - msg.length(); i++) {
      builder.append(" ");
    }
 
    return builder.toString();
  }
}
       这里FixedLengthFrameEncoder实现了decode()方法，在该方法中，主要是将消息长度不足20的消息进行空格补全。EchoServerHandler的作用主要是打印接收到的消息，然后发送响应给客户端：

public class EchoServerHandler extends SimpleChannelInboundHandler<String> {
 
  @Override
  protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
    System.out.println("server receives message: " + msg.trim());
    ctx.writeAndFlush("hello client!");
  }
}
       对于客户端，其实现方式基本与服务端的使用方式类似，只是在最后进行消息发送的时候与服务端的处理方式不同。如下是客户端EchoClient的代码：

public class EchoClient {
 
  public void connect(String host, int port) throws InterruptedException {
    EventLoopGroup group = new NioEventLoopGroup();
    try {
      Bootstrap bootstrap = new Bootstrap();
      bootstrap.group(group)
        .channel(NioSocketChannel.class)
        .option(ChannelOption.TCP_NODELAY, true)
        .handler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {
            // 对服务端发送的消息进行粘包和拆包处理，由于服务端发送的消息已经进行了空格补全，
            // 并且长度为20，因而这里指定的长度也为20
            ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
            // 将粘包和拆包处理得到的消息转换为字符串
            ch.pipeline().addLast(new StringDecoder());
            // 对客户端发送的消息进行空格补全，保证其长度为20
            ch.pipeline().addLast(new FixedLengthFrameEncoder(20));
            // 客户端发送消息给服务端，并且处理服务端响应的消息
            ch.pipeline().addLast(new EchoClientHandler());
          }
        });
 
      ChannelFuture future = bootstrap.connect(host, port).sync();
      future.channel().closeFuture().sync();
    } finally {
      group.shutdownGracefully();
    }
  }
 
  public static void main(String[] args) throws InterruptedException {
    new EchoClient().connect("127.0.0.1", 8080);
  }
}
       对于客户端而言，其消息的处理流程其实与服务端是相似的，对于入站消息，需要对其进行粘包和拆包处理，然后将其转码为字符串，对于出站消息，则需要将长度不足20的消息进行空格补全。客户端与服务端处理的主要区别在于最后的消息处理handler不一样，也即这里的EchoClientHandler，如下是该handler的源码：

public class EchoClientHandler extends SimpleChannelInboundHandler<String> {
 
  @Override
  protected void channelRead0(ChannelHandlerContext ctx, String msg) throws Exception {
    System.out.println("client receives message: " + msg.trim());
  }
 
  @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.writeAndFlush("hello server!");
  }
}
       这里客户端的处理主要是重写了channelActive()和channelRead0()两个方法，这两个方法的主要作用在于，channelActive()会在客户端连接上服务器时执行，也就是说，其连上服务器之后就会往服务器发送消息。而channelRead0()主要是在服务器发送响应给客户端时执行，这里主要是打印服务器的响应消息。对于服务端而言，前面我们我们可以看到，EchoServerHandler只重写了channelRead0()方法，这是因为服务器只需要等待客户端发送消息过来，然后在该方法中进行处理，处理完成后直接将响应发送给客户端。如下是分别启动服务端和客户端之后控制台打印的数据：

// server
server receives message: hello server!
// client
client receives message: hello client!
4.2 LineBasedFrameDecoder与DelimiterBasedFrameDecoder

       对于通过分隔符进行粘包和拆包问题的处理，Netty提供了两个编解码的类，LineBasedFrameDecoder和DelimiterBasedFrameDecoder。这里LineBasedFrameDecoder的作用主要是通过换行符，即\n或者\r\n对数据进行处理；而DelimiterBasedFrameDecoder的作用则是通过用户指定的分隔符对数据进行粘包和拆包处理。同样的，这两个类都是解码一器类，而对于数据的编码，也即在每个数据包最后添加换行符或者指定分割符的部分需要用户自行进行处理。这里以DelimiterBasedFrameDecoder为例进行讲解，如下是EchoServer中使用该类的代码片段，其余部分与前面的例子中的完全一致：

@Override
protected void initChannel(SocketChannel ch) throws Exception {
    String delimiter = "_$";
    // 将delimiter设置到DelimiterBasedFrameDecoder中，经过该解码一器进行处理之后，源数据将会
    // 被按照_$进行分隔，这里1024指的是分隔的最大长度，即当读取到1024个字节的数据之后，若还是未
    // 读取到分隔符，则舍弃当前数据段，因为其很有可能是由于码流紊乱造成的
    ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024,
        Unpooled.wrappedBuffer(delimiter.getBytes())));
    // 将分隔之后的字节数据转换为字符串数据
    ch.pipeline().addLast(new StringDecoder());
    // 这是我们自定义的一个编码器，主要作用是在返回的响应数据最后添加分隔符
    ch.pipeline().addLast(new DelimiterBasedFrameEncoder(delimiter));
    // 最终处理数据并且返回响应的handler
    ch.pipeline().addLast(new EchoServerHandler());
}
       上面pipeline的设置中，添加的解码一器主要有DelimiterBasedFrameDecoder和StringDecoder，经过这两个处理器处理之后，接收到的字节流就会被分隔，并且转换为字符串数据，最终交由EchoServerHandler处理。这里DelimiterBasedFrameEncoder是我们自定义的编码器，其主要作用是在返回的响应数据之后添加分隔符。如下是该编码器的源码：

public class DelimiterBasedFrameEncoder extends MessageToByteEncoder<String> {
 
  private String delimiter;
 
  public DelimiterBasedFrameEncoder(String delimiter) {
    this.delimiter = delimiter;
  }
 
  @Override
  protected void encode(ChannelHandlerContext ctx, String msg, ByteBuf out) 
      throws Exception {
    // 在响应的数据后面添加分隔符
    ctx.writeAndFlush(Unpooled.wrappedBuffer((msg + delimiter).getBytes()));
  }
}
       对于客户端而言，这里的处理方式与服务端类似，其pipeline的添加方式如下：

@Override
protected void initChannel(SocketChannel ch) throws Exception {
    String delimiter = "_$";
    // 对服务端返回的消息通过_$进行分隔，并且每次查找的最大大小为1024字节
    ch.pipeline().addLast(new DelimiterBasedFrameDecoder(1024, 
        Unpooled.wrappedBuffer(delimiter.getBytes())));
    // 将分隔之后的字节数据转换为字符串
    ch.pipeline().addLast(new StringDecoder());
    // 对客户端发送的数据进行编码，这里主要是在客户端发送的数据最后添加分隔符
    ch.pipeline().addLast(new DelimiterBasedFrameEncoder(delimiter));
    // 客户端发送数据给服务端，并且处理从服务端响应的数据
    ch.pipeline().addLast(new EchoClientHandler());
}
       这里客户端的处理方式与服务端基本一致，关于这里没展示的代码，其与示例一中的代码完全一致，这里则不予展示。

4.3 LengthFieldBasedFrameDecoder与LengthFieldPrepender

       这里LengthFieldBasedFrameDecoder与LengthFieldPrepender需要配合起来使用，其实本质上来讲，这两者一个是解码，一个是编码的关系。它们处理粘拆包的主要思想是在生成的数据包中添加一个长度字段，用于记录当前数据包的长度。LengthFieldBasedFrameDecoder会按照参数指定的包长度偏移量数据对接收到的数据进行解码，从而得到目标消息体数据；而LengthFieldPrepender则会在响应的数据前面添加指定的字节数据，这个字节数据中保存了当前消息体的整体字节数据长度。LengthFieldBasedFrameDecoder的解码过程如下图所示：

       LengthFieldPrepender的编码过程如下图所示：

       关于LengthFieldBasedFrameDecoder，这里需要对其构造函数参数进行介绍：

maxFrameLength：指定了每个包所能传递的最大数据包大小；
lengthFieldOffset：指定了长度字段在字节码中的偏移量；
lengthFieldLength：指定了长度字段所占用的字节长度；
lengthAdjustment：对一些不仅包含有消息头和消息体的数据进行消息头的长度的调整，这样就可以只得到消息体的数据，这里的lengthAdjustment指定的就是消息头的长度；
initialBytesToStrip：对于长度字段在消息头中间的情况，可以通过initialBytesToStrip忽略掉消息头以及长度字段占用的字节。
       这里我们以json序列化为例对LengthFieldBasedFrameDecoder和LengthFieldPrepender的使用方式进行讲解。如下是EchoServer的源码：

public class EchoServer {
 
  public void bind(int port) throws InterruptedException {
    EventLoopGroup bossGroup = new NioEventLoopGroup();
    EventLoopGroup workerGroup = new NioEventLoopGroup();
    try {
      ServerBootstrap bootstrap = new ServerBootstrap();
      bootstrap.group(bossGroup, workerGroup)
        .channel(NioServerSocketChannel.class)
        .option(ChannelOption.SO_BACKLOG, 1024)
        .handler(new LoggingHandler(LogLevel.INFO))
        .childHandler(new ChannelInitializer<SocketChannel>() {
          @Override
          protected void initChannel(SocketChannel ch) throws Exception {
            // 这里将LengthFieldBasedFrameDecoder添加到pipeline的首位，因为其需要对接收到的数据
            // 进行长度字段解码，这里也会对数据进行粘包和拆包处理
            ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2));
            // LengthFieldPrepender是一个编码器，主要是在响应字节数据前面添加字节长度字段
            ch.pipeline().addLast(new LengthFieldPrepender(2));
            // 对经过粘包和拆包处理之后的数据进行json反序列化，从而得到User对象
            ch.pipeline().addLast(new JsonDecoder());
            // 对响应数据进行编码，主要是将User对象序列化为json
            ch.pipeline().addLast(new JsonEncoder());
            // 处理客户端的请求的数据，并且进行响应
            ch.pipeline().addLast(new EchoServerHandler());
          }
        });
 
      ChannelFuture future = bootstrap.bind(port).sync();
      future.channel().closeFuture().sync();
    } finally {
      bossGroup.shutdownGracefully();
      workerGroup.shutdownGracefully();
    }
  }
 
  public static void main(String[] args) throws InterruptedException {
    new EchoServer().bind(8080);
  }
}

       这里EchoServer主要是在pipeline中添加了两个编码器和两个解码一器，编码器主要是负责将响应的User对象序列化为json对象，然后在其字节数组前面添加一个长度字段的字节数组；解码一器主要是对接收到的数据进行长度字段的解码，然后将其反序列化为一个User对象。下面是JsonDecoder的源码：

public class JsonDecoder extends MessageToMessageDecoder<ByteBuf> {
 
  @Override
  protected void decode(ChannelHandlerContext ctx, ByteBuf buf, List<Object> out) 
      throws Exception {
    byte[] bytes = new byte[buf.readableBytes()];
    buf.readBytes(bytes);
    User user = JSON.parseObject(new String(bytes, CharsetUtil.UTF_8), User.class);
    out.add(user);
  }
}
       JsonDecoder首先从接收到的数据流中读取字节数组，然后将其反序列化为一个User对象。下面我们看看JsonEncoder的源码：

public class JsonEncoder extends MessageToByteEncoder<User> {
 
  @Override
  protected void encode(ChannelHandlerContext ctx, User user, ByteBuf buf)
      throws Exception {
    String json = JSON.toJSONString(user);
    ctx.writeAndFlush(Unpooled.wrappedBuffer(json.getBytes()));
  }
}
       JsonEncoder将响应得到的User对象转换为一个json对象，然后写入响应中。对于EchoServerHandler，其主要作用就是接收客户端数据，并且进行响应，如下是其源码：

public class EchoServerHandler extends SimpleChannelInboundHandler<User> {
 
  @Override
  protected void channelRead0(ChannelHandlerContext ctx, User user) throws Exception {
    System.out.println("receive from client: " + user);
    ctx.write(user);
  }
}
       对于客户端，其主要逻辑与服务端的基本类似，这里主要展示其pipeline的添加方式，以及最后发送请求，并且对服务器响应进行处理的过程：

@Override
protected void initChannel(SocketChannel ch) throws Exception {
    ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 0, 2, 0, 2));
    ch.pipeline().addLast(new LengthFieldPrepender(2));
    ch.pipeline().addLast(new JsonDecoder());
    ch.pipeline().addLast(new JsonEncoder());
    ch.pipeline().addLast(new EchoClientHandler());
}
public class EchoClientHandler extends SimpleChannelInboundHandler<User> {
 
  @Override
  public void channelActive(ChannelHandlerContext ctx) throws Exception {
    ctx.write(getUser());
  }
 
  private User getUser() {
    User user = new User();
    user.setAge(27);
    user.setName("zhangxufeng");
    return user;
  }
 
  @Override
  protected void channelRead0(ChannelHandlerContext ctx, User user) throws Exception {
    System.out.println("receive message from server: " + user);
  }
}

       这里客户端首先会在连接上服务器时，往服务器发送一个User对象数据，然后在接收到服务器响应之后，会打印服务器响应的数据。

4.4 自定义粘包与拆包器

       对于粘包与拆包问题，其实前面三种基本上已经能够满足大多数情形了，但是对于一些更加复杂的协议，可能有一些定制化的需求。对于这些场景，其实本质上，我们也不需要手动从头开始写一份粘包与拆包处理器，而是通过继承LengthFieldBasedFrameDecoder和LengthFieldPrepender来实现粘包和拆包的处理。

       如果用户确实需要不通过继承的方式实现自己的粘包和拆包处理器，这里可以通过实现MessageToByteEncoder和ByteToMessageDecoder来实现。这里MessageToByteEncoder的作用是将响应数据编码为一个ByteBuf对象，而ByteToMessageDecoder则是将接收到的ByteBuf数据转换为某个对象数据。通过实现这两个抽象类，用户就可以达到实现自定义粘包和拆包处理的目的。如下是这两个类及其抽象方法的声明：

public abstract class ByteToMessageDecoder extends ChannelInboundHandlerAdapter {
    protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) 
        throws Exception;
}
public abstract class MessageToByteEncoder<I> extends ChannelOutboundHandlerAdapter {
    protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) 
        throws Exception;