Netty 粘包和半包

最新推荐文章于 2022-11-13 19:23:10 发布
最新推荐文章于 2022-11-13 19:23:10 发布
阅读量191 收藏
点赞数
分类专栏： Netty 文章标签： netty 网络通信 socket
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_48922154/article/details/116757630
版权

文章目录

一、示例

服务器端代码

package com.lboyang.chapter03;

import com.sun.corba.se.internal.CosNaming.BootstrapServer;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import io.netty.handler.logging.LogLevel;
import io.netty.handler.logging.LoggingHandler;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * @Description:
 * @Author: Aiguodala
 * @CreateDate: 2021/5/13 17:03
 */

public class ServerTest {

    /**
     * slf4j 记录日志
     */
    static final Logger log = LoggerFactory.getLogger(ServerTest.class);

    public static void main(String[] args) {
        new ServerTest().start();
    }

    private void start() {
        NioEventLoopGroup acceptor = new NioEventLoopGroup(1);
        NioEventLoopGroup worker = new NioEventLoopGroup();

        try {
            ServerBootstrap server = new ServerBootstrap();
            server.channel(NioServerSocketChannel.class);
            server.group(acceptor, worker);
            server.childHandler(new ChannelInitializer<NioSocketChannel>() {
                @Override
                protected void initChannel(NioSocketChannel ch) throws Exception {
                    ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
                            // 连接建立执行该方法
                            log.debug("connected {}", ctx.channel());
                            super.channelActive(ctx);
                        }
                        @Override
                        public void channelInactive(ChannelHandlerContext ctx) throws Exception {
                            // 连接断开时会执行该方法
                            log.debug("disconnect {}", ctx.channel());
                            super.channelInactive(ctx);
                        }
                    });
                }
            });
            // 绑定端口
            ChannelFuture channelFuture = server.bind(8080);
            channelFuture.sync();

            //关闭channel
            channelFuture.channel().closeFuture().sync();
        }catch (InterruptedException e) {
            log.error("server error", e);
        }finally {
            acceptor.shutdownGracefully();
            worker.shutdownGracefully();
            log.debug("stopped");
        }

    }


}

1. 粘包现象

客户端代码

package com.lboyang.chapter03;

import io.netty.bootstrap.Bootstrap;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioSocketChannel;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * @Description:
 * @Author: Aiguodala
 * @CreateDate: 2021/5/14 13:12
 */

public class ClientTest {

    /**
     * 打印日志
     */
    static final Logger log = LoggerFactory.getLogger(ClientTest.class);

    public static void main(String[] args) {
        NioEventLoopGroup worker = new NioEventLoopGroup();
        try {
            Bootstrap bootstrap = new Bootstrap();
            bootstrap.channel(NioSocketChannel.class);
            bootstrap.group(worker);
            bootstrap.handler(new ChannelInitializer<NioSocketChannel>() {
                @Override
                protected void initChannel(NioSocketChannel ch) throws Exception {
                    log.debug("connected...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
                            log.debug("sending...");
                            // 每次发送16个字节的数据，共发送10次
                            for (int i = 0; i < 10; i++) {
                                ByteBuf buffer = ctx.alloc().buffer();
                                buffer.writeBytes(new byte[]{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15});
                                ctx.writeAndFlush(buffer);
                            }
                        }
                    });
                }
            });
            ChannelFuture channelFuture = bootstrap.connect("localhost", 8080).sync();
            channelFuture.channel().closeFuture().sync();

        } catch (InterruptedException e) {
            log.error("client error", e);
        } finally {
            worker.shutdownGracefully();
        }

    }
}

服务器端接受结果

13:30:52.266 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xc807762c, L:/127.0.0.1:8080 - R:/127.0.0.1:56906] READ: 160B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000010| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000020| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000030| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000040| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000050| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000060| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000070| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000080| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000090| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
+--------+-------------------------------------------------+----------------+

可见虽然客户端是分别以16字节为单位，通过channel向服务器发送了10次数据，可是服务器端却只接收了一次，接收数据的大小为160B，即客户端发送的数据总大小，这就是粘包现象

