一.故事背景

二.Tomcat概述

1、Tomcat介绍

2、Tomcat历史

二、Tomcat原理分析

1、Http工作原理

2、Tomcat整体架构

3、Coyote连接器架构

4、Catalina容器架构

5、Jasper处理流程

6、JSP编译过程

7、Tomcat启动流程

8、Tomcat请求处理流程

三、Tomcat安装与配置

扩充知识：类与对象

四、Tomcat配置文件详解

1.配置文件目录

2.server.xml 详解

Server

Listener

Service

Connector

executor

Engine

Host

Context

3.web.xml

欢迎页面配置

4.context.xml

5.tomcat-users.xml

6.拓展，查看server status

五、Tomcat高可用项目

1、项目概述

2、设计构架图

3、实施流程

4.动静分离

5.如何解决session共享问题

六.总结

一.故事背景

在学习完nginx后，本节课将会带领了解tomcat的相关介绍，作为之后学习数据库的过渡内容，接下来将讲解tomcat。

二.Tomcat概述

1、Tomcat介绍

Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持，最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，Tomcat 5支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web 应用服务器。

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。实际上Tomcat是Apache 服务器的扩展，但运行时它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。

2、Tomcat历史

Tomcat 最初由Sun公司的软件架构师 James Duncan Davidson 开发，名称为“JavaWebServer”。
1999年，在 Davidson 的帮助下，该项目于1999年于apache软件基金会旗下的JServ项目合并，并发布第一个版本（3.x），即是现在的Tomcat，该版本实现了Servlet2.2和JSP 1.1规范。
2001年，Tomcat 发布了4.0版本，作为里程碑式的版本，Tomcat 完全重新设计了其架构，并实现了Servlet 2.3和JSP 1.2规范。
目前 Tomcat 已经更新到 10.0.x版本，但是目前企业中的Tomcat服务器，主流版本还是7.x 和 8.x，所以本课程是基于 8.5 版本进行讲解。

二、Tomcat原理分析

1、Http工作原理

HTTP协议（超文本传输协议）是浏览器与服务器之间的数据传送协议。作为应用层协议，HTTP是基于TCP/IP协议来传递数据的（HTML文件、图片、查询结果等），HTTP协议不涉及数据包（Packet）传输，主要规定了客户端和服务器之间的通信格式。它的整个过程如下图所示：

用户通过浏览器进行了一个操作，比如输入网址并回车，或者是点击链接，接着浏览器获取了这个事件。
浏览器向服务端发出TCP连接请求。
服务程序接受浏览器的连接请求并经过TCP三次握手建立连接。
浏览器将请求数据打包成一个HTTP协议格式的数据包。
浏览器将该数据包推入网络，数据包经过网络传输，最终达到端服务程序。
服务端程序拿到这个数据包后，同样以HTTP协议格式解包，获取到客户端的意图。
得知客户端意图后进行处理，比如提供静态文件或者调用服务端程序获得动态结果。
服务器将响应结果（可能是HTML或者图片等）按照HTTP协议格式打包。
服务器将响应数据包推入网络，数据包经过网络传输最终达到到浏览器。
浏览器拿到数据包后，以HTTP协议的格式解包，然后解析数据，假设这里的数据是 HTML。
浏览器将HTML文件展示在页面上。

2、Tomcat整体架构

Tomcat要实现两个核心功能：

处理Socket连接，负责网络字节流与Request和Response对象的转化。
加载和管理Servlet，以及具体处理Request请求。

因此Tomcat设计了两个核心组件连接器（Connector）和容器（Container）来分别做这两件事情。连接器负责对外交流，容器负责内部处理。

3、Coyote连接器架构

Coyote是Tomcat的连接器框架的名称 , 是Tomcat服务器提供的供客户端访问的外部接口。客户端通过Coyote与服务器建立连接、发送请求并接受响应。

Coyote封装了底层的网络通信（Socket请求及响应处理），为Catalina容器提供了统一的接口，使Catalina容器与具体的请求协议及IO操作方式完全解耦。Coyote 将Socket输入转换封装为Request对象，交由Catalina容器进行处理，处理请求完成后，Catalina通过Coyote提供的Response对象将结果写入输出流。

