粘包的主要原因:
• 发送方每次写入数据 < 套接字缓冲区大小
• 接收方读取套接字缓冲区数据不够及时
半包的主要原因:
• 发送方写入数据 > 套接字缓冲区大小
• 发送的数据大于协议的 MTU(Maximum Transmission Unit,最大传输单元),必须拆包
根本原因:
TCP 是流式协议,消息无边界。
提醒:UDP 像邮寄的包裹,虽然一次运输多个,但每个包裹都有“界限”,一个一个签收,
所以无粘包、半包问题。
解决粘包和半包问题的几种常用方法
解决问题的根本手段:找出消息的边界
Netty 对三种常用封帧方式的支持
实战中使用 protobuf 协议系列化:
protobuf是google序列化的工具,主要是把数据序列化成二进制的数据来传输用的。它主要优点如下:
1.性能好,效率高;
2.跨语言(JAVA自带的序列化,不能跨语言)
其实,在netty中使用Protobuf需要注意的是:
protobufDecoder仅仅负责编码,并不支持读半包,所以在之前,一定要有读半包的处理器。
有三种方式可以选择:
使用netty提供ProtobufVarint32FrameDecoder
继承netty提供的通用半包处理器 LengthFieldBasedFrameDecoder
继承ByteToMessageDecoder类,自己处理半包
• 一次解码器:ByteToMessageDecoder
• io.netty.buffer.ByteBuf (原始数据流)-> io.netty.buffer.ByteBuf (用户数据)
• 二次解码器:MessageToMessageDecoder<I>
• io.netty.buffer.ByteBuf (用户数据)-> Java Object
选择编解码方式的要点
• 空间:编码后占用空间
需要比较不同的数据大小情况
https://www.howtoautomate.in.th/protobuf-101/2017-05-06-10_30_22-serialization-performance-comparisonxmlbinaryjsonp/
• 时间:编解码速度
需要比较不同的数据大小情况
https://www.howtoautomate.in.th/protobuf-101/2017-05-06-10_30_34-serialization-performance-comparisonxmlbinaryjsonp/
大多数都会选择 Google Protobuf
• Protobuf 是一个灵活的、高效的用于序列化数据的协议。
• 相比较 XML 和 JSON 格式,Protobuf 更小、更快、更便捷。
• Protobuf 是跨语言的,并且自带了一个编译器(protoc),只需要用它进行编译,可
以自动生成 Java、Python、C++ 等代码,不需要再写其他代码。
[ 写法比较简单 网上很多例子 可以参考 ]