2. 半包现象

将客户端-服务器之间的channel容量进行调整

调整服务端代码

// 调整channel容量,
server.option(ChannelOption.SO_RCVBUF, 10);

影响的是底层接收缓冲区（即滑动窗口）大小，仅决定了 netty 读取的最小单位，netty 实际每次读取的一般是它的整数倍

输出内容

20:09:29.438 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ: 36B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000010| 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................|
|00000020| 00 01 02 03                                     |....            |
+--------+-------------------------------------------------+----------------+
20:09:29.439 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ COMPLETE
20:09:29.439 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000010| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000020| 04 05 06 07 08 09 0a 0b                         |........        |
+--------+-------------------------------------------------+----------------+
20:09:29.439 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ COMPLETE
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a 0b |................|
|00000010| 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a 0b |................|
|00000020| 0c 0d 0e 0f 00 01 02 03                         |........        |
+--------+-------------------------------------------------+----------------+
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ COMPLETE
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ: 40B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000010| 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 |................|
|00000020| 04 05 06 07 08 09 0a 0b                         |........        |
+--------+-------------------------------------------------+----------------+
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ COMPLETE
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ: 4B
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 0c 0d 0e 0f                                     |....            |
+--------+-------------------------------------------------+----------------+
20:09:29.440 [nioEventLoopGroup-3-1] DEBUG io.netty.handler.logging.LoggingHandler - [id: 0xf69051e8, L:/127.0.0.1:8080 - R:/127.0.0.1:63716] READ COMPLETE

可见客户端每次发送的数据，因channel容量不足，无法将发送的数据一次性接收，便产生了半包现象

二、现象分析

1. 粘包

现象

例如 发送 A iguo dala 收到的是 Aiguodala

原因

  • 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）
  • 传输层-网络层：
    • 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大（大于256 bytes），这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包
    • Nagle 算法：会造成粘包

2. 半包

现象

发送 AIguodala，接收 A Iguo dala

原因

  • 应用层：接收方 ByteBuf 小于实际发送数据量
  • 传输层-网络层：滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时接收方窗口中无法容纳发送方的全部报文，发送方只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包
  • 数据链路层：MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包

本质

发生粘包与半包现象的本质是因为 TCP 是流式协议，消息无边界

三、解决方案

1. 短连接

客户端每次向服务器发送数据以后，就与服务器断开连接，此时的消息边界为连接建立到连接断开。这时便无需使用滑动窗口等技术来缓冲数据，则不会发生粘包现象。但如果一次性数据发送过多，接收方无法一次性容纳所有数据，还是会发生半包现象，所以短链接无法解决半包现象

2. 定长解码器

客户端于服务器约定一个最大长度，保证客户端每次发送的数据长度都不会大于该长度。若发送数据长度不足则需要补齐至该长度

服务器接收数据时，将接收到的数据按照约定的最大长度进行拆分，即使发送过程中产生了粘包，也可以通过定长解码器将数据正确地进行拆分。服务端需要用到FixedLengthFrameDecoder对数据进行定长解码，具体使用方法如下

ch.pipeline().addLast(new FixedLengthFrameDecoder(16));

客户端发送数据代码

            bootstrap.handler(new ChannelInitializer<NioSocketChannel>() {
                @Override
                protected void initChannel(NioSocketChannel ch) throws Exception {
                    log.debug("connected...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
                            // 约定最大长度为16
                            final int maxLength = 16;
							// 被发送的数据
                            char c = 'a';
							// 向服务器发送10个报文
                            for (int i = 0; i < 10; i++) {
                                ByteBuf buffer = ctx.alloc().buffer(maxLength);
                                // 定长byte数组，未使用部分会以0进行填充
                                byte[] bytes = new byte[maxLength];
                                // 生成长度为0~15的数据
                                for (int j = 0; j < (int)(Math.random()*(maxLength-1)); j++) {
                                    bytes[j] = (byte) c;
                                }
                                buffer.writeBytes(bytes);
                                c++;
                                // 将数据发送给服务器
                                ctx.writeAndFlush(buffer);
                            }
                        }
                    });
                }
            });

