底层连接tcp连接，它怎么就建立起来了？【服务器端】
【Server端】
先说说，连接配置
协议类型（指定commandFactory）、端口、发送缓冲队列最大字节数、回调线程池、允许的最大回调个数、定时扫描连接的时间间隔，云云；
配置都清楚了，那就开工吧
根据配置，创建上下文context；
可能会有各种事件过来吧，得注册监听器和处理器
在context中注册：各种类型的命令，生命周期连接监听器，连接选择器，心跳包处理器，云云；
请个大管家：控制器controller
在controller中设置：backlog参数、协议工厂、handler（这个很重要）、关闭连接时逗留的超时值、socket配置、selector池大小、读事件派发器；
万事俱备，所有人注意！开工啦！
controller绑上本地IP、端口：selectorManager/reactor开工，socketchannel绑IP，建会话，各listener开工；
还是想，说个故事，可能不够精准，但味道应该是对的：
- 有位老爷，他知道家里所有的事，他脑子里有详细完整的context；
- controller是大管家，管些细琐杂务，负责与外部打交道，如各堂主、舵主、帮主；
- 某舵主（client）愿意与老爷合作，好，建立连接，这边翠喜（processor）就处理相关事宜；
- 该舵主（client）要做某件事，好，处理请求，这边阿福（processor）处理相关事宜；
- 该舵主（client）派下人，抽得空的时候，发个心跳包过来，看看老爷这边是否都还好，这边阿贵（processor）处理相关事宜；
- 该舵主（client）不想合作了，好，断开连接，这边秋香（processor）处理善后事宜；
- 老爷会定时寻问下人，与各主的联系是否都还存在，定时扫描连接；
- ……（未完待续）
【问&答】
1. handler是如何注入的？一层一层如何调上来？
应用层：各种handler会全部注册到上下文里。
通讯层：统一的handler来处理，解析出具体消息类型，寻找到具体处理器，进行处理；
粘合应用层与通讯层的，是session。
2. session横在中间（通讯与应用层），是什么作用？
a).对于应用层，session就表示“一个连接”，其看不到下面更多的细节。session与connection保持一一对应关系。
b). session配置：session过期时间，是否并行读写，消息派发器，队列，socketChannel信息, reactor/selector信息, handler（总的）, 协议工厂（总的）。
c). session对通信层上来的各种事件，进行派发（session附着在selectionkey上），其handler会解析出具体消息类型，寻找到具体处理器，进行处理；
3. Server端面对几百个、几千个连接，是如何建立socket连接的（reactor毕竟只有那么几个）？能否建立上万、几十万个连接，如果不能，瓶颈在哪里？
a). reactor过来的事件，如果是OP_ACCEPT，那么服务器端就要接受人家的socketchannel连接请求：SocketChannel socketChannel = serverSocketChannel.accept();
b). reactor/selector只是个多路复用器，个数多为 n*CPU 个，具体负责转发各种事件：OP_CONNECT, OP_ACCEPT, OP_READ, OP_WRITE。它的工作很纯粹，就是从操作系统中取出各类事件，交由相应人员处理即可；
c). 接受client端socket请求，底层三次握手，由操作系统代劳了。我们在reactor程序里，只需获取到selectionKey进行后续操作。
d). 如果机器够牛？能不能建几十万个连接呢？未完待续……
