关于Netty使用中黏包拆包带来报错问题及解决

最新推荐文章于 2024-07-02 00:45:00 发布
最新推荐文章于 2024-07-02 00:45:00 发布
阅读量1.2k 收藏 1
点赞数
分类专栏： java 异常报错 文章标签： java spring Netty 网络编程 黏包拆包
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010882234/article/details/130325408
版权
文章描述了一名开发者在维护基于TCP/IP的socket通信系统时遇到的问题，包括数据丢失和报错。问题1是平台接收到的过车数据比现场视频显示的少，问题2是程序启动时出现数据包解析异常。通过排查，发现是由于Netty解码器在处理数据包时没有进行包头校验和负载长度校验，导致在数据量大时出现数据丢失和解析错误。优化后的代码增加了包头校验和负载长度校验，解决了这两个问题。
摘要由CSDN通过智能技术生成

文章目录

问题现象

  • 业务场景：雷达作为客户端，平台作为服务端，采用TCP/IP协议的socket连接，数据包采用字节的二进制数据传输
  • 平台与雷达的通信和数据解析，在我接手时，已经开发完成，我接手负责维护和继续开发
  • 由于日常工作忙于大数据分析和指标计算，未对使用正常的通信代码做什么改动，在客户现场使用后发现了一些问题（公司测试没问题）
  • 问题1：雷达实时监测过车车辆，将数据通过socket上报给平台。但平台存入的过车，与现场视频相比，数量上明显偏少，怀疑存在数据丢失现象
  • 问题2：程序刚启动时，产生以下报错，后续也有偶尔类似报错
2022-12-19 10:40:57.215 ERROR 1 --- [ntLoopGroup-3-9] c.n.s.listener.DefaultExceptionListener  : Can't parse 115

java.lang.IllegalArgumentException: Can't parse 115
	at com.newatc.socketio.protocol.PacketType.valueOfInner(PacketType.java:63)
	at com.newatc.socketio.protocol.PacketDecoder.decodePackets(PacketDecoder.java:21)
	at com.newatc.socketio.handler.InPacketHandler.channelRead0(InPacketHandler.java:66)
	at com.newatc.socketio.handler.InPacketHandler.channelRead0(InPacketHandler.java:33)
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:302)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at com.newatc.socketio.handler.AuthorizeHandler.channelRead(AuthorizeHandler.java:149)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:102)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	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(Unknown Source)

