2019-12-05请问老师，这里的断开链接和心跳本身冲突没？怎么理解好一点？作者回复: 你把断开连接理解成为了防止恶意的人做连接不做事的情况，而心跳是为了自己信任的机器没做事也不被断开连接，这样理解就不冲突了。那你可能会想那恶意的人也定时发乱七八糟的信息不就行了？所以我们加了授权，第一个消息必须是授权。所以他也攻击不了的。总之有点饶人，可以一个一个判断需求来添加就容易理解了。
再说点饶人的话:断开是断开，心跳是心跳，心跳有的时候是为了监测已断掉的连接，而有的时候为了不断开连接而做心跳用来证明自己还在。 1- 2020-01-06老师，如果黑客知道了服务端的地址和端口，然后只是进行大量的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状态的）
等等吧，总之根据攻击特征做防范就行。 2 - 2020-01-02老师问一下，为什么客户端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后的关闭连接给去掉，进而测试体会下。谢谢。 
2019-12-13老师2个问题：我们课程里老出现的这个 “共享” 是什么意思啊，是谁跟谁共享什么？第二个问题怎么判断我们写的一个Handler要不要共享？作者回复: 不同channel的某一个handler对象是否相同，共享判断方法参考直播的pdf(课程git里)里面有，可以下载下看看。这里我不重复复制粘贴了。