使用Netty解决TCP粘包和拆包问题过程详解

前言

上一篇我们介绍了如果使用Netty来开发一个简单的服务端和客户端,接下来我们来讨论如何使用解码器来解决TCP的粘包和拆包问题

TCP为什么会粘包/拆包

我们知道,TCP是以一种流的方式来进行网络转播的,当tcp三次握手简历通信后,客户端服务端之间就建立了一种通讯管道,我们可以想象成自来水管道,流出来的水是连城一片的,是没有分界线的。

TCP底层并不了解上层的业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分。

所以对于我们应用层而言。我们直观是发送一个个连续完整TCP数据包的,而在底层就可能会出现将一个完整的TCP拆分成多个包发送或者将多个包封装成一个大的数据包发送。

这就是所谓的TCP粘包和拆包。

当发生TCP粘包/拆包会发生什么情况

我们举一个简单例子说明:

客户端向服务端发送两个数据包:第一个内容为 123;第二个内容为456。服务端接受一个数据并做相应的业务处理(这里就是打印接受数据加一个逗号)。

那么服务端输出结果将会出现下面四种情况

服务端响应结果 结论
123,456, 正常接收,没有发生粘包和拆包
123456, 异常接收,发生tcp粘包
123,4,56, 异常接收,发生tcp拆包
12,3456, 异常接收,发生tcp拆包和粘包

如何解决

主流的协议解决方案可以归纳如下:

  1. 消息定长,例如每个报文的大小固定为20个字节,如果不够,空位补空格;
  2. 在包尾增加回车换行符进行切割;
  3. 将消息分为消息头和消息体,消息头中包含表示消息总长度的字段;
  4. 更复杂的应用层协议。

对于之前描述的案例,在这里我们就可以采取方案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);
 }
}

服务端Handler

public class PrintServerHandler extends ChannelHandlerAdapter {

 @Override
 public void channelRead(ChannelHandlerContext ctx, Object msg)
  throws Exception {
 ByteBuf buf = (ByteBuf) msg;
 byte[] req = new byte[buf.readableBytes()];
 buf.readBytes(req); //将缓存区的字节数组复制到新建的req数组中
 String body = new String(req, "UTF-8");
 System.out.println(body);
 String response= "打印成功";
 ByteBuf resp = Unpooled.copiedBuffer(response.getBytes());
 ctx.write(resp);
 } 

 @Override
 public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
 ctx.flush();
 }

 @Override
 public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
 ctx.close();
 }
}

客户端

public class PrintClient {

 public void connect(int port, String host) throws Exception {
 EventLoopGroup group = new NioEventLoopGroup();
 try {
  Bootstrap b = new Bootstrap();
   b.group(group)
   .channel(NioSocketChannel.class)
   .option(ChannelOption.TCP_NODELAY, true)
   .handler(new ChannelInitializer<SocketChannel>() {
   @Override
   public void initChannel(SocketChannel ch)
    throws Exception {
     ch.pipeline().addLast(
     new LineBasedFrameDecoder(1024));   //3
    ch.pipeline().addLast(new StringDecoder());  //4
    ch.pipeline().addLast(new PrintClientHandler());
   }
   });

  ChannelFuture f = b.connect(host, port).sync();
  f.channel().closeFuture().sync();
 } finally {
  // 优雅退出,释放NIO线程组
  group.shutdownGracefully();
 }
 }

 /**
  * @param args
  * @throws Exception
  */
 public static void main(String[] args) throws Exception {
 int port = 8080;
 new TimeClient().connect(port, "127.0.0.1");
 }
}

客户端的Handler

public class PrintClientHandler extends ChannelHandlerAdapter {

 private static final Logger logger = Logger
  .getLogger(TimeClientHandler.class.getName());

 private final ByteBuf firstMessage;

 /**
  * Creates a client-side handler.
  */
 public TimeClientHandler() {
 byte[] req = "你好服务端".getBytes();
 firstMessage = Unpooled.buffer(req.length);
 firstMessage.writeBytes(req);

 }

 @Override
 public void channelActive(ChannelHandlerContext ctx) {
 ctx.writeAndFlush(firstMessage);
 }

 @Override
 public void channelRead(ChannelHandlerContext ctx, Object msg)
  throws Exception {
 ByteBuf buf = (ByteBuf) msg;
 byte[] req = new byte[buf.readableBytes()];
 buf.readBytes(req);
 String body = new String(req, "UTF-8");
 System.out.println("服务端回应消息 : " + body);
 }

 @Override
 public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
 // 释放资源
 System.out.println("Unexpected exception from downstream : "
  + cause.getMessage());
 ctx.close();
 }
}

上诉代码逻辑与上一章代码逻辑相同,客户端接受服务端数据答应,并回复客户端信息,客户端接受到数据后打印数据。

我们观察代码可以发现,要想Netty解决粘包拆包问题,只需在编写服务端和客户端的pipeline上加上相应的解码器即可,上诉注释 1,2,3,4处。其余代码无需做任何修改。

