Netty 源码剖析与实战
傅健
Netty 源码贡献者、Cisco 高级软件工程师
32935 人已学习
新⼈⾸单¥59
课程目录
已完结/共 60 讲
第一章:初识Netty:背景、现状与趋势 (7讲)
第三章:Netty源码:从“线”(请求处理)的角度剖析 (8讲)
第六章:成长为Netty的贡献者 (6讲)
Netty 源码剖析与实战
登录|注册
留言
7
收藏
沉浸
阅读
分享
手机端
回顶部
当前播放: 49 | 安全增强:启用空闲监测
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 | 结课测试&结束语
本节摘要
登录 后留言

全部留言(7)

  • 最新
  • 精选
fancion
请问老师,这里的断开链接和心跳本身冲突没?怎么理解好一点?

作者回复: 你把断开连接理解成为了防止恶意的人做连接不做事的情况,而心跳是为了自己信任的机器没做事也不被断开连接,这样理解就不冲突了。那你可能会想那恶意的人也定时发乱七八糟的信息不就行了?所以我们加了授权,第一个消息必须是授权。所以他也攻击不了的。总之有点饶人,可以一个一个判断需求来添加就容易理解了。 再说点饶人的话:断开是断开,心跳是心跳,心跳有的时候是为了监测已断掉的连接,而有的时候为了不断开连接而做心跳用来证明自己还在。

2019-12-05
3
有个不可
老师问一下,为什么客户端KeepaliveHandler触发时间每次都是IdleStateEvent.FIRST_WRITER_IDLE_STATE_EVENT,看了一下源码,IdleStateHandler里面的firstWriterIdleEvent初始默认为true,发过一次事件后会改为false,下次触发事件应该是IdleStateEvent.WRITER_IDLE_STATE_EVENT,难道是因为多线程的可见性问题导致的吗?

作者回复: 不是的,是因为KeepaliveHandler里面遇到idle就写了keepalive数据,所以相当于重置了idle的状态,具体而言: 写的时候(idleStateHandler#write)会回调:IdleStateHandler#writeListener 然后重置了状态位: firstWriterIdleEvent = firstAllIdleEvent = true; 从你的这个问题,你可以去理解下为什么要区分第一次和后面的。你可以这样测下,就是把client的idle检测后的发送消息去掉,然后把server的idle check后的关闭连接给去掉,进而测试体会下。谢谢。

2020-01-02
2
WING
老师,如果黑客知道了服务端的地址和端口,然后只是进行大量的TCP连接(大量肉鸡),不发任何信息。服务端idle检查后主动关闭channel,因为是服务端主动关闭的,这样会不会导致大量的TIME_WAIT消耗服务端的资源?如果会有什么办法防御?

作者回复: 如果别人知道你的服务器IP,你说的情况确实会发生; 所以idle保护仅仅是减缓这种情况,还需要其他的,比如紧接着的第50节“黑白名单”,但是直接使用可能不够,需要写一些代码。总结一下对这种问题的一些做法供你参考和选择: (1)设置一个ip只能建N个连接,当然这个是根据需求来的,就是根据实际情况减少建太多连接的情况 (2)如果一个ip做的连接因为idle断连,且断连的时候还没有经过任何授权(可以在连接上设置一个attribute属性,比如IsAuth来标记可做过授权),只要N次以上,则自动将ip加入黑名单,以后不给它再做连接了:需要自己写写代码。 (3)下下策:考虑设置so_reuseaddr来减少time_wait时间(当然或许本来你就设置了,那样会很快解除time_wait状态的) 等等吧,总之根据攻击特征做防范就行。

2020-01-06
3
1
Peter
老师2个问题:我们课程里老出现的这个 “共享” 是什么意思啊,是谁跟谁共享什么?第二个问题怎么判断我们写的一个Handler要不要共享?

作者回复: 不同channel的某一个handler对象是否相同,共享判断方法参考直播的pdf(课程git里)里面有,可以下载下看看。这里我不重复复制粘贴了。

2019-12-13
1
被过去推开
只要在pipeline加入了idle检测相关的handler,就不用去设置childOption中的keepalive选项了,这个对吗?

作者回复: 不一样,层次不同,一个是tcp层的,一个是应用层的,你如果上层做过了,下层不做确实也可以。

2020-03-12
Geek_1cc6d1
老师,在网络断开后到调用writeAndFlush 抛出异常之间的时间是什么参数配置的(这个时间是超过心跳检查时间的)
2021-05-14
1
夏目
老师,你这里客户端发送的keepalive消息好像就是一个正常的消息发送,在服务端那边会解析处理的吧
2020-05-27
1
收起评论