Tomcat

The Apache Tomcat software is an open source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies.

Tomcat是目前比较流行的Web 应用服务器,它一个开源的Servlet容器，技术先进而且性能稳定，通常是我们进行Java Web应用开发、调试的首选。

在了解Tomcat之前，我们可能得先看看Tomcat与Apache之间的关系。
Tomcat是Apache基金会（Apache Software Foundation）下的项目这点大家可能都知道，但是这里说的Apache不是指Apache基金会，而是当前最流行的Web服务器之一的Apache HTTP Server（简称Apache，在很多书上会写作Apache httpd）。

httpd是超文本传输协议(HTTP)服务器的主程序，一般上认定apache和httpd是相同的，apache2后正式改名为了httpd

Tomcat和Apache都提供了Http服务，都属于Apache基金会并且都是开源项目。但是与Tomcat不同的是，Apache是一个静态文件服务器，也就是说Apache并不支持Jsp等动态内容。

实际上Tomcat部分是Apache服务器的扩展，但它是独立运行的，所以当你运行Tomcat 时，它实际上是作为一个与Apache 相互独立的进程单独运行的。

Apache Tomcat并不等于Apache + Tomcat，Apache服务器需要编译源码安装（或者使用第三方网站提供的二进制版进行安装），这一点我们需要明确。
很多情况下我们会将Apache与Tomcat搭配使用，常用做法是用Apache进行转发，Apache处理HTML页面，而Tomcat处理JSP页面和Servlet，毕竟Apache处理静态页面的速度是Tomcat所不能比拟的。

这里指的是大部分情况下，在某种特殊程度上，Tomcat的Web服务器可能会反而比Apache httpd 要稍微快一些。《Tomcat权威指南》一书中给出的示例数据是Tomcat提供静态内容服务的速度至少要比独立的Apache httpd要快23%

Tomcat 的结构很复杂，但是它同时是组件化（模块化）的，它的整体结构十分的清晰明了。
    我们先来看下Tomcat的总体结构图：

我们可以看出，Tomcat的核心在于连接器Connector和核心容器Container。

1、Connector
Connector的作用是负责监听端口接收客户端的发过来的连接请求，创建Request和Response对象用于和客户端交换数据，接着产生一个线程来处理这个请求，并把Request和 Response对象传给Container组件处理。
Tomcat有两个典型的Connector，一个直接侦听来自浏览器的http请求，一个侦听来自其它Web Server的请求

1、Coyote Http/1.1 Connector在端口8080处侦听来自客户browser的http请求
2、Coyote JK2 Connector在端口8009处侦听来自其它Web Server(Apache)的servlet/jsp代理请求

Connector最重要的功能就是接收连接请求然后分配线程让Container来处理这个请求，所以Connector必然是多线程的。
    我们可以看下Connector是怎么处理请求的：

当然，这是一个简易的时序图，实际上Connector的所进行的工作要复杂很多；Tomcat将Connector处理请求的过程进行了细化，划分成了Connector、Processor、Protocol。

2、Container
Container用于处理Servlet，并填充response。Tomcat一共有4种类型的容器：Engine，Host，Context和Wrapper，它们都继承自Container接口。

Engine代表完整的Servlet引擎，由多个Host组成，用于接收和处理来自Connector的请求
Host代表一个虚拟主机，可以运行多个应用，它负责安装和展开这些应用，其子容器为Context
Context代表一个Web Application，一个Web Application由一个或者多个Servlet组成，理论上只要有Context就可以运行Servlet了，其子容器为Wrapper
Wrapper代表一个Servlet，是最底部的容器。它负责管理一个Servlet，包含Servlet的装载、初始化、执行和卸载等。只有Wrapper也是可以运行Servlet的

Tomcat是一个基于组件的服务器，Connector和Container作为两个独立的组件，由Service进行连接。事实上，Service只是对Connector和Container进行了包装，将它们组装在一起对外提供服务，一个Service可以设置多个Connector，但是只能有一个Container容器。

Tomcat的构建组件都是可配置的，其各个组件在$CATALINA_HOME/conf/server.xml文件中配置
    我们可以看下经过简化后的server.xml文件：

Server我们可以看下官方的描述：
A Server element represents the entire Catalina servlet Container. (Singleton)

Server本身不是一个容器，但是可以代表Catalina这整个容器本身，该元素只有一个。

1、Catalina是一座小岛的名字，曾被评为全美最漂亮的小岛。Tomcat服务器使用的Servlet容器的名字就叫Catalina
2、脚本Catalina用于启动和关闭tomcat服务器，是最关键的脚本

这是Catalina脚本的片段，想要看懂这个脚本可能还需要些Shell Script方面的知识，该脚本在$CATALINA_HOME/bin目录下

Server是一个提供完整JVM的独立组件，我们可以指定一个端口来负责监听关闭Tomcat的请求，并且定义关闭Tomcat的命令字符串。

Server.xml给出的默认配置是port=”8005”、shutdown=”SHUTDOWN”，那么对于一个处于运行状态tomcat服务器，可以在cmd下使用telnet ip 8005命令进行连接，然后输入“SHUTDOWN” 命令就可以关闭服务器

Server下可以包含多个Service，Service之前我们已经有过介绍，它可以包含一个Container和多个Connector。Tomcat默认定义了一个叫“Catalina”的Service，配置了2个Connector：HTTP 和 AJP

protocol定义了该Connector所处理的请求