Coyote作为独立的模块，只负责具体协议和IO的相关操作，与Servlet规范实现没有直接关系，因此即便是Request和Response对象也并未实现Servlet规范对应的接口，而是在Catalina中将他们进一步封装为ServletRequest和ServletResponse。

在Coyote中，Tomcat支持的IO模型

IO模型	描述
NIO	非阻塞I/O，采用Java NIO类库实现。
NIO2	异步I/O，采用JDK 7最新的NIO2类库实现。
APR	采用Apache可移植运行库实现，是C/C++编写的本地库。如果选择该方案，需要单独安装APR库。

在Coyote中，Tomcat支持的应用层协议

应用层协议	描述
HTTP/1.1	这是大部分Web应用采用的访问协议。
AJP/1.3	用于和Web服务器集成（如Apache），以实现对静态资源的优化以及集群部署。
HTTP/2	HTTP 2.0大幅度的提升了Web性能。下一代HTTP协议，自8.5以及9.0版本之后支持。

协议分层

在8.0之前，Tomcat 默认采用的I/O方式为 BIO，之后改为 NIO。无论 NIO、NIO2还是 APR，在性能方面均优于以往的BIO。如果采用APR，甚至可以达到 Apache HTTP Server的影响性能。

Tomcat为了实现支持多种I/O模型和应用层协议，一个容器可能对接多个连接器，就好比一个房间有多个门。但是单独的连接器或者容器都不能对外提供服务，需要把它们组装起来才能工作，组装后这个整体叫作Service组件。这里请你注意，Service本身没有做什么重要的事情，只是在连接器和容器外面多包了一层，把它们组装在一起。Tomcat内可能有多个Service，这样的设计也是出于灵活性的考虑。通过在Tomcat中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。

Coyote的主要组件结构：

Coyote的各个组件的作用：

EndPoint：Coyote 通信端点，即通信监听的接口，是具体Socket接收和发送处理器，是对传输层的抽象，因此EndPoint用来实现TCP/IP协议的。Tomcat 并没有EndPoint接口，而是提供了一个抽象类AbstractEndpoint，里面定义了两个内部类：Acceptor和SocketProcessor。Acceptor用于监听Socket连接请求。SocketProcessor用于处理接收到的Socket请求，它实现Runnable接口，在Run方法里调用协议处理组件Processor进行处理。为了提高处理力，SocketProcessor被提交到线程池来执行，而这个线程池叫作执行器（Executor）。
Processor：Coyote 协议处理接口，如果说EndPoint是用来实现TCP/IP协议的，那么Processor用来实现HTTP协议，Processor接收来自EndPoint的Socket，读取字节流解析成Tomcat Request和Response对象，并通过Adapter将其提交到容器处理，Processor是对应用层协议的抽象。
ProtocolHandler：Coyote 协议接口，通过Endpoint和Processor，实现针对具体协议的处理能力。Tomcat按照协议和I/O 提供了6个实现类： AjpNioProtocol、AjpNio2Protocol、AjpAprProtocol、Http11NioProtocol、Http11Nio2Protocol、Http11AprProtocol。我们在配置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方法。

4、Catalina容器架构

Tomcat的模块分层结构

Tomcat本质上就是一款 Servlet 容器，因此Catalina 才是 Tomcat 的核心，其他模块都是为Catalina提供支撑的。比如：通过Coyote模块提供连接通信，Jasper 模块提供JSP引擎，Naming 提供JNDI 服务，Juli提供日志服务。

Catalina的主要组件结构

Catalina的各个组件的作用

Catalina

负责解析Tomcat的配置文件 , 以此来创建服务器Server组件，并根据命令来对其进行管理。

Server

服务器表示整个Catalina Servlet容器以及其它组件，负责组装并启动Servlet引擎、Tomcat连接器。Server通过实现Lifecycle接口，提供了一种优雅的启动和关闭整个系统的方式。

Service

服务是Server内部的组件，一个Server包含多个Service。它将若干个Connector组件绑定到一个Container（Engine）上。

Connector