LineBasedFrameDecoder+StringDecoder的组合就是按行切换的文本解码器,它被设计用来支持TCP的粘包和拆包。原理为:如果连续读取到最大长度后任然没有发现换行符,就会抛出异常,同时忽略掉之前督导的异常码流。

DelimiteBasedFrameDecoder

该解码器的可以自动完成以分割符作为码流结束标识的消息解码。(其实上一个解码器类似,如果指定分隔符为换行符,那么与上一个编码器的作用基本相同)

使用也很简单:

只需要修改服务端和客户端对应代码中的initChannel代码即可

   public void initChannel(SocketChannel ch)
    ByteBuf delimiter = Unpooled.copiedBuffer("_".getBytes()); //1
    ch.pipeline().addLast(
     new DelimiterBasedFrameDecoder(1024,
      delimiter));          //2
    ch.pipeline().addLast(new StringDecoder());     //3
    ch.pipeline().addLast(new PrintHandler());
   }

注释1:首先创建分隔符缓冲对象ByteBuf,并指定以"_"作为分隔符。

注释2:将分隔符缓冲对象ByteBuf传入DelimiterBasedFrameDecoder,并指定最大长度。

注释3:指定为字符串字节流

FixedLengthFrameDecoder

该解码器为固定长度解码器,它能够按照指定的长度对详细进行自动解码。

使用同样也很简单:

同样只需要修改服务端和客户端对应代码中的initChannel代码即可

 public void initChannel(SocketChannel ch)
    throws Exception {
    ch.pipeline().addLast(new FixedLengthFrameDecoder(20));
    ch.pipeline().addLast(new StringDecoder());
    ch.pipeline().addLast(new PrintHandler());
   }
   });

这样我们就指定了,每接收20个字符大小的字符串字节流就将其看作一个包来经行处理。

总结