服务器代码

使用FixedLengthFrameDecoder对粘包数据进行拆分，该handler需要添加在LoggingHandler之前，保证数据被打印时已被拆分

// 通过定长解码器对粘包数据进行拆分
ch.pipeline().addLast(new FixedLengthFrameDecoder(16));

运行结果没有出现粘包和半包现象

3. 行解码器

行解码器的是通过分隔符对数据进行拆分来解决粘包半包问题的？

可以通过LineBasedFrameDecoder(int maxLength)来拆分以换行符(\n)为分隔符的数据，也可以通过DelimiterBasedFrameDecoder(int maxFrameLength, ByteBuf… delimiters)来指定通过什么分隔符来拆分数据（可以传入多个分隔符）

两种解码器都需要传入数据的最大长度，若超出最大长度，会抛出TooLongFrameException异常

以换行符 “\c” 为分隔符

客户端发送数据代码

            bootstrap.handler(new ChannelInitializer<NioSocketChannel>() {
                @Override
                protected void initChannel(NioSocketChannel ch) throws Exception {
                    log.debug("connected...");
                    ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) throws Exception {
                            // 约定最大长度为 64
                            final int maxLength = 64;
                            // 被发送的数据
                            char c = 'a';
                            for (int i = 0; i < 10; i++) {
                                ByteBuf buffer = ctx.alloc().buffer(maxLength);
                                // 生成长度为0~62的数据
                                Random random = new Random();
                                StringBuilder sb = new StringBuilder();
                                for (int j = 0; j < (int)(random.nextInt(maxLength-2)); j++) {
                                    sb.append(c);
                                }
                                // 数据以 \n 结尾
                                sb.append("\\c");
                                buffer.writeBytes(sb.toString().getBytes(StandardCharsets.UTF_8));
                                c++;
                                // 将数据发送给服务器
                                ctx.writeAndFlush(buffer);
                            }
                        }
                    });
                }
            });

服务端接受数据代码

// 将分隔符放入ByteBuf中
ByteBuf bufSet = ch.alloc().buffer().writeBytes("\\c".getBytes(StandardCharsets.UTF_8));
// 通过行解码器对粘包数据进行拆分，以 \c 为分隔符
ch.pipeline().addLast(new DelimiterBasedFrameDecoder(64, ch.alloc().buffer().writeBytes(bufSet)));

运行结果没有出现粘包和半包现象

4. 长度字段解码器

在传送数据时可以在数据中添加一个用于表示有用数据长度的字段，在解码时读取出这个用于表明长度的字段，同时读取其他相关参数，即可知道最终需要的数据是什么样子的

LengthFieldBasedFrameDecoder解码器可以提供更为丰富的拆分方法，其构造方法有七个参数

    public LengthFieldBasedFrameDecoder(
            ByteOrder byteOrder, int maxFrameLength, int lengthFieldOffset, int lengthFieldLength,
            int lengthAdjustment, int initialBytesToStrip, boolean failFast)

主要参数解析

  • maxFrameLength 数据最大长度
    • 表示数据的最大长度（包括附加信息、长度标识等内容）
  • lengthFieldOffset 数据长度标识的起始偏移量
    • 用于指明数据第几个字节开始是用于标识有用字节长度的，因为前面可能还有其他附加信息
  • lengthFieldLength 数据长度标识所占字节数（用于指明有用数据的长度）
    • 数据中用于表示有用数据长度的标识所占的字节数
  • lengthAdjustment 长度表示与有用数据的偏移量
    • 用于指明数据长度标识和有用数据之间的距离，因为两者之间还可能有附加信息
  • initialBytesToStrip 数据读取起点
    • 读取起点，不读取 0 ~ initialBytesToStrip 之间的数据

在这里插入图片描述