连接器主要是处理与客户端的通信，它负责接收客户请求，然后转给相关的容器处理，最后向客户返回响应结果。

Container

容器负责处理用户的Servlet请求，并返回对象给web用户的模块。

Container的主要组件结构

Tomcat设计了4种容器，分别是Engine、Host、Context和Wrapper。这4种容器不是平行关系，而是父子关系。Tomcat通过一种分层的架构，使得Servlet容器具有很好的灵活性。

Container的各个组件的作用：

Engine

表示整个Catalina的Servlet引擎，用来管理多个虚拟站点，一个Service最多只能有一个Engine，但是一个引擎可包含多个Host。

Host

代表一个虚拟主机或者说一个站点，可以给Tomcat配置多个虚拟主机地址，而一个虚拟主机下可包含多个Context。

Context

表示一个Web应用程序，一个Web应用可包含多个Wrapper。

Wrapper

表示一个Servlet，Wrapper 作为容器中的最底层，不能包含子容器。

我们也可以再通过Tomcat的server.xml配置文件来加深对Tomcat容器的理解。Tomcat采用了组件化的设计，它的构成组件都是可配置的，其中最外层的是Server，其他组件按照一定的格式要求配置在这个顶层容器中。

<Server>          <!-- 顶级元素，代表整个Tomcat实例 --><Service>     <!-- 服务组件，关联连接器和引擎 --><Connector/> <!-- 接收外部请求的连接器（HTTP/HTTPS/AJP） --><Engine>   <!-- 请求处理引擎，包含多个虚拟主机 --><Realm/> <!-- 安全认证域 --><Host>  <!-- 虚拟主机配置 --><Context/> <!-- Web应用配置（通常不推荐直接在此配置） --><Valve/>   <!-- 拦截器，用于日志、IP过滤等 --></Host></Engine></service>
</Server>

那么，Tomcat是怎么管理这些容器的呢？你会发现这些容器具有父子关系，形成一个树形结构，你可能马上就想到了设计模式中的组合模式。没错，Tomcat就是用组合模式来管理这些容器的。具体实现方法是，所有容器组件都实现了Container接口，因此组合模式可以使得用户对单容器对象和组合容器对象的使用具有一致性。这里单容器对象指的是最底层的Wrapper，组合容器对象指的是上面的Context、Host或者Engine。

5、Jasper处理流程

Tomcat在默认的web.xml中配置了一个org.apache.jasper.servlet.JspServlet，用于处理所有的.jsp或 .jspx结尾的请求，该Servlet 实现即是运行时编译的入口。

<servlet><servlet-name>jsp</servlet-name><servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class><init-param><param-name>fork</param-name><param-value>false</param-value></init-param><init-param><param-name>xpoweredBy</param-name><param-value>false</param-value></init-param><load-on-startup>3</load-on-startup>
</servlet>
<servlet-mapping><servlet-name>jsp</servlet-name><url-pattern>*.jsp</url-pattern><url-pattern>*.jspx</url-pattern>
</servlet-mapping>

JspServlet 处理流程图

如果在 tomcat/conf/web.xml 中配置了参数scratchdir，则jsp编译后的结果，就会存储在该目录下 .如果没有配置该选项，则会将编译后的结果，存储在Tomcat安装目录下的 work/Catalina(Engine名称)/localhost(Host名称)/Context名称。

除了运行时编译，我们还可以直接在Web应用启动时，一次性将Web应用中的所有的JSP页面一次性编译完成。在这种情况下，Web应用运行过程中，便可以不必再进行实时编译，而是直接调用JSP页面对应的Servlet完成请求处理，从而提升系统性能。

Tomcat 提供了一个Shell程序JspC，用于支持JSP预编译，而且在Tomcat的安装目录下提供了一个 catalina-tasks.xml 文件声明了Tomcat 支持的Ant任务，因此，我们很容易使用 Ant 来执行JSP 预编译。（要想使用这种方式，必须得确保在此之前已经下载并安装了Apache Ant）。

6、JSP编译过程

Compiler 编译工作主要包含代码生成和编译两部分：

代码生成

