Netty 源码剖析与实战
傅健
Netty 源码贡献者、Cisco 高级软件工程师
32935 人已学习
新⼈⾸单¥59
课程目录
已完结/共 60 讲
第一章:初识Netty:背景、现状与趋势 (7讲)
第三章:Netty源码:从“线”(请求处理)的角度剖析 (8讲)
第六章:成长为Netty的贡献者 (6讲)
Netty 源码剖析与实战
登录|注册
留言
15
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 17 | 源码剖析:Netty对keepalive与idle监测的支持
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.75x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
01 | 课程介绍
02 | 内容综述
03 | 揭开Netty面纱
04 | 为什么舍近求远:不直接用JDK NIO?
05 | 为什么孤注一掷:独选Netty?
06 | Netty的前尘往事
07 | Netty的现状与趋势
08 | Netty怎么切换三种I/O模式?
09 | 源码剖析:Netty对I/O模式的支持
10 | Netty如何支持三种Reactor?
11 | 源码剖析:Netty对Reactor的支持
12 | TCP粘包/半包Netty全搞定
13 | 源码剖析:Netty对处理粘包/半包的支持
14 | 常用的“二次”编解码方式
15 | 源码剖析:Netty对常用编解码的支持
16 | keepalive与idle监测
17 | 源码剖析:Netty对keepalive与idle监测的支持
18 | Netty的那些“锁”事
19 | Netty如何玩转内存使用
20 | 源码解析:Netty对堆外内存和内存池的支持
21 | Netty代码编译与总览
22 | 源码剖析:启动服务
23 | 源码剖析:构建连接
24 | 源码剖析:接收数据
25 | 源码剖析:业务处理
26 | 源码剖析:发送数据
27 | 源码剖析:断开连接
28 | 源码剖析:关闭服务
29 | 编写网络应用程序的基本步骤
30 | 案例介绍和数据结构设计
31 | 实现服务器端编解码
32 | 实现一个服务器端
33 | 实现客户端编解码
34 | 完成一个客户端雏形
35 | 引入"响应分发"完善客户端
36 | Netty编码中易错点解析
37 | 调优参数:调整System参数夯实基础
38 | 调优参数:权衡Netty核心参数
39 | 调优参数:图解费脑的三个参数
40 | 跟踪诊断:如何让应用易诊断?
41 | 跟踪诊断:应用能可视,心里才有底
42 | 跟踪诊断:让应用内存不“泄露”?
43 | 优化使用:用好自带注解省点心
44 | 优化使用:“整改”线程模型让"响应"健步如飞
45 | 优化使用:增强写,延迟与吞吐量的抉择
46 | 优化使用:如何让应用丝般“平滑”?
47 | 优化使用:为不同平台开启native
48 | 安全增强:设置“高低水位线”等保护好自己
49 | 安全增强:启用空闲监测
50 | 安全增强:简单有效的黑白名单
51 | 安全增强:少不了的自定义授权
52 | 安全增强:拿来即用的SSL-对话呈现表象
53 | 安全增强:拿来即用的SSL-抓包暴露本质
54 | 安全增强:拿来即用的SSL-轻松融入案例
55 | Cassandra如何使用Netty ?
56 | Dubbo如何使用Netty ?
57 | Hadoop如何使用Netty ?
58 | 赏析Netty之美
59 | 如何给Netty贡献代码?
60 | 结课测试&结束语
本节摘要
登录 后留言

全部留言(15)

  • 最新
  • 精选
冬渐暖
设置keepalive参数的流程:有个用于接收连接的后续处理ServerBootstrapAcceptor,把选项设置到消息里面去(不同的io实现不同) 开启keepalive的 NioChannelOption和普通的ChannelOption的区别 NioChannelOption会优先根据jdk版本是否大于7和请求是否为NioChannelOption,如果是的话就通过NioChannelOption.setOption来设置(调用jdk的设置方法,当然,其中也包括规避jdk的一些bug版本来用自己的,这个也对应了开始章节讲的:netty的思想是解决不了的就绕过),不是的话就通过父类老方法来set(要一个一个的if else你的入参是什么类型的) idle检测 idle有三个状态:没有数据收(READER_IDLE),没有数据发送(WRTIER_IDLE),收和发都没有(ALL_IDLE)。总之跟idle状态相关的(比如event、handle) 一定有这三个状态,只是具体的类型不同 关于idle事件的状态,又根据这个状态是否为第一次来把上面的三个状态分成6个,是第一次的话就在名字前面加个FIREST_,不是就不加 idle检测核心是触发event 是通过定时任务轮询看是否有空闲并且写ing或者成功(会跟踪这个进度,通过比较哈希以及上一次待发送字节数是否不等于这次的字节数),不是idle话就再建一个定时任务

作者回复: 全部读下来,没找到你的问题,也没发现哪里不对,所以:正解!

2019-11-25
10
Ricky Fung
请教一下 option 和 childOption 设置的参数有何不同呢?

