《跟闪电侠学Netty》阅读笔记 - Netty入门程序解析(二)

简介: 《跟闪电侠学Netty》阅读笔记 - Netty入门程序解析

《跟闪电侠学Netty》阅读笔记 - Netty入门程序解析(一)https://developer.aliyun.com/article/1395286

Bootstrap

客户端连接不需要监听端口,为了和服务端区分直接被叫做Bootstrap,代表客户端的启动引导器。


Bootstrap bootstrap = new Bootstrap();

NioEventLoopGroup

Netty中客户端也同样需要设置线程模型才能和服务端正确交互,客户端的NioEventLoopGroup同样可以看作是线程池,负责和服务端的数据读写处理。


NioEventLoopGroup eventExecutors = new NioEventLoopGroup();

group

客户端 group 线程池的设置只需要一个即可,因为主要目的是和服务端建立连接(只需要一个线程即可)。


.group(eventExecutors)

channel

和服务端设置同理,作用是底层编程模型的设置。官方注释中推荐使用NIO / EPOLL / KQUEUE这几种,使用最多的是NIO


.channel(NioSocketChannel.class)

这里比较好奇如果用OIO模型的客户端连接NIO的服务端会怎么样? 于是做了个实验,把如下代码改为OioServerSocketChannel(生产禁止使用,此方式已被Deprecated),启动服务端之后启动客户端即可观察效果。


.channel(OioServerSocketChannel.class)

从实验结果来看,显然不允许这么干。


15:24:00.934 [main] WARN  io.netty.bootstrap.Bootstrap - Unknown channel option 'SO_KEEPALIVE' for channel '[id: 0xd0aaab57]'
15:24:00.934 [main] WARN  io.netty.bootstrap.Bootstrap - Unknown channel option 'TCP_NODELAY' for channel '[id: 0xd0aaab57]'

handler

上文介绍服务端的时候提到过 handler()代表服务端启动过程当中的逻辑,在这里自然就表示客户端启动过程的逻辑,客户端的handler()可以直接看作服务端引导器当中的childHandler()

这里读者可能会好奇为什么客户端代码用childHandler呢?答案是Netty为了防止使用者误解Bootstrap中只有handler,所以我们可以直接等同于服务端的childHandler()

吐槽:这个child不child的API名称看的比较蛋疼,不加以区分有时候确实容易用错。这里生活化理解服务端中的childHandler是身上带了连接,所以在连接成功之后会调用,没有child则代表此时没有任何连接,所以会发送在初始化的时候调用。

而客户端为什么只保留 handler() 呢?个人理解是客户端最关注的是连接上服务端之后所做的处理,增加初始化的时候做处理没啥意义,并且会导致设计变复杂。

handler内部是对于Channel进行初始化并且添加pipline自定义客户端的读写逻辑。这里同样添加Netty提供的StringEncoder默认会是用字符串编码模式对于发送的数据进行编码处理。


channel.pipeline().addLast(new StringEncoder());

ChannelInitializer可以直接类比SocketChannel

connect

当配置都准备好之后,客户端的最后一步是启动客户端并且和服务端进行TCP三次握手建立连接。这里方法会返回Channel对象,Netty的connect支持异步连接。


Channel channel = bootstrap.connect("127.0.0.1", 8000).channel();

再次强调,connect 是一个异步方法,同样可以通过给返回的channel对象调用addListner添加监听器,在Netty的客户端成功和服务端建立连接之后会回调相关方法告知监听器所有数据准备完成,此时可以在监听器中添加回调之后的处理逻辑。

我们还可以用监听器对于连接失败的情况做自定义处理逻辑,比如下面例子将会介绍利用监听器实现客户端连接服务端失败之后,定时自动重连服务端多次直到重连次数用完的例子。

实践:客户端失败重连

第二个实践代码是客户端在连接服务端的时候进行失败重连。失败重连在网络环境较差的时候十分有效,但是需要注意这里的代码中多次重试会逐渐增加时间间隔。

客户端失败重连的整体代码如下:


private static void connect(Bootstrap bootstrap, String host, int port, int retry) {  
    bootstrap.connect(host, port).addListener(future -> {  
        if (future.isSuccess()) {  
            System.out.println(new Date() + ": 连接成功,启动控制台线程……");  
            Channel channel = ((ChannelFuture) future).channel();  
            startConsoleThread(channel);  
        } else if (retry == 0) {  
            System.err.println("重试次数已用完,放弃连接!");  
        } else {  
            // 第几次重连  
            int order = (MAX_RETRY - retry) + 1;  
            // 本次重连的间隔  
            int delay = 1 << order;  
            System.err.println(new Date() + ": 连接失败,第" + order + "次重连……");  
            bootstrap.config().group().schedule(() -> connect(bootstrap, host, port, retry - 1), delay, TimeUnit  
                    .SECONDS);  
        }  
    });  
}
private static void startConsoleThread(Channel channel) {  
    ConsoleCommandManager consoleCommandManager = new ConsoleCommandManager();  
    LoginConsoleCommand loginConsoleCommand = new LoginConsoleCommand();  
    Scanner scanner = new Scanner(System.in);  
    new Thread(() -> {  
        while (!Thread.interrupted()) {  
            if (!SessionUtil.hasLogin(channel)) {  
                loginConsoleCommand.exec(scanner, channel);  
            } else {  
                consoleCommandManager.exec(scanner, channel);  
            }  
        }  
    }).start();  
}

