前言
上一篇我们介绍了如果使用Netty来开发一个简单的服务端和客户端,接下来我们来讨论如何使用解码器来解决TCP的粘包和拆包问题
TCP为什么会粘包/拆包
我们知道,TCP是以一种流的方式来进行网络转播的,当tcp三次握手简历通信后,客户端服务端之间就建立了一种通讯管道,我们可以想象成自来水管道,流出来的水是连城一片的,是没有分界线的。
TCP底层并不了解上层的业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分。
所以对于我们应用层而言。我们直观是发送一个个连续完整TCP数据包的,而在底层就可能会出现将一个完整的TCP拆分成多个包发送或者将多个包封装成一个大的数据包发送。
这就是所谓的TCP粘包和拆包。
当发生TCP粘包/拆包会发生什么情况
我们举一个简单例子说明:
客户端向服务端发送两个数据包:第一个内容为 123;第二个内容为456。服务端接受一个数据并做相应的业务处理(这里就是打印接受数据加一个逗号)。
那么服务端输出结果将会出现下面四种情况
服务端响应结果 | 结论 |
---|---|
123,456, | 正常接收,没有发生粘包和拆包 |
123456, | 异常接收,发生tcp粘包 |
123,4,56, | 异常接收,发生tcp拆包 |
12,3456, | 异常接收,发生tcp拆包和粘包 |
如何解决
主流的协议解决方案可以归纳如下:
- 消息定长,例如每个报文的大小固定为20个字节,如果不够,空位补空格;
- 在包尾增加回车换行符进行切割;
- 将消息分为消息头和消息体,消息头中包含表示消息总长度的字段;
- 更复杂的应用层协议。
对于之前描述的案例,在这里我们就可以采取方案1和方案3。
以方案1为例:我们每次发送的TCP包只有三个数字,那么我将报文设置为3个字节大小的,此时,服务器就会以三个字节为基准来接受包,以此来解决站包拆包问题。
Netty的解决之道
LineBasedFrameDecoder
废话不多说直接上代码
服务端
public class PrintServer { public void bind(int port) throws Exception { // 配置服务端的NIO线程组 EventLoopGroup bossGroup = new NioEventLoopGroup(); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .childHandler(new ChildChannelHandler()); // 绑定端口,同步等待成功 ChannelFuture f = b.bind(port).sync(); // 等待服务端监听端口关闭 f.channel().closeFuture().sync(); } finally { // 优雅退出,释放线程池资源 bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } } private class ChildChannelHandler extends ChannelInitializer<SocketChannel> { @Override protected void initChannel(SocketChannel arg0) throws Exception { arg0.pipeline().addLast(new LineBasedFrameDecoder(1024)); //1 arg0.pipeline().addLast(new StringDecoder()); //2 arg0.pipeline().addLast(new PrintServerHandler()); } } public static void main(String[] args) throws Exception { int port = 8080; new TimeServer().bind(port); } }