《netty实战》读书笔记四---心跳、编码解码、TCP 粘包和拆包及解决方案

最新推荐文章于 2024-06-25 17:50:43 发布

阿拉斯加大闸蟹

最新推荐文章于 2024-06-25 17:50:43 发布

阅读量1.5k

点赞数

分类专栏： netty day day study day day up

本文链接：https://blog.csdn.net/singgel/article/details/105478963

版权

day day study day day up 同时被 2 个专栏收录

18 篇文章 1 订阅

订阅专栏

netty

11 篇文章 1 订阅

订阅专栏

netty心跳

IdelStateHandler

http是无状态，Http协议是无状态的, 浏览器和服务器间的请求响应一次，下一次会重新创建连接，webSocket的长连接的全双工的交互，改变Http协议多次请求的约束，实现长连接了，服务器可以发送消息给浏览器

http传输过程中是分段的，HttpObjectAggregator可以将多个段聚合

浏览器在发送大量数据的时候，就会发出多次http请求

对应websocket，他的数据以帧（frame）的形式传递

WebSocketServerProtocolHandler核心功能是将http协议升级为ws协议，保持长连接

http协议升级ws协议，是通过一个状态码101

netty编码解码

编写网络应用程序时，因为数据在网络中传输的都是二进制字节码数据，在发送数据时就需要编码，接收数据时就需要解码

codec(编解码器) 的组成部分有两个：decoder(解码器)和 encoder(编码器)。encoder 负责把业务数据转换成字节码数据，decoder 负责把字节码数据转换成业务数据

Netty 本身的编码解码的机制和问题分析

Netty 自身提供了一些 codec(编解码器)

Netty 提供的编码器：StringEncoder，对字符串数据进行编码 ObjectEncoder，对 Java 对象进行编码

Netty 提供的解码器：StringDecoder, 对字符串数据进行解码 ObjectDecoder，对 Java 对象进行解码

Netty 本身自带的 ObjectDecoder 和 ObjectEncoder 可以用来实现 POJO 对象或各种业务对象的编码和解码，底层使用的仍是 Java 序列化技术 , 而Java 序列化技术本身效率就不高，存在如下问题

无法跨语言

序列化后的体积太大，是二进制编码的 5 倍多。

序列化性能太低

引出新的解决方案 [Google 的 Protobuf]

Protobuf 是 Google 发布的开源项目，全称 Google Protocol Buffers，是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC[远程过程调用 remote procedure call ] 数据交换格式。目前很多公司 http+json  tcp+protobuf

参考文档 : https://developers.google.com/protocol-buffers/docs/proto 语言指南 Protobuf 是以 message 的方式来管理数据的.

高性能，高可靠性

使用 protobuf 编译器能自动生成代码，Protobuf 是将类的定义使用.proto 文件进行描述。说明，在idea 中编写 .proto 文件时，会自动提示是否下载 .ptotot 编写插件. 可以让语法高亮。

然后通过 protoc.exe 编译器根据.proto 自动生成.java 文件

protobuf 使用示意图

syntax= "proto3";
//永远不要修改生成的代码，只能修改这里的代码
option optimize_for = SPEED;//加快解析速度
option java_package="atguigu.netty.codec2";//生成到哪个包下
opton java_outer_classname="MyDataInfo"; //外部类名

Netty编解码器和handler的调用机制

netty的组件设计：Netty的主要组件有Channel、EventLoop、ChannelFuture、ChannelHandler、ChannelPipe等

ChannelHandler充当了处理入站和出站数据的应用程序逻辑的容器。例如，实现ChannelInboundHandler接口（或ChannelInboundHandlerAdapter），你就可以接收入站事件和数据，这些数据会被业务逻辑处理。当要给客户端发送响应时，也可以从ChannelInboundHandler冲刷数据。业务逻辑通常写在一个或者多个ChannelInboundHandler中。ChannelOutboundHandler原理一样，只不过它是用来处理出站数据的

ChannelPipeline提供了ChannelHandler链的容器。以客户端应用程序为例，如果事件的运动方向是从客户端到服务端的，那么我们称这些事件为出站的，即客户端发送给服务端的数据会通过pipeline中的一系列ChannelOutboundHandler，并被这些Handler处理，反之则称为入站的

编码解码器

当Netty发送或者接受一个消息的时候，就将会发生一次数据转换。入站消息会被解码：从字节转换为另一种格式（比如java对象）；如果是出站消息，它会被编码成字节。

Netty提供一系列实用的编解码器，他们都实现了ChannelInboundHadnler或者ChannelOutboundHandler接口。在这些类中，channelRead方法已经被重写了。以入站为例，对于每个从入站Channel读取的消息，这个方法会被调用。随后，它将调用由解码器所提供的decode()方法进行解码，并将已经解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。

解码器-ByteToMessageDecoder

由于不可能知道远程节点是否会一次性发送一个完整的信息，tcp有可能出现粘包拆包的问题，这个类会对入站数据进行缓冲，直到它准备好被处理.

关系继承图

不论解码器handler 还是编码器handler 即接收的消息类型必须与待处理的消息类型一致，否则该handler不会被执行

在解码器进行数据解码时，需要判断缓存区(ByteBuf)的数据是否足够，否则接收到的结果会期望结果可能不一致

解码器-ReplayingDecoder

public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder

ReplayingDecoder扩展了ByteToMessageDecoder类，使用这个类，我们不必调用readableBytes()方法。参数S指定了用户状态管理的类型，其中Void代表不需要状态管理

ReplayingDecoder使用方便，但它也有一些局限性：

并不是所有的 ByteBuf 操作都被支持，如果调用了一个不被支持的方法，将会抛出一个 UnsupportedOperationException。

ReplayingDecoder 在某些情况下可能稍慢于 ByteToMessageDecoder，例如网络缓慢并且消息格式复杂时，消息会被拆成了多个碎片，速度变慢

TCP 粘包和拆包及解决方案

TCP是面向连接的，面向流的，提供高可靠性服务。收发两端（客户端和服务器端）都要有一一成对的socket，因此，发送端为了将多个发给接收端的包，更有效的发给对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据块，然后进行封包。这样做虽然提高了效率，但是接收端就难于分辨出完整的数据包了，因为面向流的通信是无消息保护边界的

由于TCP无消息保护边界, 需要在接收端处理消息边界问题，也就是我们所说的粘包、拆包问题, 看一张图