protocol=”HTTP/1.1”指定了处理 HTTP 请求，使得 Tomcat 成为了一个 HTTP 服务器
protocol=”AJP/1.3”指定了处理Tomcat 服务器与 Apache HTTP 服务器之间的交互（Apache JServ Protocol connector）

看到这里可能会觉得奇怪，重定向配置redirectPort指定的端口为何是8443？
实际上，8443是Tomcat打开SSL的文本服务的默认端口。默认的https端口号是443,因此Tomcat为了进行区分就使用了8443这个端口。
让Tomcat支持SSL的Connector默认是注释的，去掉注释并且按需修改即可使用。需要注意的是，如果你更改了SSL端口8443为其他端口，那么你必须同时修改其他非SSL的redirectPort,因为非SSL连接会重定向那些需要SSL安全约束的用户请求到你所修改的那个端口

除了Connector，Service还包含一个Container：Engine。之前我们说到，Engine由一个或多个Host组成，而在Tomcat给出的默认配置中，Engine就包含了一个名为“localhost”的Host，同时指定默认Host即为“localhost”。
Host是一个虚拟主机，它负责安装和展开这些应用

unpackWARs=”true”解压缩war包就不多说了，我们来看下自动部署autoDeploy=”true”。如果将autoDeploy=”true”与Context中的自动加载reloadable=”true”搭配使用，就可以实现我们常说的“热部署”了

Tomcat的容器实现热部署使用了2种机制：
1、Classloader重写，通过自定义classloader加载相应的jsp编译后的class到JVM中
2、通过动态修改内存中的字节码，将修改过的class再次装载到JVM中

既然说Tomcat是组件化的，那自然是可以自由的添加或修改插件的。实际上，Server中不仅仅是Service，往往还会包含一些监听器（Listener）和配置系统JNDI(数据库链接等各种资源)的GlobalNamingResources。
Tomcat默认的GlobalNamingResources配置中就引用了”conf/tomcat-users.xml”文件。

了解了这些组件之后，我们再来看Tomcat Server的结构图就显得容易理解了：

刚才我们说到Context代表一个Web Application，它运行在特定的虚拟机Host中。实际上，每个Web应用要么是一个war文件，要么是一个符合规范的目录。
一般Tomcat会从Http请求路径中带有的requestURI中获取上下文路径，根据上下文路径选择适合的web应用程序来处理这个请求。Context是允许定义多个的，也就是说一个Host下可以有多个Context，但是Context的名字必须是唯一的。

实际上，我们并不推荐直接在server.xml文件中直接添加Context，因为修改server.xml文件必须重新启动Tomcat才会生效。当然这也不意味着在server.xml中添加Context就一无是处,在server.xml文件中进行定义也是有其优势的，就是可以定义多个context元素，这在其他的情况下难以实现的。

一般情况下Context会出现在三个地方：
1、server.xml文件的Host元素下面
2、web应用的/META-INF/context.xml中，此时如果copyXML属性为true,会将其被拷贝到 $CATALINA_BASE/conf/[enginename]/[hostname]/ 目录中，并命名为应用名
3、$CATALINA_BASE/conf/[enginename]/[hostname]/ 目录下，该文件将总是优先于/META-INF/context.xml部署

Host调用host.addChild()方法将context挂在host名下作为它的子容器，至于其具体的过渡过程我们就不多说了。我们要知道的是，在context启动完后，会随即启动它的附属组件：loader、logger、pipeline、sessionManager等；这里我们要注意的是sessionManager，顾名思义，这是一个session的管理器。

Session代表服务器与浏览器的一次会话过程，在web开发中是一个非常重要的概念。我们知道Session是在Server端程序显式调用HttpSessionRequest.getSession(true)语句是才创建的，在我们的JSP中，如果没有在页头显式声明<%@page session=”false” %>关闭session，那么在编译成Servlet时将会自动加上HttpSession session = HttpSessionRequest.getSession(true)这样一条语句，这也就是JSP中隐含对象Session的来历。

Tomcat提供了一种优化策略：Session钝化机制。Session的主要数据被存储在服务器内存中，而服务器会为每个在线用户创建一个Session对象，当在线用户很多时，例如同时有几万或是几十万在线的情况下，Session内存的开销将会十分巨大，会影响Web服务器性能，Session钝化机制的作用就在于处理这样的问题。

Session钝化机制不属于Java EE的范畴，在tomcat中，Session钝化机制就是由sessionManager进行管理的。Session钝化的本质就是把服务器不经常使用的session对象暂时序列化到系统文件中，整个的过程是由服务器自动完成的。

Tomcat提供了2种sessionManager的实现:
1、StandardManager（缺省）
2、PersistentManager

当Tomcat服务器被关闭或重启时，tomcat服务器会将当前内存中的Session对象钝化到服务器文件系统中；另一种情况是Web应用程序被重新加载时，内存中的Session对象也会被钝化到服务器的文件系统中。

Tomcat默认是已经启用了全局的Session钝化机制的，持久化文件存储在”$CATALINA_HOME/work/Catalina/host_name/webappname/”目录下。若要禁用持久化功能，则只需要在节点里配置即可

Manager元素常用配置
maxActiveSessions：可处于活动状态的session数，default -1 不限制
checkInterval：检查session是否过期的时间间隔，default 60s
saveOnRestart：服务器关闭时，是否将所有的session保存到文件中；
minIdleSwap/maxIdleSwap：session处于不活动状态最短/长时间(s)，sesson对象转移到File Store中；(－1表示没有限制)
maxIdleBackup：超过这一时间，将session备份。(－1表示没有限制)
directory：文件存储位置work\Catalina\host name\web app\session\文件名.session*