加入失败重连代码之后,客户端的启动代码需要进行略微调整,在链式调用中不再使用直接connection,而是传递引导类和相关参数,通过递归的方式实现失败重连的效果:


connect(bootstrap, "127.0.0.1", 10999, MAX_RETRY);

客户端API其他方法和相关属性

attr()

  • NioChannel绑定自定义属性
  • 底层实际为Map
  • NioSocketChannel存储参数使用此方法取出

三种TCP关联参数

SO_KEEPALIVE

对应源码定义如下:


public static final ChannelOption<Boolean> SO_KEEPALIVE = valueOf("SO_KEEPALIVE");

主要关联TCP底层心跳机制。SO_KEEPALIVE用于开启或者关闭保活探测,默认情况下是关闭的。当SO_KEEPALIVE开启时,可以保持连接检测对方主机是否崩溃,避免(服务器)永远阻塞于TCP连接的输入。

TCP_NODELAY

Nagle 算法解释

这个参数的含义是:是否开启Nagle算法。首先需要注意这个参数和Linux操作系统的默认值不一样,true 传输到Linux是关闭调Nagle算法。

Nagele算法的出现和以前的网络带宽资源有限有关,为了尽可能的利用网络带宽,TCP总是希望尽可能的发送足够大的数据,Nagle算法就是为了尽可能发送大块数据,避免网络中充斥着许多小数据块

为了理解Nagle算法,我们需要了解TCP的缓冲区通常会设置 MSS 参数。

MSS 参数:除去 IP 和 TCP 头部之后,一个网络包所能容纳的 TCP 数据的最大长度; 最大 1460。MTU:一个网络包的最大长度,以太网中一般为 1500 字节;

为什么最大为1460个字节? 因为TCP传输过程中都会要求绑定 TCP 和 IP 的头部信息,这样服务端才能回送ACK确认收到包正确。

也就是说传输大数据包的时候,数据会按照MSS的值进行切割。回到Nagle算法,它的作用就是定义任意时刻只能有一个未被ACK确认的小段(MSS对应切割的一个块)。

这就意味着当有多个未被ACK确认的小段的时候,此时client端会小小的延迟一下等待合并为更大的数据包才发送。

Netty 默认关闭了这个算法,意味着一有数据就理解发送,满足低延迟和高并发的设计。

Netty源码关联

TCP_NODELAY 配置选项定义如下:


public static final ChannelOption<Boolean> TCP_NODELAY = valueOf("TCP_NODELAY");

此参数的配置介绍可以从 SocketChannelConfig 关联的配置中获取。


/**  
 * Gets the {@link StandardSocketOptions#TCP_NODELAY} option.  Please note that the default value of this option  
 * is {@code true} unlike the operating system default ({@code false}). However, for some buggy platforms, such as  
 * Android, that shows erratic behavior with Nagle's algorithm disabled, the default value remains to be * {@code false}.  
 */
 boolean isTcpNoDelay();

注释翻译如下。

获取 StandardSocketOptions.TCP_NODELAY 配置。请注意,该选项的默认值为 true,与操作系统的默认值(false)不同。然而,对于一些有问题的平台,比如Android,在禁用Nagle算法的情况下会出现不稳定的行为,默认值仍然为false。

CONNECTION_TIMEOUT

表示连接超时时间,单位为毫秒。

客户端和服务端通信

本部分可以参考作者代码,这里仅仅用笔记归档一下大致代码编写思路。

github.com/lightningMa…

客户端写入数据到服务端

  • handler 方法:指定客户端通信处理逻辑
  • initChannel 方法:给客户端添加逻辑处理器
  • pipeline:逻辑处理链添加逻辑处理器
  • addLast 添加自定义ChannelHandler
  • 逻辑处理器继承自ChannelHandler
  • 覆盖channelActive()方法
  • 客户端连接建立成功提示打印
  • 逻辑处理器可以通过继承适配类ChannelInboundHandlerAdapter实现简化开发
  • 写数据部分ByteBuf (Netty实现)
  1. alloc获得内存管理器
  2. byte[] 数据填充二进制数据
  3. writeAndFlush 刷缓存