作者回复: option和childoption是设置不同socket channel的,分别服务于ServerSocketChannel和SocketChannel。 之所以用了child前缀作为区分,是因为服务的channel有父子关系(前者产生后者: SocketChannel = serverSocketChannel.accept();)。 他们都在channel初始化时使用,具体而言。前者是在启动服务时,后者是在创建连接时,但是这里有个问题是,就是可以设置的option是共享的,这就导致,一些参数(例如io.netty.channel.ChannelOption#SO_BACKLOG, )仅仅对serversocketchannel有效,但是可能会不小心设置给socketchannel。例如本应该是.option(ChannelOption.SO_BACKLOG, 100),却不小心写成了.childOption(ChannelOption.SO_BACKLOG, 100),这样的话,会发生什么?实际上并没有报错,只是后期使用时,可能无法生效,可以说是一个隐蔽的坑。这里要注意下。 所以你的问题,总结下就是:设置的参数服务目标不同,且应该根据不同的目标选择参数,当然这些参数有一些是都可以设置的,有一些却是专有的。上面的例子也说了。

2020-04-12
7
torres
老师,两点问题请教一下 1.如果想idle和keepalive配合使用,是否是需要在处理idle事件时进行编码,向客服端去发送对应的keepalive请求? 2.客户端是否要对我发送的keepalive请求进行回复,没有回复是否视为连接失效,直接断开?(此处服务端和客户端是否都要进行相应的编码?)

作者回复: 配合方式有很多种,你这种是可以的,而且很多也这么做,然后不管哪种,只要收发消息都需要编解码,所以才是统一的(不然不就不是消息的一种了么?),你在案例中可能没有看到显示编解码,而是直接写出了消息。那是因为这个写的过程经过了之前写的二对编解码器了,所以都会做的,也应该做的。

2020-01-05
2
加载中……
老师好,有个疑问请教下,如下: 一、netty使用IdleStateHandler类做idle监测 1、对于读idle监测,IdleStateHandler的子类ReadTimeoutHandler会触发ReadTimeoutException异常,自定义的handler感知到这个异常可以做一些处理操作。 2、对于写idle监测, a、如果observeOutput为false, 只有写入缓冲区成功 才算有写操作。 b、如果observeOutput为true,只要有写的意图 就算 有写操作,写意图包括:①写了,但缓冲区满了,没写成功 ②写了一个大数据,写确实在动,但没有完成。 这里些疑问: 如果有个场景:调用write方法写入了一个4个G的文件(一时半会写不完,假如每次只能写1k到缓冲区) 问题一:这对应的是b.②情况么? 问题二:如果observeOutput为false, 是要把4G都写入完缓冲区才算有写操作? 我先说下我的理解: 问题一:不知道 问题二: 1、如果observeOutput为false,虽然发送的是4个G数据,只要有n字节(n>0)写入成功 都算有写操作. 2、如果发送的是4个G的数据,判断在一段时间内有没有全部把4G写完,是WriteTimeoutHandler干的事情。

作者回复: 问题1:对的;问题2:也对,但是问题2的(1)你写反了吧?observeOutput = true。这里补充说下,这么大的文件,应该用chunk的方式那写了,否则容易OOM的。

2019-10-23
2
姚远
老师您好 最近在看dubbo源码。发现dubbo最新的release使用的还是netty3~~为什么呢。还有dubbo实现了一个keepalive的handler 对应netty来说就是业务层的keepalive了吧。

作者回复: 这个在第六章的dubbo那节都会讲到,这里先简单说下: 1 dubbo用了二个版本,有二个文件夹 2 是的,它的客户端用idle来触发keepalive了,server端的idle直接断连,两个配合一起用

2019-11-21
nomoshen
老师我有一点不明白;keepalive其实本质也是用来检测链路是否正常,而idle检测看起来也是用来检测链路是否正常;tcp的keepalive是在7200s之后如果没有数据就进行发送,那会不会在之前idle就已经被触发然后断掉连接呢? 这块没怎么搞明白?

作者回复: 会的,如果你设置idle监测的时间低于你的keepalive时间,然后没数据,就会监测到空闲后就关闭连接,就是你说的情况,所以一般把空闲监测的时间设置的比keepalive大,这样就好了。当然这里说的都是应用层keepalive.你说的那个tcp层的keepalive对应用层的idle监测并没用,idle监测是应用层在做,它看的是应用层有没有数据,而不是tcp层的,另外idle监测主要是保护系统的,优化系统的,所以连接正常也可能触发的

2019-10-30
shinee_x_X
老师,前一节课不是说tcp keepalive不好吗,怎么netty不在应用层用keepalive

作者回复: 因为应用层的keeplive属于应用层,而且每个协议,除了那些流行的外,大多是我们自己的内部写的应用,都不同,所以他不知道我们怎么定义我们的keepalive,所以他不好提供通用的实现什么的,所以我们自己要去实现keepalive.

2019-10-30
2
Gary
老师你好,keepalive发送的是什么数据来探测的,需要对端做处理吗?

作者回复: 一般就特别简单的数据。比如ping pong字符这种都可以,原则就是简单数据量小。对端一般都要处理下,但比如只想服务器看看有没有请求过来,不考虑客户端,那也可以不处理,但是作为完整性,最好还是要处理的,这样所有消息定义都是一来一回清晰

2019-10-25
2
鱼向北游
idlestate 那里的all 我看注释写的是either or 这个的意思不是或者。。或者。。么,意思是写idle或者读idle,如果是并且的关系应该是用neither nor呀

作者回复: 但是原文前面是no data.意思没有读,也没有写,用你说的表达肯定也行,就要换句表达了,二个本质都是一个意思,类似 双重否定等于肯定

2019-10-23
null
老师,请教一下 idle 和 keepalive 的关系: 1. idle_time 后,进入 idle 状态,然后发keepalive探测包,最后关闭连接。 2. 发 keepalive 探测包,7200+75*9之后,再过一段时间 idle_time,就进入 idle 状态,触发 idle_event 关闭连接。 学习16节时,我理解它俩的关系如第1点描述那样。 但是学习了17节,它俩的关系又好像第2点那样。 有点犯迷糊了,望老师回复,谢谢!
2020-10-22
1
2
收起评论