解决粘包和拆包问题

解决粘包和拆包问题

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

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

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

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

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

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

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

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

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

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

4|0如何解决

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

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

对于之前描述的案例,在这里我们就可以采取方案1和方案3。

以方案1为例:我们每次发送的TCP包只有三个数字,那么我将报文设置为3个字节大小的,此时,服务器就会以三个字节为基准来接受包,以此来解决站包拆包问题。

5|0Netty的解决之道

5|1LineBasedFrameDecoder

废话不多说直接上代码

服务端

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的粘包和拆包。原理为:如果连续读取到最大长度后任然没有发现换行符,就会抛出异常,同时忽略掉之前督导的异常码流。

5|2DelimiteBasedFrameDecoder

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

使用也很简单:

只需要修改服务端和客户端对应代码中的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:指定为字符串字节流

5|3FixedLengthFrameDecoder

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

使用同样也很简单:

同样只需要修改服务端和客户端对应代码中的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个字符大小的字符串字节流就将其看作一个包来经行处理。

6|0总结

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

原文地址:https://www.cnblogs.com/Leo_wl/p/10993036.html

时间: 2024-11-08 10:12:45

解决粘包和拆包问题的相关文章

Netty解决粘包和拆包问题的四种方案

在RPC框架中,粘包和拆包问题是必须解决一个问题,因为RPC框架中,各个微服务相互之间都是维系了一个TCP长连接,比如dubbo就是一个全双工的长连接.由于微服务往对方发送信息的时候,所有的请求都是使用的同一个连接,这样就会产生粘包和拆包的问题.本文首先会对粘包和拆包问题进行描述,然后介绍其常用的解决方案,最后会对Netty提供的几种解决方案进行讲解.这里说明一下,由于oschina将"jie ma qi"认定为敏感文字,因而本文统一使用"解码一器"表示该含义 粘包

netty 解决TCP粘包与拆包问题(二)

TCP以流的方式进行数据传输,上层应用协议为了对消息的区分,采用了以下几种方法. 1.消息固定长度 2.第一篇讲的回车换行符形式 3.以特殊字符作为消息结束符的形式 4.通过消息头中定义长度字段来标识消息的总长度 一.采用指定分割符解决粘包与拆包问题 服务端 1 package com.ming.netty.nio.stickpack; 2 3 4 5 import java.net.InetSocketAddress; 6 7 import io.netty.bootstrap.ServerB

tcp的粘包和拆包示例以及使用LengthFieldFrameDecoder来解决的方法

粘包和拆包是什么? TCP协议是一种字节流协议,没有记录边界,我们在接收消息的时候,不能人为接收到的数据包就是一个整包消息 当客户端向服务器端发送多个消息数据的时候,TCP协议可能将多个消息数据合并成一个数据包进行发送,这就是粘包 当客户端向服务器端发送的消息过大的时候,tcp协议可能将一个数据包拆成多个数据包来进行发送,这就是拆包 以下一netty为例,展示一下tcp粘包和拆包的例子: ServerBusinessHanler: import io.netty.buffer.ByteBuf;

TCP粘包,拆包及解决方法

粘包拆包问题是处于网络比较底层的问题,在数据链路层.网络层以及传输层都有可能发生.我们日常的网络应用开发大都在传输层进行,由于UDP有消息保护边界,不会发生粘包拆包问题,因此粘包拆包问题只发生在TCP协议中. 什么是粘包.拆包? 假设客户端向服务端连续发送了两个数据包,用packet1和packet2来表示,那么服务端收到的数据可以分为三种,现列举如下: 第一种情况,接收端正常收到两个数据包,即没有发生拆包和粘包的现象,此种情况不在本文的讨论范围内. 第二种情况,接收端只收到一个数据包,由于TC

关于TCP的粘包和拆包

问题产生 一个完整的业务可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这个就是TCP的拆包和封包问题. 下面可以看一张图,是客户端向服务端发送包: 1. 第一种情况,Data1和Data2都分开发送到了Server端,没有产生粘包和拆包的情况. 2. 第二种情况,Data1和Data2数据粘在了一起,打成了一个大的包发送到Server端,这个情况就是粘包. 3. 第三种情况,Data2被分离成Data2_1和Data2_2,并且Data2_1在Data1之前到

10.python网络编程(解决粘包问题 part 2)

一.什么时候会产生粘包现象. 只有在使用tcp协议的情况下才会产生粘包现象!udp协议永远不会! 发送端可以1k1k的把数据发送出去,接收端,可以2k2k的的去接收数据,一次可能会接收3k,也有可能1次接收6k. TCP协议是面向流的协议,这也是容易出现粘包问题的原因.而UDP是面向消息的协议,每个UDP段都是一条消息,应用程序必须以消息为单位提取数据,不能一次提取任意字节的数据,这一点和TCP是很不同的.怎样定义消息呢?可以认为对方一次性write/send的数据为一个消息,需要明白的是当对方

netty的解码器与粘包和拆包

tcp是一个“流”的协议,一个完整的包可能会被TCP拆分成多个包进行发送,也可能把小的封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题. 假设客户端分别发送数据包D1和D2给服务端,由于服务端一次性读取到的字节数是不确定的,所以可能存在以下4种情况. 1.服务端分2次读取到了两个独立的包,分别是D1,D2,没有粘包和拆包: 2.服务端一次性接收了两个包,D1和D2粘在一起了,被成为TCP粘包; 3.服务端分2次读取到了两个数据包,第一次读取到了完整的D1和D2包的部分内容,第二次读取到

第31篇 粘包的产生原理 以及如何解决粘包问题

内容回顾: 如何与另外一台电脑连接: ping 对方的ip地址 如何参电脑的ip配置 cmd-->ipconfig 内容概览: 粘包问题 粘包产生原理 如何解决粘包问题 粘包的产生: #server import socket sk = socket.socket() ip_port = ('127.0.0.1',8989) sk.bind(ip_port) sk.listen() conn,addr = sk.accept() conn.send(b'hello,') conn.send(b'

粘包、拆包发生原因滑动窗口、MSS/MTU限制、Nagle算法

[TCP协议](3)---TCP粘包黏包 有关TCP协议之前写过两篇博客: 1.[TCP协议](1)---TCP协议详解 2.[TCP协议](2)---TCP三次握手和四次挥手 一.TCP粘包.拆包图解 假设客户端分别发送了两个数据包D1和D2给服务端,由于服务端一次读取到字节数是不确定的,故可能存在以下四种情况: 1)服务端分两次读取到了两个独立的数据包,分别是D1和D2,没有粘包和拆包 2)服务端一次接受到了两个数据包,D1和D2粘合在一起,称之为TCP粘包 3)服务端分两次读取到了数据包,