解决

  • 针对问题2，追踪业务代码，发现是解析到的数据包类型出错，不在规定范围内。由于我们的平台和雷达设备都在客户内网内（不通互联网），基本不会有第三方数据侵入，数据上报类型不应该超出规定范围，肯定是平台数据接收解析出了问题
  • 针对问题1，用了另一个工具（雷达上位机软件）接收雷达数据，发现车辆数量正常，初步定位为平台处理socket上报信息时丢失了部分数据
  • 针对问题1，是在客户现场实施时发现的问题，在公司测试环境接入雷达测试时没有问题。对比分析了下两个场景，发现客户的路口数量较多，雷达数量也较多，同时这些路口实时过车也较多。
  • 雷达监测到过车就会触发数据上报，当数据量较大时，单个数据包超过最大长度就会进行拆包，分多个数据包上报
  • 查看了平台已有代码，使用的是Netty，但在数据接收时，没有进行包头校验、长度校验。对于拆包后的数据包（前面几个字节不是包头），跳过包头长度直接进行包类型校验会失败报错（此字节位置可能是负载的实际数据内容，而不是包头包类型），出错就丢掉数据，就会导致上面2个问题
    在这里插入图片描述
  • 先看下优化前，有问题的代码，很粗糙，很明显，但当过车较少，单个数据包包含所有信息时没问题
    // 数据接收经过的一个解码器 InPacketHandler 的接收处理方法
    @Override
    protected void channelRead0(ChannelHandlerContext ctx, PacketsMessage message) throws Exception {
        ByteBuf content = message.getContent();
        ClientHead client = message.getClient();

        if (log.isTraceEnabled()) {
            log.trace("In message: {} sessionId: {}", content.toString(CharsetUtil.UTF_8), client.getSessionId());
        }
        while (content.isReadable()) {
            try {
                Packet packet = decoder.decodePackets(content, client);
                if(packet == null)
                    continue;
                Namespace ns = namespacesHub.get(packet.getNsp());

                NamespaceClient nClient = client.getChildClient(ns);
                if (nClient == null) {
                    log.debug(
                        "Can't find namespace client in namespace: {}, sessionId: {} probably it was disconnected.",
                        ns.getName(),
                        client.getSessionId()
                    );
                    return;
                }
                packetListener.onPacket(packet, nClient);
            } catch (Exception ex) {
                String c = content.toString(CharsetUtil.UTF_8);
                log.error("Error during data processing. Client sessionId: " + client.getSessionId() + ", data: " + c, ex);
                throw ex;
            }
        }
        // 读取完成后，释放ByteBuf，防止内存溢出LEAK
        content.release();
    }
    
    // 上面channelRead0方法里对应的具体解码方法
    public Packet decodePackets(ByteBuf buf, ClientHead client) {
        // 前七个字节为 ： 标志（4）-负载长度（2）-协议版本号（1），未校验，直接跳过了
        buf.skipBytes(7);
        Packet packet = null;
        // 第8个字节是包类型
        short pType = buf.readUnsignedByte();
        PacketType packetSubType = PacketType.valueOfInner(pType);
        // 第 9、10字节是校验位和预留位，也跳过了
        buf.skipBytes(2);
        // 这里也没进行负载长度校验，只校验了是否还有可读字节
        if (buf.readableBytes() < 1){
            // 直接返回了，已读的字节也没有回滚回去，这样后面数据包上报依然不完整，解析依然会有问题
            return packet;
        }
        short oID = buf.readUnsignedByte();
        ObjectId objectId = ObjectId.valueOf(oID);

        switch (packetSubType) {
            case QUERY_RESULT:
                break;
            case REPLY:
                break;
            case REPORT:
                packet = new Packet(PacketType.MESSAGE);
                packet.setSubType(packetSubType);
                packet.setObjectId(objectId);

                switch (objectId){
                    case REALTIME_DATA:
                        packet.setName(EventName.REALTIME_DATA);
                        break;
                    case PASSING_VEHICLE:
                        packet.setName(EventName.PASSING_VEHICLE);
                        break;
                    case TRAFFIC_STATUS:
                        packet.setName(EventName.TRAFFIC_STATUS);
                        break;
                    case TRAFFIC_STATS:
                        packet.setName(EventName.FLOW_STATS);
                        break;
                    case PERFORMANCE:
                        packet.setName(EventName.PERFORMANCE);
                        break;
                    case TRAFFIC_EVENT:
                        packet.setName(EventName.TRAFFIC_EVENT);
                        break;
                    case RADAR_FAULT:
                        packet.setName(EventName.RADAR_FAULT);
                        break;
                }
                // 解析数据包里负载的数据体
                Object o = readReportObject(objectId, buf);
                List<Object> args = new ArrayList<>();
                args.add(o);
                packet.setData(args);
                break;
            case HEART_BEAT:
                packet = new Packet(PacketType.PING);
                packet.setSubType(packetSubType);
                packet.setObjectId(ObjectId.HEART_BEAT_FROM_RADAR);

                break;
            default:
                break;
        }

        return packet;
    }
  • 优化后的代码，主要做了包头校验和负载长度校验
  • 如果不是包头则舍弃，直到读到包头开始解析，这是为了防止程序启动时接收到的就是一个不完整包
  • 读取完包头后，如果剩余字节长度小于负载长度，回滚游标到包头位置，返回，继续等待下一个数据包上报再一起解析
    public Packet decodePackets(ByteBuf buf, ClientHead client) {
        // 将起始位置记录下，后面如果不完整，读取失败，回复到此位置
        int savedReaderIndex = buf.readerIndex();

        // 前七个字节为 ： 标志CYRC（4）-负载长度（2）-协议版本号（1），除了负载长度，其他没有用，直接跳过
        // 读取前四个字节，如果不是包头，则继续往下读
        byte head1 = buf.readByte();
        if (head1 != 0x43) {
            logger.info("第一个字符不是 C ，舍弃");
            return null;
        }
        byte head2 = buf.readByte();
        if (head2 != 0x59) {
            logger.info("第二个字符不是 Y ，舍弃");
            return null;
        }
        byte head3 = buf.readByte();
        if (head3 != 0x52) {
            logger.info("第三个字符不是 R ，舍弃");
            return null;
        }
        byte head4 = buf.readByte();
        if (head4 != 0x43) {
            logger.info("第四个字符不是 C ，舍弃");
            return null;
        }
        // 读取负载长度
        int dataLength = buf.readUnsignedShort();
        buf.skipBytes(1);
        // 第8个字节为包类型
        short pType = buf.readUnsignedByte();
        PacketType packetSubType = PacketType.valueOfInner(pType);
        // 第9/10字节，为校验位（1）-Reserve（1），暂未实际使用，直接跳过了
        buf.skipBytes(2);
        // 后续数据长度小于负载长度，则等待后面的数据上报再一起解析
        if (buf.readableBytes() < dataLength) {
            buf.readerIndex(savedReaderIndex);
            logger.info("剩余消息长度，小于负载（消息内容）长度 ，重置游标返回，等待后面数据上报一起解析");
            return null;
        }
        // 包头十个字节，后面为负载（消息内容），负载的第一个字节为对象标识，剩余为对象数据内容
        Packet packet = null;
        short oID = buf.readUnsignedByte();
        ObjectId objectId = ObjectId.valueOf(oID);

        switch (packetSubType) {
            case QUERY_RESULT:
                break;
            case REPLY:
                break;
            case REPORT:
                packet = new Packet(PacketType.MESSAGE);
                packet.setSubType(packetSubType);
                packet.setObjectId(objectId);

                switch (objectId) {
                    case REALTIME_DATA:
                        packet.setName(EventName.REALTIME_DATA);
                        break;
                    case PASSING_VEHICLE:
                        packet.setName(EventName.PASSING_VEHICLE);
                        break;
                    case TRAFFIC_STATUS:
                        packet.setName(EventName.TRAFFIC_STATUS);
                        break;
                    case TRAFFIC_STATS:
                        packet.setName(EventName.FLOW_STATS);
                        break;
                    case PERFORMANCE:
                        packet.setName(EventName.PERFORMANCE);
                        break;
                    case TRAFFIC_EVENT:
                        packet.setName(EventName.TRAFFIC_EVENT);
                        break;
                    case RADAR_FAULT:
                        packet.setName(EventName.RADAR_FAULT);
                        break;
                }

                Object o = readReportObject(objectId, buf);
                List<Object> args = new ArrayList<>();
                args.add(o);
                packet.setData(args);
                break;
            case HEART_BEAT:
                packet = new Packet(PacketType.PING);
                packet.setSubType(packetSubType);
                packet.setObjectId(ObjectId.HEART_BEAT_FROM_RADAR);

                break;
            default:
                break;
        }

        return packet;
    }