Netty已经在底层为我们做了很多事情,我们只需要简单的使用其提供好的解码器使用即可,源码内容待我研究归来,再进行展开,哈哈,完活~睡觉!

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • Spring Boot实战之netty-socketio实现简单聊天室(给指定用户推送消息)

    网上好多例子都是群发的,本文实现一对一的发送,给指定客户端进行消息推送 1.本文使用到netty-socketio开源库,以及MySQL,所以首先在pom.xml中添加相应的依赖库 <dependency> <groupId>com.corundumstudio.socketio</groupId> <artifactId>netty-socketio</artifactId> <version>1.7.11</version&

  • spring+netty服务器搭建的方法

    游戏一般是长连接,自定义协议,不用http协议,BIO,NIO,AIO这些我就不说了,自己查资料 我现在用spring+netty搭起简单的游戏服 思路:1自定义协议和协议包:2spring+netty整合:3半包粘包处理,心跳机制等:4请求分发(目前自己搞的都是单例模式) 下个是测试用的,结构如下 首先自定义包头 Header.java package com.test.netty.message; /** * Header.java * 自定义协议包头 * @author janehuang

  • Spring Boot集成netty实现客户端服务端交互示例详解

    前言 Netty 是一个高性能的 NIO 网络框架,本文主要给大家介绍了关于SpringBoot集成netty实现客户端服务端交互的相关内容,下面来一起看看详细的介绍吧 看了好几天的netty实战,慢慢摸索,虽然还没有摸着很多门道,但今天还是把之前想加入到项目里的 一些想法实现了,算是有点信心了吧(讲真netty对初学者还真的不是很友好......) 首先,当然是在SpringBoot项目里添加netty的依赖了,注意不要用netty5的依赖,因为已经废弃了 <!--netty--> <

  • 使用Netty进行编解码的操作过程详解

    前言 何为编解码,通俗的来说,我们需要将一串文本信息从A发送到B并且将这段文本进行加工处理,如:A将信息文本信息编码为2进制信息进行传输.B接受到的消息是一串2进制信息,需要将其解码为文本信息才能正常进行处理. 上章我们介绍的Netty如何解决拆包和粘包问题,就是运用了解码的这一功能. java默认的序列化机制 使用Netty大多是java程序猿,我们基于一切都是对象的原则,经常会将对象进行网络传输,那么对于序列化操作肯定大家都是非常熟悉的. 一个对象是不能直接进行网络I/O传输的,jdk默认是

  • 使用Netty解决TCP粘包和拆包问题过程详解

    前言 上一篇我们介绍了如果使用Netty来开发一个简单的服务端和客户端,接下来我们来讨论如何使用解码器来解决TCP的粘包和拆包问题 TCP为什么会粘包/拆包 我们知道,TCP是以一种流的方式来进行网络转播的,当tcp三次握手简历通信后,客户端服务端之间就建立了一种通讯管道,我们可以想象成自来水管道,流出来的水是连城一片的,是没有分界线的. TCP底层并不了解上层的业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分. 所以对于我们应用层而言.我们直观是发送一个个连续完整TCP数据包的,

  • Netty解决 TCP 粘包拆包的方法

    什么是粘包/拆包 一般所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据.TCP通讯为何存在粘包呢?主要原因是TCP是以流的方式来处理数据,再加上网络上MTU的往往小于在应用处理的消息数据,所以就会引发一次接收的数据无法满足消息的需要,导致粘包的存在.处理粘包的唯一方法就是制定应用层的数据通讯协议,通过协议来规范现有接收的数据是否满足消息数据的需要. 我们都知道TCP是基于字节流的传输协议. 那么数据在通信层传播其实就像河水一样并没有明显的分界线,而数据具体表示什么意思什么地方有句

  • python TCP Socket的粘包和分包的处理详解

    概述 在进行TCP Socket开发时,都需要处理数据包粘包和分包的情况.本文详细讲解解决该问题的步骤.使用的语言是Python.实际上解决该问题很简单,在应用层下,定义一个协议:消息头部+消息长度+消息正文即可. 那什么是粘包和分包呢? 关于分包和粘包 粘包:发送方发送两个字符串"hello"+"world",接收方却一次性接收到了"helloworld". 分包:发送方发送字符串"helloworld",接收方却接收到了两

  • Python使用socketServer包搭建简易服务器过程详解

    官方提供了socketserver包去方便我们快速的搭建一个服务器框架. server类 socketserver包提供5个Server类,这些单独使用这些Server类都只能完成同步的操作,他是一个单线程的,不能同时处理各个客户端的请求,只能按照顺序依次处理. +------------+ | BaseServer | +------------+ | v +-----------+ +------------------+ | TCPServer |------->| UnixStreamS

  • Python Socket TCP双端聊天功能实现过程详解

    SOCKET编程 socket(套接字):是一个网络通信的端点,能实现不同主机的进程通信, -通过IP+端口定位对方并发送消息的通信机制 分为UDP和TCP 客户端Client: 发起访问的一-方 服务器端Server: 接受访问的一方 UDP编程 Server端流程 1.建立socket,socket是负贵具体通信的一个实例 2.绑定,为创建的socket指派固定的端口和ip地址 3.接受对方发送内容 4.给对方发送反馈,此步骤为非必须步骤 Client端流程 1.建立通信的socket 2.

  • Golang通过包长协议处理TCP粘包的问题解决

    tcp粘包产生的原因这里就不说了,因为大家能搜索TCP粘包的处理方法,想必大概对TCP粘包有了一定了解,所以我们直接从处理思路开始讲起 tcp粘包现象代码重现 首先,我们来重现一下TCP粘包,然后再此基础之上解决粘包的问题,这里给出了client和server的示例代码如下 /* 文件名:client.go client客户端的示例代码(未处理粘包问题) 通过无限循环无时间间隔发送数据给server服务器 server将会不间断的出现TCP粘包问题 */ package main import

  • Golang TCP粘包拆包问题的解决方法

    什么是粘包问题 最近在使用Golang编写Socket层,发现有时候接收端会一次读到多个数据包的问题.于是通过查阅资料,发现这个就是传说中的TCP粘包问题.下面通过编写代码来重现这个问题: 服务端代码 server/main.go func main() { l, err := net.Listen("tcp", ":4044") if err != nil { panic(err) } fmt.Println("listen to 4044")

  • C#中TCP粘包问题的解决方法

    一.TCP粘包产生的原理 1.TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾.出现粘包现象的原因是多方面的,它既可能由发送方造成,也可能由接收方造成. 2.发送方引起的粘包是由TCP协议本身造成的,TCP为提高传输效率,发送方往往要收集到足够多的数据后才发送一包数据.若连续几次发送的数据都很少,通常TCP会根据优化算法把这些数据合成一包后一次发送出去,这样接收方就收到了粘包数据.接收方引起的粘包是由于接收方用户进程不及时接收数据,从

  • 6行代码快速解决golang TCP粘包问题

    前言 什么是TCP粘包问题以及为什么会产生TCP粘包,本文不加讨论.本文使用golang的bufio.Scanner来实现自定义协议解包. 下面话不多说了,来一起看看详细的介绍吧. 协议数据包定义 本文模拟一个日志服务器,该服务器接收客户端传到的数据包并显示出来 type Package struct { Version [2]byte // 协议版本,暂定V1 Length int16 // 数据部分长度 Timestamp int64 // 时间戳 HostnameLength int16

  • GO语言如何手动处理TCP粘包详解

    前言 一般所谓的TCP粘包是在一次接收数据不能完全地体现一个完整的消息数据.TCP通讯为何存在粘包呢?主要原因是TCP是以流的方式来处理数据,再加上网络上MTU的往往小于在应用处理的消息数据,所以就会引发一次接收的数据无法满足消息的需要,导致粘包的存在.处理粘包的唯一方法就是制定应用层的数据通讯协议,通过协议来规范现有接收的数据是否满足消息数据的需要.在应用中处理粘包的基础方法主要有两种分别是以4节字描述消息大小或以结束符,实际上也有两者相结合的如HTTP,redis的通讯协议等. 应用场景 大

随机推荐