netty如何处理粘包半包

文章目录 NIO中存在问题粘包半包滑动窗口MSS 限制Nagle 算法 解决方案

NIO中存在问题 粘包 现象，发送 abc def，接收 abcdef原因 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包Nagle 算法：会造成粘包（将小的数据包组合成一个更大的数据包进行发送，以此来减少网络中数据包的数量，从而提高网络带宽的利用率，降低网络拥塞的可能性。具体来说，当应用程序产生数据后，Nagle 算法会等待一段时间，看是否还有后续的数据需要发送。如果在等待时间内有新的数据产生，就会将这些数据与之前的数据合并成一个数据包发送；只有当等待时间结束且没有新数据产生时，才会将已有的数据发送出去。） 半包 现象，发送 abcdef，接收 abc def原因 应用层：接收方 ByteBuf 小于实际发送数据量滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包 滑动窗口

TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差。为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值。

窗口实际就起到一个缓冲区的作用，同时也能起到流量控制的作用

图中深色的部分即要发送的数据，高亮的部分即窗口窗口内的数据才允许被发送，当应答未到达前，窗口必须停止滑动如果 1001~2000 这个段的数据 ack 回来了，窗口就可以向前滑动接收方也会维护一个窗口，只有落在窗口内的数据才能允许接收 MSS 限制

链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如

以太网的 MTU 是 1500

FDDI（光纤分布式数据接口）的 MTU 是 4352

本地回环地址的 MTU 是 65535 - 本地测试不走网卡

MSS 是最大段长度（maximum segment size），它是 MTU 刨去 tcp 头和 ip 头后剩余能够作为数据传输的字节数

ipv4 tcp 头占用 20 bytes，ip 头占用 20 bytes，因此以太网 MSS 的值为 1500 - 40 = 1460

TCP 在传递大量数据时，会按照 MSS 大小将数据进行分割发送

MSS 的值在三次握手时通知对方自己 MSS 的值，然后在两者之间选择一个小值作为 MSS

Nagle 算法 即使发送一个字节，也需要加入 tcp 头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送 如果 SO_SNDBUF 的数据达到 MSS，则需要发送如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭如果 TCP_NODELAY = true，则需要发送已发送的数据都收到 ack 时，则需要发送上述条件不满足，但发生超时（一般为 200ms）则需要发送除上述情况，延迟发送 解决方案 短链接，发一个包建立一次连接，这样连接建立到连接断开之间就是消息的边界，缺点效率太低每一条消息采用固定长度，缺点浪费空间每一条消息采用分隔符，例如 \n，缺点需要转义每一条消息分为 head 和 body，head 中包含 body 的长度

半包用短连接还是不好解决，因为接收方的缓冲区大小是有限的。固定长度数据包的大小不好把握，长度定的太大，浪费， 长度定的太小，对某些数据包又显得不够。固定分隔符处理字符数据比较合适，但如果内容本身包含了分隔符（字节数据常常会有此情况），那么就会解析错误。对netty而言，Netty 提供了多种方式来处理这些问题，就看你选择使用哪种方式处理粘包半包，要保证客户端与服务端配合处理，服务端根据与客户端协商的处理方案采用合适的解码器。

如下面的长度域解码器案例

import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.ChannelInitializer; import io.netty.channel.ChannelOption; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioServerSocketChannel; import io.netty.handler.codec.LengthFieldBasedFrameDecoder; import io.netty.handler.codec.string.StringDecoder; import io.netty.handler.codec.string.StringEncoder; public class NettyServerWithLengthField { private final int port; public NettyServerWithLengthField(int port) { this.port = port; } public void run() throws Exception { EventLoopGroup bossGroup = new NioEventLoopGroup(); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override public void initChannel(SocketChannel ch) throws Exception { // 长度字段位于消息的第0个字节，长度为4字节，长度字段的值包含长度字段本身 ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(8192, 0, 4, 0, 4)); ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new NettyServerHandler()); } }) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true); ChannelFuture f = b.bind(port).sync(); f.channel().closeFuture().sync(); } finally { workerGroup.shutdownGracefully(); bossGroup.shutdownGracefully(); } } public static void main(String[] args) throws Exception { new NettyServerWithLengthField(8080).run(); } }