总结

在使用Netty进行TCP数据传输时，由于TCP是一个面向流的协议，消息会被拆分成多个字节流进行发送，因此接收方收到消息时，可能会出现黏包和拆包现象。

黏包指的是接收方一次性收到了多个完整的消息，而拆包则是接收方收到了不完整的消息。这种现象的出现是由于TCP是面向流的、无边界的协议，不保留数据报的边界。

为了解决黏包和拆包问题，Netty提供了多种解决方法：

  1. 消息定长：即发送方发送的每个消息长度固定，接收方接收到固定长度的字节流后进行消息的解析，这个是一种简单有效的实现方法。但是存在一个问题，不同消息长度不同，如心跳消息和数据上报消息，消息定长则部分消息必须填充补偿，显得浪费带宽。

  2. 消息分隔符：发送方在每个消息后添加特殊的分隔符，接收方根据分隔符对消息进行解码和拆分。使用这种实现方式时，要确保分隔符是唯一的，不会和消息内容重复，造成错误分隔。

  3. 消息头部标识：发送方在消息头部加入固定长度的表示消息长度的字段，接收方根据消息长度字段对消息进行解码和拆分。这是一种比较通用的实现，消息头部可以加一些标识、负载长度、校验位等，就可以正确识别到包头位置和对数据完整性进行校验。

  4. 基于Netty编解码器：Netty提供了一系列编解码器，可以自定义编解码器来控制消息的长度和格式。我们按照自己的诗句情况进行参数配置后，就可以实现自动的黏包和拆包处理。

