目录
基本说明
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有可能出现粘包拆包的问题,这个类会对入站数据进行缓冲,直到它准备好被处理.
- 一个关于
ByteToMessageDecoder
实例分析
- 关系继承图
public class ToIntegerDecoder extends ByteToMessageDecoder {
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
if (in.readableBytes() >= 4) {
out.add(in.readInt());
}
}
}
说明:
这个例子,每次入站从ByteBuf
中读取4字节,将其解码为一个int
,然后将它添加到下一个List
中。当没有更多元素可以被添加到该List
中时,它的内容将会被发送给下一个ChannelInboundHandler
。int
在被添加到List
中时,会被自动装箱为Integer
。在调用readInt
()方法前必须验证所输入的ByteBuf
是否具有足够的数据
decode
执行分析图 [示意图]
Handler调用链机制
使用自定义的编码器和解码器来说明Netty
的handler
调用机制
- 客户端发送long -> 服务器
- 服务端发送long -> 客户端
客户端发送long -> 服务器
服务端代码
服务端:
public class MyServer {
public static void main(String[] args) {
NioEventLoopGroup bossGroup = new NioEventLoopGroup(1);
NioEventLoopGroup workerGroup = new NioEventLoopGroup();
try{
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.group(bossGroup,workerGroup)
.channel(NioServerSocketChannel.class)
.childHandler(new MyServerInitializer());
ChannelFuture sync = serverBootstrap.bind(8003).sync();
sync.channel().closeFuture().sync();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
}
}
ChannelInitializer
:
public class MyServerInitializer extends ChannelInitializer<SocketChannel> {
@Override
protected void initChannel(SocketChannel channel) throws Exception {
ChannelPipeline pipeline = channel.pipeline();
//入站的handler进行解码 MyByteToLongDecoder
pipeline.addLast(new MyByteToLongDecoder());
//自定义的handler,处理业务逻辑
pipeline.addLast(new MyServerHandler());
}
}
入站的解码编码器:将byte
解码为long
,为啥不用while
呢?下面有解释。
public class MyByteToLongDecoder extends ByteToMessageDecoder{
//上下文channelHandlerContext
//入站的ByteBuf
//List集合,将解码后的数据传给下一个handler
@Override
protected void decode(ChannelHandlerContext channelHandlerContext, ByteBuf byteBuf, List list) throws Exception {
System.out.println("MyByteToLongDecoder被调用");
//因为long8字节,8个字节,才能读取一个long
if (byteBuf.readableBytes()>=8){
list.add(byteBuf.readLong());
}
}
}
自定义handler:
public class MyServerHandler extends SimpleChannelInboundHandler<Long> {
@Override
protected void channelRead0(ChannelHandlerContext channelHandlerContext, Long aLong) throws Exception {
System.out.println("从客户端"+channelHandlerContext.channel().remoteAddress()+" 读取到long "+aLong);
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
cause.printStackTrace();
ctx.close();
}
}
客户端代码
客户端:
public class MyClient {
public static void main(String[] args) {
NioEventLoopGroup eventExecutors = new NioEventLoopGroup();
try{
Bootstrap bootstrap = new Bootstrap();
bootstrap.group(eventExecutors)
.channel(NioSocketChannel.class)
.handler(new MyClientInitializer());
ChannelFuture sync = bootstrap.connect("127.0.0.1", 8003).sync();
sync.channel().closeFuture().sync();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
eventExecutors.shutdownGracefully();
}
}
}
ChannelInitializer
:
public class MyClientInitializer extends ChannelInitializer<SocketChannel> {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
//加入出站编码handler
pipeline.addLast(new MyLongToByteEncoder());
//加入一个自定义的handler
pipeline.addLast(new MyClientHandler());
}
}
出站编码handler
:将Long转成byte
public class MyLongToByteEncoder extends MessageToByteEncoder<Long> {
//编码方法
@Override
protected void encode(ChannelHandlerContext ctx, Long msg, ByteBuf out) throws Exception {
System.out.println("MyLongToByteEncoder encoder 被调用");
System.out.println("msg="+msg);
out.writeLong(msg);
}
}
自定义handler
:用ChannelOutboundHandlerAdapter
更合适?
public class MyClientHandler extends SimpleChannelInboundHandler<Long> {
//通道就绪时,发送数据
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("MyClientHandler 发送数据");
ctx.writeAndFlush(123465L);
}
}
测试
启动服务端和客户端。
服务端:
MyByteToLongDecoder被调用
从客户端/127.0.0.1:53198 读取到long 123465
客户端:
MyClientHandler 发送数据
MyLongToByteEncoder encoder 被调用
msg=123465
总结:
从打印日志看出
对于客户端是出站,处于尾部,因此是先调用的自定义的handler
,MyClientHandler
,然后才是调用出站编码handler
。
即MyLongToByteEncoder <---MyClientHandler
。
对于服务端是入站,处于头部,因此先调用解码,然后才执行自定义handler
。
即MyServerHandler <----MyByteToLongDecoder
两个细节问题
1.问题1,如果客户端自定义的handler
发送的是下面这个代码,数据是16个字节,那么服务端的入解码器的decode
方法会被调用几次?
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("MyClientHandler 发送数据");
// ctx.writeAndFlush(123465L);
//abcdabcdabcdabcd是16个字节
ctx.writeAndFlush(Unpooled.copiedBuffer("abcdabcdabcdabcd", CharsetUtil.UTF_8));
}
对于decode
方法会根据接收到的数据,被调用多次,直到确定没有新的元素被添加到list
或者是ByteBuf
没有更多的可读字节为止。如果list
不为空,就会将list
内容传递给下一个ChannelInboundhandler
处理,改处理器的方法也会被调用多次。
这里"abcdabcdabcdabcd
"是16个字节,所以服务端解码的时候decode
会被调两次,每次解码出来的数据放到list
里面,list
的里数据传给自定义的handler
进行处理。
2.使用问题1的代码片段后,发现,客户端的出站编码handler-》MyLongToByteEncoder
,没有被调用,怎么回事呢?
对于客户端的自定义handler
的前一个handler
是MyLongToByteEncoder
,MyLongToByteEncoder
父类MessageToByteEncoder
有一个write
方法:
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
ByteBuf buf = null;
try {
//判断数据是不是应该处理的类型,是的话调用encode方法,进行编码,不是,就不编码,直接write,然后交给前一个handler
if (acceptOutboundMessage(msg)) {
@SuppressWarnings("unchecked")
I cast = (I) msg;
buf = allocateBuffer(ctx, cast, preferDirect);
try {
//我们写子类的时候,重写了改方法
encode(ctx, cast, buf);
} finally {
ReferenceCountUtil.release(cast);
}
if (buf.isReadable()) {
ctx.write(buf, promise);
} else {
buf.release();
ctx.write(Unpooled.EMPTY_BUFFER, promise);
}
buf = null;
} else {
ctx.write(msg, promise);
}
因此,我们编写的Encoder
是要注意传入的数据类型和处理的数据类型一致
服务端发送long -> 客户端
基于客户端发送long -> 服务器,再实现服务端发送long -> 客户端。
原理图:
服务端
ChannelInitializer
:
//出站的handler进行编码 MyLongToByteEncoder
pipeline.addLast(new MyLongToByteEncoder());
自定义handler修改:
protected void channelRead0(ChannelHandlerContext channelHandlerContext, Long aLong) throws Exception {
System.out.println("从客户端"+channelHandlerContext.channel().remoteAddress()+" 读取到long "+aLong);
//给客户端发送一个long
channelHandlerContext.writeAndFlush(98765L);
}
客户端
ChannelInitializer
:
//加入入站解码handler
pipeline.addLast(new MyByteToLongDecoder());
自定义handler修改:
@Override
protected void channelRead0(ChannelHandlerContext ctx, Long msg) throws Exception {
System.out.println("服务器的ip="+ctx.channel().remoteAddress());
System.out.println("收到服务器消息="+msg);
}
//发送数据
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("MyClientHandler 发送数据");
ctx.writeAndFlush(123465L);
//abcdabcdabcdabcd是16个字节
// ctx.writeAndFlush(Unpooled.copiedBuffer("abcdabcdabcdabcda", CharsetUtil.UTF_8));
}
测试
启动服务端和客户端。
客户端:
服务端:
结论
- 不论解码器handler 还是 编码器handler 即接收的消息类型必须与待处理的消息类型一致,否则该handler不会被执行
- 在解码器 进行数据解码时,需要判断 缓存区(ByteBuf)的数据是否足够 ,否则接收到的结果会期望结果可能不一致
其他常用的编解码器
解码器-ReplayingDecoder
public abstract class ReplayingDecoder<S> extends ByteToMessageDecoder
ReplayingDecoder
扩展了ByteToMessageDecoder
类,使用这个类,我们不必调用readableBytes
()方法。参数S
指定了用户状态管理的类型,其中Void
代表不需要状态管理- 应用实例:使用
ReplayingDecoder
编写解码器,对前面的案例进行简化 [案例演示]
public class MyByteToLongDecoder2 extends ReplayingDecoder<Void> {
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
System.out.println("MyByteToLongDecoder被调用");
//在ReplayingDecoder不需要判断数据是否足够读取,内部会进行处理判断
out.add(in.readLong());
}
}
测试:使用MyByteToLongDecoder2
替代之前的MyByteToLongDecoder
,结果和之前的一样。
它有一些局限性:
- 并不是所有的
ByteBuf
操作都被支持,如果调用了一个不被支持的方法,将会抛出一个UnsupportedOperationException
。 ReplayingDecoder
在某些情况下可能稍慢于ByteToMessageDecoder
,例如网络缓慢并且消息格式复杂时,消息会被拆成了多个碎片,速度变慢
其它解码器
- LineBasedFrameDecoder:这个类在Netty内部也有使用,它使用行尾控制字符(\n或者\r\n)作为分隔符来解析数据。
- DelimiterBasedFrameDecoder:使用自定义的特殊字符作为消息的分隔符。
- HttpObjectDecoder:一个HTTP数据的解码器
- LengthFieldBasedFrameDecoder:通过指定长度来标识整包消息,这样就可以自动的处理黏包和半包消息。