正在write或者read的消息，需要继续处理;
设置在NioEventLoop线程调度器中的定时任务，需要执行或者清理。
Netty架构剖析之安全性
Netty面临的安全挑战：
对第三方开放
作为应用层协议的基础通信框架
安全威胁场景分析：
对第三方开放的通信框架：如果使用Netty做RPC框架或者私有协议栈，RPC框架面向非授信的第三方开放，例如将内部的一些能力通过服务对外开放出去，此时就需要进行安全认证，如果开放的是公网IP，对于安全性要求非常高的一些服务，例如在线支付、订购等，需要通过SSL/TLS进行通信。
应用层协议的安全性。作为高性能、异步事件驱动的NIO框架，Netty非常适合构建上层的应用层协议。由于绝大多数应用层协议都是公有的，这意味着底层的Netty需要向上层提供通信层的安全传输功能。
SSL/TLS
Netty安全传输特性：
1.支持SSL V2和V3
2.支持TLS
3.支持SSL单向认证、双向认证和第三方CA认证。
SSL单向认证流程图如下：
Netty通过SslHandler提供了对SSL的支持，它支持的SSL协议类型包括：SSL V2、SSL V3和TLS。
单向认证：单向认证，即客户端只验证服务端的合法性，服务端不验证客户端。
双向认证：与单向认证不同的是服务端也需要对客户端进行安全认证。这就意味着客户端的自签名证书也需要导入到服务端的数字证书仓库中。
CA认证：基于自签名的SSL双向认证，只要客户端或者服务端修改了密钥和证书，就需要重新进行签名和证书交换，这种调试和维护工作量是非常大的。因此，在实际的商用系统中往往会使用第三方CA证书颁发机构进行签名和验证。我们的浏览器就保存了几个常用的CA_ROOT。每次连接到网站时只要这个网站的证书是经过这些CA_ROOT签名过的。就可以通过验证了。
可扩展的安全特性
通过Netty的扩展特性，可以自定义安全策略：
1.IP地址黑名单机制
2.接入认证
3.敏感信息加密或者过滤机制
IP地址黑名单是比较常用的弱安全保护策略，它的特点就是服务端在与客户端通信的过程中，对客户端的IP地址进行校验，如果发现对方IP在黑名单列表中，则拒绝与其通信，关闭链路。
接入认证策略非常多，通常是较强的安全认证策略，例如基于用户名+密码的认证，认证内容往往采用加密的方式，例如Base64+AES等。
Netty架构剖析之扩展性
通过Netty的扩展特性，可以自定义安全策略：
1.线程模型可扩展
2.序列化方式可扩展
3.上层协议栈可扩展
4.提供大量的网络事件切面，方便用户功能扩展
Netty的架构可扩展性设计理念如下：
5.判断扩展点，事先预留相关扩展接口，给用户二次定制和扩展使用;
6.主要功能点都基于接口编程，方便用户定制和扩展。
精彩问答
问：据我之前了解到，Java的NIO selector底层在Windows下的实现是起两个随机端口互联来监测连接或读写事件，在Linux上是利用管道实现的;我有遇到过这样的需求，需要占用很多个固定端口做服务端，如果在Windows下，利用NIO框架(Mina或Netty)就有可能会造成端口冲突，这种情况有什么好的解决方案吗?
你说的问题确实存在，Linux使用Pipe实现网络监听，Windows要启动端口。目前没有更好的办法，建议的方式是作为服务端的端口可以规划一个范围，然后根据节点和进程信息动态生成，如果发现端口冲突，可以在规划范围内基于算法重新生成一个新的端口。
问：请我，我现在将Spring与Netty做了整合，使用Spring的Service开启 Netty主线程，但是停止整个运行容器的时候，Netty的TCP Server端口不能释放?退出处理时，有什么好的办法释放Netty Server端口么?
实际上，由谁拉起Netty 主线程并不重要。我们需要做的就是当应用容器退出的时候(Spring Context销毁)，在退出之前调用Netty 的优雅退出接口即可实现端口、NIO线程资源的释放。请参考这篇文章：http://www.infoq.com/cn/articles/netty-elegant-exit-mechanism-and-principles