总的来说，Netty提供了多种方式来解决黏包和拆包问题，我们可以根据业务需求选择合适的方式进行实现。只要双方约定了通信协议且严格按照协议发送数据，并且代码已经处理了黏包拆包，数据解析应该就没有问题。

坚持是一种态度
关注
专栏目录
【物联网系列网络编程之路】netty进阶学习（黏包拆包的应用场景、解决办法、hj212的报文为例）
尽力漂亮的博客
08-19 743
【网络编程之路】netty进阶学习之黏包半包的解决办法1黏包、拆包举例：实际场景解决办法demo: 本文目标： 1.介绍黏包和拆包是个啥、实际应用场景 2.解决办法以及demo 黏包、拆包举例： 假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。 （1）服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包； （2）服务端一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；
开源一个自用的Android IM库，基于Netty+TCP+Protobuf实现。
FreddyChen的博客
04-11 6027
转载请注明出处：https://juejin.im/post/5c97ae12e51d45580b681b0b 写在前面 一直想写一篇关于im即时通讯分享的文章，无奈工作太忙，很难抽出时间。今天终于从公司离职了，打算好好休息几天再重新找工作，趁时间空闲，决定静下心来写一篇文章，毕竟从前辈那里学到了很多东西。工作了五年半，这三四年来一直在做社交相关的项目，有 直播、 即时通讯、 短视频分享、 社区论...
Netty使用遇见的几个小问题及解决
Loong的专栏
08-30 1382
如何处理数据 不需要使用线程池启动线程处理数据了，因为Netty已经为处理数据创建了线程池！ 直接在Handler的线程中处理数据就可以了 使用Netty，一定要要深入了解它的线程模型！之前我理解错误，试图使用线程池处理数据。结果建立多个连接时，产生了大量的线程池。 一定要释放Buffer的内存 Netty为了提高IO的性能，使用了直接内存，使用后需要手动释放，否则会导致内存泄露。 要注意TC...
【Netty框架问题总结】
weixin_47068446的博客
04-24 931
Netty 是一个基于 Java NIO 的异步事件驱动的网络应用框架，用于快速开发高性能、可维护的网络服务器和客户端。它提供了简单易用的 API，使得网络编程更加轻松。Netty 的设计重点在于提供高性能、高可靠性和灵活性，适用于各种网络应用场景，包括但不限于服务器通信、分布式系统、即时通讯等。Netty 的主要特点包括：1.异步事件驱动：Netty 使用基于事件驱动的模型，通过回调机制实现非阻塞式的网络通信，提高了系统的并发性能。
【Netty】Netty经典问题
最新发布
九师兄
07-02 168
在Netty中，每个Channel都有一个与之关联的ChannelPipeline，用于处理该Channel上的事件和请求。ChannelPipeline是一种基于事件驱动的处理机制，它由多个处理器（Handler）组成，每个处理器负责处理一个或多个事件类型，将事件转换为下一个处理器所需的数据格式。
Netty TCP 粘包和拆包
hn_lzh2014的博客
03-29 244
TCP 是面向连接的，面向流的，提供高可靠性服务。收发两端 （客户端 和 服务器端）都要有一一成对的 socket。因此，发送端为了将多个发给接收端的包，更有效的发送给对方，使用了优化方法（Nagle 算法）, 将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样做虽然提高了效率，但是接收端就难于分辨出完整的数据包了，因为面向流通信是无消息保护边界的，需要接收端处理消息边界问题。
【Netty专题】Netty调优及网络编程中一些问题补充（面向面试学习）
qq_32681589的博客
11-25 1750
很直接哈，最近去面试的时候遇到了一些Netty网络编程，序列化框架上的问题，当时回答的不是很好，所以赶紧回来学习了一下，顺便做一下笔记，沉淀一下了。什么是序列化/反序列化？我在前面的文章中有提到过，但那时候没有写的很仔细，我自己也忘了，罪过啊。其实我知道，序列化/反序列化在网络编程中是很重要的概念，只不过被我自己疏忽了。言归正传。什么是序列化、反序列化？我们知道，数据在网络中传输不可能是原文传输的，人家机器设备只认得二进制01串。所以，把原文转换为01串字节流这个过程就是序列化；反之，则叫做反序列化。
42道计算机网络面试高频题+答案，面试官喜欢的答案都在这里
jiey0407的博客
06-02 7169
前言：计算机网络、计算机操作系统这两个“兄弟”是所有开发岗位都需要“结拜”的，不管你是 Java、C++还是测试。 对于后端开发的童鞋来说，计算机网络的重要性不亚于语言基础，毕竟平时开发经常会和网络打交道，比如： 抓个包等等。 所以对这一块知识点的准备还是要抱着敬畏之心，不要放过任何一个漏网之题。1、谈下你对五层网络协议体系结构的理解？学习计算机网络时我们一般采用折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。应用层（applicati
tcp与udp！！！
tayloramanda的博客
09-28 1929
5、TCP 的主要特点是什么？ 1. TCP 是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）； 2. 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）； 3. TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达； 4. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据； 5.面向字节.
netty 的异常处理
masterShaw的博客
04-28 6592
1. io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1 at io.netty.buffer.AbstractReferenceCountedByteBuf.releas...
关于netty-socketio的踩坑记录 TooLongFrameException异常问题
dubismile的博客
11-18 9914
Configuration config = new Configuration(); config.setHostname("localhost"); config.setPort(9092); config.setMaxFramePayloadLength(1024 * 1024); config.setMax...
Netty源码解析（四）之EventLoop和EventLoopGroup
benjam1n77的博客
02-24 879
前面几篇文章对Netty的服务器启动以及客户端连接做了较为详细的解析。接下来的文章，我将对Netty的各个主要的组件进行源码分析。这篇文章先介绍EventLoop和EventLoopGroup
Netty4：使用过程中的问题记录
编程学习者的博客
04-11 6022
1.声明 当前内容主要为本人学习和测试netty这个nio框架之用 2.问题1 本人处理传递的数据的时候出现的错误（发送消息的时候） 四月 11, 2021 5:15:59 下午 io.netty.channel.DefaultChannelPipeline onUnhandledInboundException 警告: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually
netty客户端发送数据时异常被隐藏
Brucelwl的博客
01-09 5260
while (!channelFuture1.isDone()) { try { boolean notTimeout = channelFuture1.await(10);//超时时间示例值 } catch (Exception e) { log.warn(e.getMessage()); } }
netty
hhui007的博客
03-23 845
java.util.concurrent.RejectedExecutionException: event executor terminated at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:923) ~[netty-common-4.1.74.Final.jar:4.1.74.Final] at io.netty.util.concurrent.Si...
SpringCloud-Gateway:reactor.netty.channel.AbortedException: Connection has been closed BEFORE send o
qq_38723394的博客
12-22 9029
SpringCloudGateway踩坑
[BUG10001]：Fegin远程调用报错
weixin_53621681的博客
02-28 423
[BUG10001]：Fegin远程调用报错
Netty深度解析：TCP粘包拆包问题及解决方案
例如，在Netty中，如果客户端发送消息时没有添加明确的分隔符，或者使用的是基于流的方式（如HTTP的GET请求），那么服务端在处理连续的数据流时，可能会遇到粘包问题。粘包的情况可能导致服务端在一次读取操作中接收...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

坚持是一种态度

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值