EndPoint是一个接口，对应的抽象实现类是 AbstractEndpoint，而 AbstractEndpoint的具体子类，比如在 NioEndpoint和 Nio2Endpoint中，有两个重要的子组件：Acceptor和 SocketProcessor。
其中 Acceptor 用于监听 Socket 连接请求。SocketProcessor用于处理 Acceptor 接收到的 Socket请求，它实现 Runnable接口，在 Run方法里调用应用层协议处理组件 Processor 进行处理。为了提高处理能力，SocketProcessor被提交到线程池来执行。
我们知道，对于 Java 的多路复用器的使用，无非是两步：
创建一个 Seletor，在它身上注册各种感兴趣的事件，然后调用 select 方法，等待感兴趣的事情发生。
感兴趣的事情发生了，比如可以读了，这时便创建一个新的线程从 Channel 中读数据。
在 Tomcat 中 NioEndpoint 则是 AbstractEndpoint 的具体实现，里面组件虽然很多，但是处理逻辑还是前面两步。它一共包含 LimitLatch、Acceptor、Poller、SocketProcessor和 Executor 共 5 个组件，分别分工合作实现整个 TCP/IP 协议的处理。
LimitLatch 是连接控制器，它负责控制最大连接数，NIO 模式下默认是 10000，达到这个阈值后，连接请求被拒绝。
Acceptor跑在一个单独的线程里，它在一个死循环里调用 accept方法来接收新连接，一旦有新的连接请求到来，accept方法返回一个 Channel 对象，接着把 Channel对象交给 Poller 去处理。
Poller 的本质是一个 Selector，也跑在单独线程里。Poller在内部维护一个 Channel数组，它在一个死循环里不断检测 Channel的数据就绪状态，一旦有 Channel可读，就生成一个 SocketProcessor任务对象扔给 Executor去处理。
SocketProcessor 实现了 Runnable 接口，其中 run 方法中的 getHandler().process(socketWrapper, SocketEvent.CONNECT_FAIL); 代码则是获取 handler 并执行处理 socketWrapper，最后通过 socket 获取合适应用层协议处理器，也就是调用 Http11Processor 组件来处理请求。Http11Processor 读取 Channel 的数据来生成 ServletRequest 对象，Http11Processor 并不是直接读取 Channel 的。这是因为 Tomcat 支持同步非阻塞 I/O 模型和异步 I/O 模型，在 Java API 中，相应的 Channel 类也是不一样的，比如有 AsynchronousSocketChannel 和 SocketChannel，为了对 Http11Processor 屏蔽这些差异，Tomcat 设计了一个包装类叫作 SocketWrapper，Http11Processor 只调用 SocketWrapper 的方法去读写数据。
Executor就是线程池，负责运行 SocketProcessor任务类，SocketProcessor 的 run方法会调用 Http11Processor 来读取和解析请求数据。我们知道，Http11Processor是应用层协议的封装，它会调用容器获得响应，再把响应通过 Channel写出。
工作流程如下所示：
ProcessorProcessor 用来实现 HTTP 协议，Processor 接收来自 EndPoint 的 Socket，读取字节流解析成 Tomcat Request 和 Response 对象，并通过 Adapter 将其提交到容器处理，Processor 是对应用层协议的抽象。
从图中我们看到，EndPoint 接收到 Socket 连接后，生成一个 SocketProcessor 任务提交到线程池去处理，SocketProcessor 的 Run 方法会调用 HttpProcessor 组件去解析应用层协议，Processor 通过解析生成 Request 对象后，会调用 Adapter 的 Service 方法，方法内部通过 以下代码将请求传递到容器中。
// Calling the container connector.getService().getContainer().getPipeline().getFirst().invoke(request, response); Adapter 组件由于协议的不同，Tomcat 定义了自己的 Request 类来存放请求信息，这里其实体现了面向对象的思维。但是这个 Request 不是标准的 ServletRequest ，所以不能直接使用 Tomcat 定义 Request 作为参数直接容器。
Tomcat 设计者的解决方案是引入 CoyoteAdapter，这是适配器模式的经典运用，连接器调用 CoyoteAdapter 的 Sevice 方法，传入的是 Tomcat Request 对象，CoyoteAdapter负责将 Tomcat Request 转成 ServletRequest，再调用容器的 Service方法。
容器连接器负责外部交流，容器负责内部处理。具体来说就是，连接器处理 Socket 通信和应用层协议的解析，得到 Servlet请求；而容器则负责处理 Servlet请求。
容器：顾名思义就是拿来装东西的， 所以 Tomcat 容器就是拿来装载 Servlet。
Tomcat 设计了 4 种容器，分别是 Engine、Host、Context和 Wrapper。Server 代表 Tomcat 实例。
要注意的是这 4 种容器不是平行关系，属于父子关系，如下图所示：