Compiler 通过一个 PageInfo 对象保存JSP 页面编译过程中的各种配置，这些配置可能来源于 Web 应用初始化参数，也可能来源于JSP页面的指令配置（如 page ， include）。
调用ParserController 解析指令节点，验证其是否合法，同时将配置信息保存到 PageInfo 中，用于控制代码生成。
调用ParserController 解析整个页面，由于 JSP 是逐行解析，所以对于每一行会创建一个具体的Node 对象。如静态文本（TemplateText）、Java代码（Scriptlet）、定制标签（CustomTag）、Include指令（IncludeDirective）。
验证除指令外其他所有节点的合法性，如脚本、定制标签、EL表达式等。
收集除指令外其他节点的页面配置信息。
编译并加载当前 JSP 页面依赖的标签。
对于JSP页面的EL表达式，生成对应的映射函数。
生成JSP页面对应的Servlet类源代码编译代码生成完成后，Compiler还会生成 SMAP信息。如果配置生成 SMAP信息，Compiler则会在编译阶段将SMAP信息写到class文件中。

编译阶段

Compiler的两个实现 AntCompiler 和 JDTCompiler 分别调用先关框架的 API 进行源代码编译。
对于 AntCompiler 来说，构造一个 Ant 的javac 的任务完成编译。
对于 JDTCompiler 来说，调用 org.eclipse.jdt.internal.compiler.Compiler 完成编译。

7、Tomcat启动流程

8、Tomcat请求处理流程

三、Tomcat安装与配置

版本号以及适配的java版本：

解压安装tomcat

安装Java

启动tomcat和关闭tomcat

8080口用于接收http请求，8009用于接收ajp协议请求，8005是tomcat用于停止的端口

扩充知识：类与对象

类：是抽象的概念集合，表示的是一个共性的产物，类之中定义的是属性和行为（方法）；
对象：对象是一种个性的表示，表示一个独立的个体，每个对象拥有自己独立的属性，依靠属性来区分不同对象。

可以写一个简单的脚本来启动或关闭tomcat

四、Tomcat配置文件详解

1.配置文件目录

conf配置文件目录

名称	作用
Catalina	监听8080号端口的应用
catalina.properties catalina.policy	catalina的通用配置
jaspic-providers.xml	jaspic的配置文件
logging.properties	登录配置
server.xml	服务的配置文件
context.xml	安全上下文配置
tomcat-users.xml	tomcat的用户配置
web.xml	web页面的访问配置

2.server.xml 详解

Server

Server是server.xml的根元素，用于创建一个Server实例，默认使用的实现类是 org.apache.catalina.core.StandardServer。

port:关闭Tomcat的监听端口(发送SHUTDOWN命令)

