当前播放: 49 | 安全增强:启用空闲监测
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 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 | 结课测试&结束语
49 | 安全增强:启用空闲监测

49 | 安全增强:启用空闲监测

傅健
Netty源码贡献者、Cisco高级软件工程师
全集6983
新人首单 ¥29.9 原价 ¥129
2
本节摘要
登录 后留言

精选留言(6)

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

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

    2019-12-05
    2
  • 有个不可
    老师问一下,为什么客户端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
    1
  • 夏目
    老师,你这里客户端发送的keepalive消息好像就是一个正常的消息发送,在服务端那边会解析处理的吧
    2020-05-27
  • 被过去推开
    只要在pipeline加入了idle检测相关的handler,就不用去设置childOption中的keepalive选项了,这个对吗?

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

    2020-03-12
  • 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
    2
  • PeterLu
    老师2个问题:我们课程里老出现的这个 “共享” 是什么意思啊,是谁跟谁共享什么?第二个问题怎么判断我们写的一个Handler要不要共享?

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

    2019-12-13
收起评论
看过的人还看
数据结构与算法之美

王争  前Google工程师

80讲 | 90191 人已学习

新人首单 ¥29.9 原价 ¥129
Java并发编程实战

王宝令  资深架构师

51讲 | 18456 人已学习

新人首单 ¥19.9 原价 ¥99
MySQL实战45讲

林晓斌  网名丁奇,前阿里资深技术专家

49讲 | 58843 人已学习

新人首单 ¥29.9 原价 ¥129
Java核心技术面试精讲

杨晓峰  前Oracle首席工程师

44讲 | 47454 人已学习

新人首单 ¥19.9 原价 ¥99