服务端读取客户端数据

  • 逻辑处理器继承适配类
  • 逻辑处理器可以通过继承适配类ChannelInboundHandlerAdapter实现简化开发
  • 接收数据和服务端读取数据类似
  • 构建ByteBuf
  1. alloc获得内存管理器
  2. byte[] 数据填充二进制数据
  3. writeAndFlush 刷缓存
  • 通过writeAndFlush写出数据给客户端

服务端返回数据给客户端

  • 逻辑处理器继承适配类
  • 逻辑处理器可以通过继承适配类ChannelInboundHandlerAdapter实现简化开发
  • 接收数据和服务端读取数据类似
  • 构建ByteBuf
  1. alloc获得内存管理器
  2. byte[] 数据填充二进制数据
  3. writeAndFlush 刷缓存
  • 通过writeAndFlush写出数据给客户端

客户端读取服务端数据

  • 和服务端读取客户端数据思路类似
  • 关键是需要覆盖channelRead() 方法

核心概念

  • Netty当中,childHanlder 和 handler 对应客户端服务端处理逻辑
  • ByteBuf 数据载体,类似隧道两端的中间小推车。JDK官方实现java.nio.ByteBuffer存在各种问题,Netty官方重新实现了io.netty.buffer.ByteBuf
  • 服务端读取对象基本单位为Object,如果需要读取其他对象类型通常需要强转。
  • 逻辑处理器都可以通过继承适配器实现,客户端和服务端覆盖对应方法实现被动接收或者主动推送。

章节末尾问题

客户端API对比服务端少了什么内容?

  1. “group”。
  2. 客户端只有childHandler

新连接接入时候,如何实现服务端主动推送消息,然后客户端进行回复?

答案是添加监听器,在监听到客户端连接成功之后直接主动推送自定义信息。

handler()和childHandler()有什么区别

初学者比较容易困扰的问题。handler()childHandler()的主要区别是:handler()是发生在初始化的时候childHandler()是发生在客户端连接之后

“知其所以然”的部分放到后续的源码分析笔记当中,这里暂时跳过,初次阅读只需要记住结论即可。

八股

BIO的Socket和NIO的SocketChannel 区别?

本质上都是客户端和服务端进行网络通信的连接的一种抽象,但是使用上有不小的区别。下面的内容摘录自参考资料:

Socket、SocketChannel区别:blog.csdn.net/A350204530/…Netty Channel的理解:segmentfault.com/q/101000001…

相关文章
|
1天前
|
存储 NoSQL Redis
Redis入门到通关之数据结构解析-SkipList
Redis入门到通关之数据结构解析-SkipList
|
1天前
|
存储 NoSQL 安全
Redis入门到通关之数据结构解析-动态字符串SDS
Redis入门到通关之数据结构解析-动态字符串SDS
|
1天前
|
存储 NoSQL Java
Redis入门到通关之数据结构解析-Dict
Redis入门到通关之数据结构解析-Dict
|
4天前
|
存储 开发工具 对象存储
Javaweb之SpringBootWeb案例之阿里云OSS服务入门的详细解析
Javaweb之SpringBootWeb案例之阿里云OSS服务入门的详细解析
11 0
|
前端开发 Java
Netty In Action中文版 - 第二章:第一个Netty程序
Netty In Action中文版 - 第二章第一个Netty程序 本章介绍 获取Netty4最新版本 设置运行环境来构建和运行netty程序 创建一个基于Netty的服务器和客户端 拦截和处理异常 编写和运行Netty服务器和客户端 本章将简单介绍Netty的核心概念这个狠心概念就是学习Netty是如何拦截和处理异常对于刚开始学习netty的读者利用netty的异常拦截机制来调试程序问题很有帮助。
1542 0
|
7月前
|
监控 Java Linux
由浅入深Netty基础知识NIO网络编程1
由浅入深Netty基础知识NIO网络编程
40 0
|
7月前
|
缓存 安全 Java
由浅入深Netty基础知识NIO三大组件原理实战 2
由浅入深Netty基础知识NIO三大组件原理实战
47 0
|
7月前
|
Java
由浅入深Netty基础知识NIO三大组件原理实战 1
由浅入深Netty基础知识NIO三大组件原理实战
61 0
|
2月前
|
移动开发 编解码 网络协议
用Java的BIO和NIO、Netty来实现HTTP服务器(三) 用Netty实现
用Java的BIO和NIO、Netty来实现HTTP服务器(三) 用Netty实现
|
2月前
|
编解码 网络协议 Java
用Java的BIO和NIO、Netty实现HTTP服务器(一) BIO与绪论
用Java的BIO和NIO、Netty实现HTTP服务器(一) BIO与绪论

推荐镜像

更多