shutdown:关闭指令的密码(自定义字符串）

Listener

<!‐‐ 用于以日志形式输出服务器、操作系统、JVM的版本信息 ‐‐>
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />

<!‐‐ 用于加载（服务器启动）和销毁（服务器停止） APR。如果找不到APR库，则会输出日志，并不影响Tomcat启动 ‐‐>
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

<!‐‐ 用于避免JRE内存泄漏问题 ‐‐>
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

<!‐‐ 用户加载（服务器启动）和销毁（服务器停止）全局命名服务 ‐‐>
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />

<!‐‐ 用于在Context停止时重建Executor 池中的线程，以避免ThreadLocal 相关的内存泄漏 ‐‐>
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

Service

该元素用于创建 Service 实例，默认使用 org.apache.catalina.core.StandardService。默认情况下，Tomcat 仅指定了Service 的名称，值为 “Catalina”。Service 可以内嵌的元素为： Listener、Executor、Connector、Engine，其中： Listener 用于为Service添加生命周期监听器， Executor 用于配置Service 共享线程池，Connector 用于配置Service 包含的链接器， Engine 用于配置Service中链接器对应的Servlet 容器引擎。一个Server服务器，可以包含多个Service服务。

name :引擎名称(默认Catalina)

namePrefix：所创建的每个线程的名称前缀，一个单独的线程名称为namePrefix+threadNumber。

minSpareThreads：活跃线程数，也就是核心池线程数，这些线程不会被销毁，会一直存在。

maxIdleTime：线程空闲时间，超过该时间后，空闲线程会被销毁，默认值为6000（1分钟），单位毫秒。

maxQueueSize：在被执行前最大线程排队数目，默认为Int的最大值，也就是广义的无限。除非特殊情况，这个值不需要更改，否则会有请求不会被处理的情况发生。

prestartminSpareThreads：启动线程池时是否启动 minSpareThreads部分线程。默认值为false，即不启动。

threadPriority：线程池中线程优先级，默认值为5，值从1到10。

className：线程池实现类，未指定情况下，默认实现类为 org.apache.catalina.core.StandardThreadExecutor。如果想使用自定义线程池首先需要实现 org.apache.catalina.Executor接口。

maxThreads:最大线程数(默认200)

Connector

Connector 用于创建链接器实例。默认情况下，server.xml 配置了两个链接器，一个支持HTTP协议，一个支持AJP协议。因此大多数情况下，我们并不需要新增链接器配置，只是根据需要对已有链接器进行优化。

protocol:协议类型(HTTP/1.1或自动适配org.apache.coyote.http11.Http11NioProtocol)

connectionTimeout：连接超时时间（毫秒ms）

redirectPort:HTTP请求强制跳转HTTPS的端口

executor

指定共享线程池的名称，也可以通过maxThreads、minSpareThreads 等属性配置内部线程池。

URIEncoding：用于指定编码URI的字符编码， Tomcat8.x版本默认的编码为UTF-8 , Tomcat7.x版本默认为ISO-8859-1。

acceptCount：接收的连接数。

maxConnections：接收的最大连接数。

compression:启用响应压缩。

compressionMinSize：压缩的大小。

disableUploadTimeout：禁用上传超时。

Engine

Engine 作为Servlet 引擎的顶级元素，内部可以嵌入： Cluster、Listener、Realm、 Valve和Host。

defaultHost:默认虚拟主机名(如localhost)

acceptCount:等待队列长度(当线程用完时)

<Realm>:安全认证域(用户权限)

Host

Host 元素用于配置一个虚拟主机，它支持以下嵌入元素：Alias、Cluster、Listener、Valve、Realm、Context。

如果在Engine下配置Realm，那么此配置将在当前Engine下的所有Host中共享。同样，如果在Host中配置Realm ，则在当前Host下的所有Context中共享。

Context中的Realm优先级 > Host 的Realm优先级 > Engine中的Realm优先级。

name:主机域名(如www.example.com)

appBase:Web应用存放目录(如webapps)

unpackWARs:是否解压WAR包(默认true)

autoDeploy:是否自动部署新应用(生产环境建议false)

Context

Context 用于配置一个Web应用

docBase：Web应用目录或者War包的部署路径。可以是绝对路径，也可以是相对于Host appBase的相对路径。

path：Web应用的Context 路径。

pattern:日志格式(如%{yyyy-MM-dd HH:mm:ss}t %r %s %Dms 记录响应时间)

ROOT/中有默认访问页面（8080端口）的配置

打开tomcat后，访问8080端口可得到页面

3.web.xml

web.xml 是web应用的描述文件，它支持的元素及属性来自于Servlet 规范定义。在Tomcat 中， Web 应用的描述信息包括 tomcat/conf/web.xml 中默认配置以及 Web应用 WEB-INF/web.xml 下的定制配置。

param‐name：初始化参数名称。

param‐value：初始化参数的值。

description：这个参数的描述信息。

servlet-name：你想要让哪个servlet处理，这里就写哪个servlet名称。
url-pattern：用于指定URL表达式，一个 servlet‐mapping可以同时配置多个 url‐ pattern。

filter：

filter-name：用于指定过滤器名称，在web.xml中，过滤器名称必须唯一。
filter-class：过滤器的全限定类名，该类必须实现Filter接口。
async-supported：该过滤器是否支持异步。
init-param：用于配置Filter的初始化参数，可以配置多个，可以通过FilterConfig.getInitParameter获取。
- param-name：初始化参数名称。
- param-value：初始化参数的值。