终于有人把tomcat讲清楚了，堪称史上最细致讲解！！
1.1. 第一篇：Tomcat架构介绍
1.1.1. Http工作流程
HTTP协议是浏览器与服务器之间的数据传送协议。作为应用层协议, HTTP是基于TCP/IP协议来传递数据的( HTMI文件、图片、查询结果等) , HTTP协议不涉及数据包( Packet )传输,主要规定了客户端和服务器之间的通信格式。
1.1.1. Http服务器请求处理
浏览器发给服务端的是一个HTTP格式的请求 , HTTP服务器收到这个请求后,需要调用服务端程序来处理,所谓的服务端程序就是你写的Java类,一般来说不同的请求需要由不同的Java类来处理。
Tomcat架构设计
HTT服务器不直接调用业务类,而是把请求交给容器来处理,容器通过servlet接口调用业务类。因此servlet接口和Servlet容器的出现,达到了HTTP服务器与业务类解耦的目的。而servlet接口和servlet容器这一 整套规范叫作servlet规范。
Tomcat按照serv1et规范的要求实现了servlet容器,同时它们也具有HTTP服务器的功能。作为Java程序员 ,如果我们要实现新的业务功能,只需要实现一个servlet ,并把它注册到romcat ( servlet容器)中,剩下的事情就由Tomcat帮我们处理了。
1.1.3 Tomcat核心功能
tomcat核心功能
处理socket连接 ,负责网络字节流与Request和Response对象的转化。
加载和管理servlet ,以及具体处理Request请求。
因此Tomcat设计了两个核心组件连接器( Connector )和容器( Container )来分别做这两件事情。连接器负责对外交流,容器负责内部处理。
Tomcat服务器支持的IO模型及其协议。
Tomcat8.0版本支持的I0模型(自8.5/9.0版本起，Tomcat移除了对BIO的支持) :
BIO 阻塞I/O
NIO 非阻塞I/O,采用Java NIO类库实现。
NIO2 异步I/O,采用JDK 7最新的NIO2类库实现。
APR采用Apache可移植运行库实现，是C/C++编写的本地库。如果选择该方案,需要单独安装APR库。
Tomcat支持的应用层协议:
HTTR/1.1 这是大部分web应用采用的访问协议。
AJP 用于和web服务器集成(如Apache)， 以实现对静态资源的优化以及集群部署，当前支持AJP/1.3。
HTTP/2 HTTP 2.0大幅度的提升了web性能。下一代HTTP协议，自8 .5以及9.0版本之后支持。
1.1.4. 连接器的组件
连接器组件介绍及其作用。
EndPoint组件
-
EndPoint :通信端点,即通信监听的接口,是具体socket接收和发送处理器,是对传输层的抽象,因此EndPoint用来实现TCP/ IP协议的。
-
Tomcat并没有EndPoint接口,而是提供了一 个抽象类AbstractEndpoint ，里面定义了两个内部类: Acceptor和socketprocessor. Acceptor用于监听socket连接请求。socketprocessor用于处理接收到的socket请求 ,它实现Runnable接口，在Run方法里调用协议处理组件processor进行处理。为了提高处理能力, socketprocessor被提交到线程池来执行。而这个线程池叫作执行器Executor
Processor组件
Processor :协议处理接口, 如果说EndPoint是用来实现TCP/IP协议的,那么Brocessor用来实现HTTP协议，Processor接收来自EndPoint的socket ,读取字节流解析成Tomcat Request和Response对象 ,并通过Adapter将其提交到容器处理，Processor是对应用层协议的抽象。
ProtocolHandler组件
ProtocolHandler :协议接口，通过Endpoint 和Processor ，实现针对具体协议的处理能力。 Tomcat按照协议和I/O提供了6个实现类: AjpNioprotocol ，AjpAprProtocol、AjpNio2Protocol、Http11NioProtocol、HttpllNio2Protocol、Httpl1AprProtocol.我们在配置tomcat/conf/server .xml时，至少要指定具体的
ProtocolHandler，当然也可以指定协议名称，如: HTTP/1.1 , 如果安装了APR,那么将使用Http11AprProtocol，否则使用Http11NioProtocol。
Adapter组件
由于协议不同,客户端发过来的请求信息也不尽相同, Tomcat定义了自己的Request类来“存放”这些请求信息。ProtocolHandler接口负责解析请求并生成Tomcat Request类。 但是这个Request对象不是标准的servletRequest ,也就意味着,不能用Tomcat Request作为参数来调用容器。Tomcat设计者的解决方案是引入coyoteAdapter ,这是适配器模式的经典运用,连接器调用coyoteAdapter的Sevice方法,传入的是Tomcat Request对象, CoyoteAdapter负责将Tomcat Request转成servletRequest ,再调用容器的Service方法。
1.1.5. Catalina介绍
Catalina组件结构如下
Catalina：负责解析tomcat的配置文件，以此来创建服务器server组件,并根据命令来对其进行管理。
Server：服务器表示整个Catalina Servlet容器以及其它组件,负责组装并启动servlet引擎, Tomcat连接器。server通过实现Lifecycle接口,提供了一种优雅的启动和关闭整个系统的方式
Service：服务是server内部的组件, 一server包含多个service.它将若干个Connector组件绑定到一个Container ( Engine)上。
Connector：连接器,处理与客户端的通信,它负责接收客户请求,然后转给相关的容器处理，最后向客户返回响应结果。
Container：容器,负责处理用户的servlet请求,并返回对象给web用户的模块。
1.1.6. Container容器结构
Tomcat设计了4种容器,分别是Engine. Host. Context和wrapper. 这4种容器不是平行关系,而是父子关系。，Tomcat通过一种分层的架构,使得serv1et容器具有很好的灵活性。
各个组件的含义：
Engine：表示整个Catalina的servlet引擎,用来管理多个虚拟站点, 一个service最多只能有一个Engine ,但是一个引擎可包含多个Host。
Host：代表一个虚拟主机，或者说一个站点,可以给Tomcat配置多个虚拟主机地址，而一个虚拟主机下可包含多个Context。
Context：表示一个web应用程序， 一个Web应用可包含多个Wrapper。
Wrapper：表示一个servlet , Wrapper作为容器中的最底层，不能包含子容器。
那么，Tomcat是怎么管理这些容器的呢?你会发现这些容器具有父子关系,形成一个树形结构 ,你可能马上就想到了设计模式中的组合模式。没错, Tomcat就是用组合模式来管理这些容器的。具体实现方法是,所有容器组件都实现了container接口.因此组合模式可以使得用户对单容器对象和组合容器对象的使用具有一致性。 这里单容器对象指的是最底层的wrapper ,组合容器对象指的是上面的Context、Host或者Engine。