A.iguodala
关注
专栏目录
Netty解决TCP粘包/拆包导致的半包读写问题
ForeverLove的博客
07-12 5150
一.TCP粘包/拆包问题说明   TCP是个“流”协议，就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包拆分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。 二.利用LinedBasedFrameDecoder解决TCP粘包问题    为了
Netty 粘包 & 半包
m0_66225491的博客
01-10 1088
TCP 是面向流的，提供高可靠性服务。收发两端都要有成对的 Socket 因此发送端为了将多个发给接收端的包，更有效的发送给对方，使用了 Nagle 算法优化 将多次间隔较小且数量小的数据，合并为一个大的数据块，然后进行封包， 这样虽然提高了效率，但是接收端就难以分辨出完整的数据包了，因为面向流的通信是无消息保护边界的 粘包 现象 发送 abc def，接收为 abcdef 原因 应用层：接收方 ByteBuf 设置太大（Netty默认1024） 滑动窗口：假设发送方256bytes表示一
Netty（9）粘包与半包问题和解决
учёба
08-24 373
客户端代码 客户端代码希望发送 10 个消息，每个消息是 16 字节 运行结果 一次就接收了 160 个字节，而非分 10 次接收 服务端修改一下接收缓冲区，其它代码不变 影响的底层接收缓冲区（即滑动窗口）大小， 只要是使用TCP/IP协议进行编程，就会出现黏包和半包想象TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差 为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值 ，同时
Netty 进阶学习（九）-- 粘包与半包
weixin_43989102的博客
09-07 494
链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如。TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差。消息边界就是分隔符，不再浪费空间，但是内容使用分隔符就需要进行转义，效率也不是很高。消息边界也就是固定长度，这种方式实现简单，但是空间有极大的浪费，不推荐使用。字节的数据，查看结果，存在接收到。
NETTY-Netty的粘包和半包
飞翔的肥仔
05-06 697
写在前面 最近接触了几个开源的框架，看看代码，发现都用到了netty，于是，打算比较彻底的了解一下。 基本概念 TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，粘包和半包也就会在此时产生。 客户端给服务端发送了两条消息ABC和DEF，服务端这边的接收会有多少种情况呢？有可能是一次性收到了所有的消息ABCDEF，有可能是收到了三条消息AB、CD、EF。 粘包 发送方每次写...
netty中的粘包和半包
DJYDFT2831djydft的专栏
02-23 222
在网络传输中，粘包和半包应该是最常出现的问题，作为 Java 中最常使用的 NIO 网络框架 Netty，它又是如何解决的呢？今天就让我们来看看。 一、定义 TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，粘包和半包也就会在此时产生。 客户端给服务端发送了两条消息ABC和DEF，服务端这边的接收会有多少种情况呢？有可能是一次性收到了所有的消息ABCDEF，有可能是收到了三条消息AB、CD、EF。 上面所说的一次性收到了所有的消息ABCDEF，类似于粘包。如果客户端发送的包的大
Netty 粘包/半包原理与拆包实战 源码
11-11
本实例是《Netty 粘包/半包原理与拆包实战》 一文的源代码工程。 大家好，我是作者尼恩。 在前面的文章中，完成了一个高性能的 Java 聊天程序，尼恩已经再一次的进行了通讯协议的选择。放弃了大家非常熟悉的json ...
Netty 粘包/半包原理与拆包实战 【源代码 新】
11-11
- 本实例是《Netty 粘包/半包原理与拆包实战》 一文的源代码工程。 大家好，我是作者尼恩。 在前面的文章中，完成了一个高性能的 Java 聊天程序，尼恩已经再一次的进行了通讯协议的选择。放弃了大家非常熟悉的json...
Dubbo剖析-Netty粘包与半包问题（一）
技术原始积累
05-20 531
一、前言在客户端与服务端进行通信时候都会约定一个通讯协议，协议一般包含一个header和body，一个header和body组成了一次通讯的内容，一个通讯包。正常情况下客...
Java NIO 框架 Netty 之美：粘包与半包问题
GitChat
07-03 1697
Netty 是一个可以快速开发网络应用程序的 NIO 框架，它大大简化了 TCP 或者 UDP 服务器的网络编程。Netty 的简易和快速开发并不意味着由它开发的程序将失去可维护性或者存在性能问题，它的设计参考了许多协议的实现，比如 FTP，SMTP，HTTP 和各种二进制和基于文本的传统协议，因此 Netty 成功的实现了兼顾快速开发，性能，稳定性，灵活性为一体，不需要为了考虑一方面原因而妥协其...
Netty应用之粘包半包问题
weixin_46120888的博客
05-05 2500
文章目录1.粘包现象演示2.半包现象演示3.粘包半包现象分析3.1 粘包3.2 半包4.粘包半包解决方案4.1短连接4.2 定长解码器4.3 行解码器4.4 LengthFieldBasedFrameDecoder4.5 LengthFieldBasedFrameDecoder演示 参考黑马程序员 1.粘包现象演示 我们通过一段代码演示一个这个粘包现象，首先我们来看服务端 void start() { NioEventLoopGroup boss = new NioEventLoop
Netty 粘包/半包原理与拆包实战（史上最全）
彪锅锅来啦
04-23 1527
写在前面 大家好，我是作者尼恩。 为了完成了一个高性能的 Java 聊天程序，在前面的文章中，尼恩已经再一次的进行了通讯协议的重新选择。 这就是：放弃了大家非常熟悉的json 格式，选择了性能更佳的 Protobuf协议。 在上一篇文章中，并且完成了Netty 和 Protobuf协议整合实战。 具体的文章为：Netty+Protobuf 整合一：实战案例，带源码 另外，专门开出一篇...
Netty - 粘包和半包(上)
death05的博客
10-23 1120
在网络传输中，粘包和半包应该是最常出现的问题，作为 Java 中最常使用的 NIO 网络框架 Netty，它又是如何解决的呢？今天就让我们来看看。 定义 TCP 传输中，客户端发送数据，实际是把数据写入到了 TCP 的缓存中，粘包和半包也就会在此时产生。 客户端给服务端发送了两条消息ABC和DEF，服务端这边的接收会有多少种情况呢？有可能是一次性收到了所有的消息ABCDEF，有可能是收到了三条消息...
netty学习1：NioEventLoopGroup 事件循环组源码分析
weixin_45453628的博客
05-18 1323
netty学习1：NioEventLoopGroup 事件循环组源码分析
Netty使用篇：半包&粘包
最新发布
七叔的博客
11-13 2万+
Netty使用篇：半包&粘包
Netty进阶：粘包与半包-解决方案
weixin_41377877的博客
10-17 829
粘包与半包-解决方案
Netty 粘包 拆包 | 史上最全解读
热门推荐
架构师尼恩
11-11 2万+
Netty 粘包/半包原理与拆包实战（史上最全） 疯狂创客圈 Java 聊天程序【 亿级流量】实战系列之13 【博客园 总入口 】 本文的源码工程：Netty 粘包/半包原理与拆包实战 源码 本实例是《Netty 粘包/半包原理与拆包实战》 一文的源代码工程。 写在前面 大家好，我是作者尼恩。 为了完成了一个高性能的 Java 聊天程序，在前面的文章中，尼恩已经再一次的进行了通讯协议的重新...
Netty 解决粘包/半包问题
weixin_33777877的博客
01-26 1225
2019独角兽企业重金招聘Python工程师标准>>> ...
netty之黏包半包问题详解
小尘_OnMyWay的博客
04-06 630
文章目录黏包问题半包问题出现问题的原因解决方案短连接定长解码器行解码器LTC解码器 黏包问题 在客户端循环发送十次数据，服务器端会出现黏包现象。 ChannelFuture future = bootstrap.handler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) throws
Dubbo源码探索：SPI机制与Netty粘包拆包解析
在网络通信中，由于数据传输的特性，可能会出现粘包和半包现象，即多个数据包合并成一个大的数据包发送，或者一个数据包被分割成多个部分。这对于基于固定长度或者特定分隔符的协议解析是挑战。在Dubbo中，使用...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值