架构
首先，看一下整个架构图。最全面的 Java 面试网站
接下来简略解释一下。
Server：服务器。Tomcat 就是一个 Server 服务器。
Service：在服务器中能够有多个 Service，只不过在咱们罕用的这套 Catalina 容器的 Tomcat 中只蕴含一个 Service，在 Service 中蕴含连接器和容器。一个残缺的 Service 能力实现对申请的接管和解决。
连接器：Coyote 是连接器具体的实现。用于与新来的申请建设连贯并解析数据。因为 Tomcat 反对的 IO 模型有 NIO、NIO2、APR，而反对的应用层协定有 HTTP1.1、HTTP2、AJP。所以针对不同的 IO 模型和应用层协定申请，在一个 Service 中能够有多个连接器来实用不同的协定的 IO 申请。
EndPoint：Coyote 通信端点，即通信监听的接口，是具体 Socket 接管和发送处理器，是用来实现 TCP/IP 传输协定的。
Acceptor：用于接管申请的 socket。
Executor：线程池，在接管到申请的 socket 后会从线程池中调配一条来执行前面的操作。
Processor：Coyote 协定解决接口，是用来实现 HTTP 应用层协定的，接管 EndPoint、容器传来的 Socket 字节流，解析成 request 或 response 对象。
ProtocolHandler：Coyote 协定接口，通过 EndPoint 和 Processor，实现针对具体协定的解决能力。
Adapter：容器只负责解决数据，对于申请协定不同的数据，容器会无奈解决，所以在 ProtocolHandler 解决生成的 request 对象后，还须要将其转成 Tomcat 定义好的对立格局的 ServletRequest 对象，Adapter 就是用来进行这样的操作的。
本文曾经收录到 Github 仓库，该仓库蕴含 计算机根底、Java 根底、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招社招分享 等外围知识点，欢送 star~
Github 地址
如果拜访不了 Github，能够拜访 gitee 地址。
gitee 地址
容器：Tomcat 的外围组件，用于解决申请并返回数据。Catalina 是其具体的实现。
Engine：示意整个 Catalina 的 Servlet 引擎，用来治理多个虚构站点，一个 Service 最多只能有一个 Engine。然而一个 Engine 能够蕴含多个 Host。
Host：示意一个主机地址，或者说一个站点，一个 Host 下有能够配置多个 Context。
Context：示意一个 web 利用，一个 Web 利用能够蕴含多个 Wrapper
Wrapper：示意一个 Servlet，是容器中的最底层组件。
各组件的比例关系
各组件的实现与执行
组件实现
后面提到的各个组件名都是接口或者形象办法，在理论解决申请时执行的都是其子类或者实现类。
Server、Service、Engine、Host、Context 都是接口，下图中列举了这些接口的默认 实现类。
Adapter 的实现是 CoyoteAdapter
对于 Endpoint 组件来说，在 Tomcat 中没有对应的 Endpoint 接口，然而有一个抽象类 AbstractEndpoint，其下有三个实现类：NioEndpoint、Nio2Endpoint、AprEndpoint，这三个实现类，别离对应于后面解说链接器 Coyote 时，提到的链接器反对的三种 IO 模型：NIO，NIO2，APR，tomcat8.5 版本中，默认采纳的是 NioEndpoint。
ProtocolHandler：Coyote 协定接口，通过封装 Endpoint 和 Processor，实现针对具体协定的解决性能。Tomcat 依照协定和 IO 提供了 6 个实现类。
给大家分享一个 Github 仓库，下面有大彬整顿的 300 多本经典的计算机书籍 PDF，包含 C 语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构和算法、机器学习、编程人生 等，能够 star 一下，下次找书间接在下面搜寻，仓库继续更新中~
Github 地址
AJP 协定：
1）AjpNioProtocol：采纳 NIO 的 IO 模型。
2）AjpNio2Protocol：采纳 NIO2 的 IO 模型。
3）AjpAprProtocol：采纳 APR 的 IO 模型，须要依赖于 APR 库。
HTTP 协定：
1）Http11NioProtocol：采纳 NIO 的 IO 模型，默认应用的协定（如果服务器没有装置 APR）。
2）Http11Nio2Protocol：采纳 NIO2 的 IO 模型。
3）Http11AprProtocol：采纳 APR 的 IO 模型，须要依赖于 APR 库。
这些组件均存在初始化、启动、进行等周期办法，所以 Tomcat 设计了一个 LifeCycle 接口，用于定义这些组件生命周期中须要执行的独特办法，这些组件实现类都实现了这个接口。
启动流程
1）启动 tomcat，须要调用 bin/startup.bat (在 linux 目录下 , 须要调用 bin/startup.sh)，在
startup.bat 脚本中, 调用了 catalina.bat。
2）在 catalina.bat 脚本文件中，调用了 BootStrap 中的 main 办法。
3）在 BootStrap 的 main 办法中调用了 init 办法，来创立 Catalina 及 初始化类加载器。
4）在 BootStrap 的 main 办法中调用了 load 办法，在其中又调用了 Catalina 的 load 办法。
5）在 Catalina 的 load 办法中 , 须要进行一些初始化的工作, 并须要结构 Digester 对象, 用于解析 XML。
6）而后在调用后续组件的初始化操作。。。
加载 Tomcat 的配置文件，初始化容器组件，监听对应的端口号，筹备承受客户端申请。
简而言之就是进行各组件逐级执行 init() 和 start() 办法。
执行流程
当一个申请进入 Tomcat 时，执行状况如下(因为 Tomcat 只有一个 Service，所以上面就将 Service 和 Engine 写在同一个框中）：
定位次要通过 Mapper 组件来实现，其本质就是一个 K、V 键值对，在解析时首先会将申请网址进行解析，将其中的 Host 局部在 Mapper 类中的 hosts 属性（MappedHost 数组，保留所有的 Host 信息）中进行查找，找到后再解析 Context 局部，在该 MapperHost 中又有 contextList 属性（保留所有的 context 信息），而后再向下找，最终失去对应的 Servlet，执行。
除此之外，为了加强各组件之间的拓展性，Tomcat 中定义了 Pipeline 和 Valve 两个接口，Pipeline 用于构建责任链，后者代表责任链上的每个处理器。Pipeline 中保护了一个根底的 Valve，它始终位于 Pipeline 的末端（最初执行），封装了具体的申请解决和输入响应的过程。当然，咱们也能够调用 addValve()办法，为 Pipeline 增加其余的 Valve，后增加的 Valve 位于根底的 Valve 之前，并依照增加程序执行。Pipiline 通过取得首个 Valve 来启动整合链条的执行。
所以最终的执行如下：
步骤如下:
1）Connector 组件 Endpoint 中的 Acceptor 监听客户端套接字连贯并接管 Socket。
2）将连贯交给线程池 Executor 解决，开始执行申请响应工作。
3）Processor 组件读取消息报文，解析申请行、申请体、申请头，封装成 Request 对象。
4）Mapper 组件依据申请行的 URL 值和申请头的 Host 值匹配由哪个 Host 容器、Context 容器、Wrapper 容器解决申请。
5）CoyoteAdaptor 组件负责将 Connector 组件和 Engine 容器关联起来，把生成的 Request 对象和响应对象 Response 传递到 Engine 容器中，调用 Pipeline。
6）Engine 容器的管道开始解决，管道中蕴含若干个 Valve、每个 Valve 负责局部解决逻辑。执行完 Valve 后会执行根底的 Valve–StandardEngineValve，负责调用 Host 容器的 Pipeline。
7）Host 容器的管道开始解决，流程相似，最初执行 Context 容器的 Pipeline。
8）Context 容器的管道开始解决，流程相似，最初执行 Wrapper 容器的 Pipeline。
9）Wrapper 容器的管道开始解决，流程相似，最初执行 Wrapper 容器对应的 Servlet 对象的解决办法。
配置文件
首先看一下 tomcat 的目录构造
外围配置文件在 conf 目录下
Server.xml(重点)
其中最重要的就是 server.xml，次要配置了 tomcat 容器的所有配置。上面来看一下其中有哪些配置。
Server
是 server.xml 的根元素，用于创立一个 Server 实例，默认的实现是
<Server port="8005" shutdown="SHUTDOWN">
...
</Server>port：Tomcat 监听的敞开服务器的端口
shutdown：敞开服务器的指令字符串。
Server 内嵌的子元素为 Listener、GlobalNamingResources、Service。
配置的 5 个 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" />GlobalNamingResources 中定义了全局命名服务
Service
用于创立 Service 实例，内嵌的元素为：Listener、Executor、Connector、Engine，其中：Listener 用于为 Service 增加生命周期监听器，Executor 用于配置 Service 共享线程池，Connector 用于配置 Service 蕴含的链接器，Engine 用于配置 Service 中链接器对应的 Servlet 容器引擎。默认 Service 就叫 Catalina。
Executor
默认状况，Service 并未配置共享线程池，各个连接器应用的都是各自的线程池（默认 size 为 10）。如果咱们想增加一个线程池，能够在 Service 标签中增加如下配置
<Executor name="tomcatThreadPool"
namePrefix="catalina-exec-"
maxThreads="200"
minSpareThreads="100"
maxIdleTime="60000"
maxQueueSize="Integer.MAX_VALUE"
prestartminSpareThreads="false" threadPriority="5"
className="org.apache.catalina.core.StandardThreadExecutor"/> 相干属性阐明：
Connector
用于创立连接器实例，默认状况下，server.xml 配置了两个连接器，一个反对 HTTP 协定，一个反对 AJP 协定。
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />1）port：端口号，Connector 用于创立服务端 Socket 并进行监听，以期待客户端申请链接。如果该属性设置为 0，Tomcat 将会随机抉择一个可用的端口号给以后 Connector 应用。
2）protocol：以后 Connector 反对的拜访协定。默认为 HTTP/1.1，并采纳主动切换机制抉择一个基于 JAVA NIO 的链接器或者基于本地 APR 的链接器（依据本地是否含有 Tomcat 的本地库断定）。如果不心愿采纳上述主动切换的机制，而是明确指定协定，能够应用以下值。
Http 协定：
org.apache.coyote.http11.Http11NioProtocol，非阻塞式 Java NIO 链接器
org.apache.coyote.http11.Http11Nio2Protocol，非阻塞式 JAVA NIO2 链接器
org.apache.coyote.http11.Http11AprProtocol，APR 链接器
AJP 协定：
org.apache.coyote.ajp.AjpNioProtocol，非阻塞式 Java NIO 链接器
org.apache.coyote.ajp.AjpNio2Protocol，非阻塞式 JAVA NIO2 链接器
org.apache.coyote.ajp.AjpAprProtocol，APR 链接器
3）connectionTimeOut : Connector 接管链接后的期待超时工夫，单位为 毫秒。-1 示意不超时。
4）redirectPort：以后 Connector 不反对 SSL 申请，接管到了一个申请，并且也合乎 securityconstraint 束缚，须要 SSL 传输，Catalina 主动将申请重定向到指定的端口。
5）executor：指定共享线程池的名称，也能够通过 maxThreads、minSpareThreads 等属性配置外部线程池。
6）URIEncoding : 用于指定编码 URI 的字符编码，Tomcat8.x 版本默认的编码为 UTF-8 , Tomcat7.x 版本默认为 ISO-8859-1。
Engine
Engine 作为 Servlet 引擎的顶级元素，外部能够嵌入：Cluster、Listener、Realm、Valve 和 Host。
<Engine name="Catalina" defaultHost="localhost">
...
</Engine>1）name：用于指定 Engine 的名称，默认为 Catalina。该名称会影响一部分 Tomcat 的存储门路（如临时文件）。
2）defaultHost：默认应用的虚拟主机名称，当客户端申请指向的主机有效时，将交由默认的虚拟主机解决，默认为 localhost。在 ip 地址解析时首先依据 defaultHost 设置的 Host 从 Host 列表中找对用的 Host 跳转，如果没有再从 Host 列表中查找对应的，如果列表中没有，那么就会拜访不到。
除此之外，在默认的配置文件中还蕴含 Realn 标签，如下：
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<GlobalNamingResources>
<!-- Editable user database that can also be used by
UserDatabaseRealm to authenticate users
-->
<Resource auth="Container" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/>
</GlobalNamingResources><Realm> 标签是用来配置用户权限的。
首先说一下 tomcat 的权限治理。因为在 tomcat 中能够配置多个 web 我的项目，而 tomcat 为这些我的项目的治理创立了治理页面，也就是默认 webapps 下 host-manager 与 manager 文件夹的我的项目页面，为了保障安全性，拜访这两个我的项目须要设置权限，然而如果对每个新用户都独自的设置权限比拟繁琐麻烦，所以在 tomcat 中定义了几种不同的权限，咱们能够本人配置 “ 角色 ”(能够看作是特定权限的汇合) 和 “ 用户 ”(设置登录名、明码，与角色相关联)，而后就能够通过自定义的 “ 用户 ” 去拜访治理页面。” 角色 ” 和 “ 用户 ” 的配置默认能够在 tomcat-users.xml 中配置。当 tomcat 启动后，就会通过 conf 目录下的 server.xml 中的 Realm 标签来查看权限。
<Realm> 反对多种 Realm 治理形式：
1 JDBCRealm 用户受权信息存储于某个关系型数据库中，通过 JDBC 驱动获取信息验证
2 DataSourceRealm 用户受权信息存储于对于型数据中，通过 JNDI 配置 JDBC 数据源的形式获取信息验证
3 JNDIRealm 用户受权信息存储在基于 LDAP 的目录服务的服务器中，通过 JNDI 驱动获取并验证
4 UserDatabaseRealm 默认的配置形式，信息存储于 XML 文档中 conf/tomcat-users.xml
5 MemoryRealm 用户信息存储于内存的汇合中，对象汇合的数据来源于 xml 文档 conf/tomcat-users.xml
6 JAASRealm 通过 JAAS 框架拜访受权信息
下面代码块中能够看出 Realm 就是应用默认的 UserDatabaseRealm 形式配置。而它的 resourceName 就对应之前 <GlobalNamingResources> 中配置的 conf 目录下的 tomcat-users.xml 文件。
如果在 Engine 下配置 Realm，那么此配置将在以后 Engine 下的所有 Host 中共享。同样，如果在 Host 中配置 Realm，则在以后 Host 下的所有 Context 中共享。底层会笼罩掉下层对同一个资源的配置。
Host
用于配置一个虚拟主机，它反对以下嵌入元素：Alias、Cluster、Listener、Valve、Realm、Context。一个 Engine 标签下能够配置多个 Host。
<Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true">
...
</Host>属性阐明：
1）name: 以后 Host 通用的网络名称，必须与 DNS 服务器上的注册信息统一。Engine 中蕴含的 Host 必须存在一个名称与 Engine 的 defaultHost 设置统一。
2）appBase：以后 Host 的利用根底目录，以后 Host 上部署的 Web 利用均在该目录下（能够是相对目录，相对路径）。默认为 webapps。
3）unpackWARs：设置为 true，Host 在启动时会将 appBase 目录下 war 包解压为目录。设置为 false，Host 将间接从 war 文件启动。
4）autoDeploy：管制 tomcat 是否在运行时定期检测并主动部署新增或变更的 web 利用。
Context
用于配置一个 Web 利用。
<Context docBase="myApp" path="/myApp">
....
</Context>属性形容：
1）docBase：Web 利用目录或者 War 包的部署门路。能够是绝对路径，也能够是绝对于 Host appBase 的相对路径。
2）path：Web 利用的 Context 门路。如果咱们 Host 名为 localhost，则该 web 利用拜访的根门路为：http://localhost:8080/myApp。它反对的内嵌元素为：CookieProcessor，Loader，Manager，Realm，Resources，WatchedResource，JarScanner，Valve。
tomcat-user.xml(权限治理)
下面的 realm 标签说到这个文件是配合 realm 标签来设置用户权限的，所以就来看一下具体是如何设置的。
首先看一下默认配置
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">
<!--
NOTE: By default, no user is included in the "manager-gui" role required
to operate the "/manager/html" web application. If you wish to use this app,
you must define such a user - the username and password are arbitrary. It is
strongly recommended that you do NOT use one of the users in the commented out
section below since they are intended for use with the examples web
application.
-->
<!--
NOTE: The sample user and role entries below are intended for use with the
examples web application. They are wrapped in a comment and thus are ignored
when reading this file. If you wish to configure these users for use with the
examples web application, do not forget to remove the <!.. ..> that surrounds
them. You will also need to set the passwords to something appropriate.
-->
<!--
<role rolename="tomcat"/>
<role rolename="role1"/>
<user username="tomcat" password="<must-be-changed>" roles="tomcat"/>
<user username="both" password="<must-be-changed>" roles="tomcat,role1"/>
<user username="role1" password="<must-be-changed>" roles="role1"/>
-->
</tomcat-users><tomcat-users> 标签内有两个子标签，<role> 和 <user>，role 是用来设置 “ 角色 ”，而 user 是用来设置登陆 “ 用户 ” 的。治理页面是 webapps 下的 host-manager 与 manager 目录，别离来治理所有主机以及所有的 web 我的项目。如果咱们只将正文的局部关上，还是不能拜访治理页面，因为 tomcat 设置了特定的权限名，首先是 manager：
manager-gui 容许拜访 html 接口(即 URL 门路为 /manager/html/*)
manager-script 容许拜访纯文本接口(即 URL 门路为 /manager/text/*)
manager-jmx 容许拜访 JMX 代理接口(即 URL 门路为 /manager/jmxproxy/*)
manager-status 容许拜访 Tomcat 只读状态页面(即 URL 门路为 /manager/status/*)
对于 host-manager：
admin-gui 容许拜访 html 接口(即 URL 门路为 /host-manager/html/*)
admin-script 容许拜访纯文本接口(即 URL 门路为 /host-manager/text/*)
admin-jmx 容许拜访 JMX 代理接口(即 URL 门路为 /host-manager/jmxproxy/*)
admin-status 容许拜访 Tomcat 只读状态页面(即 URL 门路为 /host-manager/status/*)
如果咱们想让某个角色间接能拜访这两个我的项目页面，能够将 roles 配置成上面的设置，而后就能够拜访 manager 和 host-manager 页面了。
<user username="tomcat" password="tomcat" roles="admin-script,admin-gui,manager-gui,manager-script"/>Web.xml(不罕用)
web.xml 目前曾经很少再用了，所以这部分内容简略理解下即可。web.xml 文件分为 tomcat 装置目录的 conf 下的以及各个我的项目的 WEB-INF 目录下的。conf 下的是全局配置，所有 web 我的项目都会受到影响，而 WEB-INF 下的只会作用于以后我的项目，然而如果与 conf 下的 web.xml 配置抵触，那么就会笼罩掉 conf 的。
ServletContext 初始化全局参数
K、V 键值对。能够在应用程序中应用 javax.servlet.ServletContext.getInitParameter()办法获取参数值。
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext-*.xml</param-value>
<description>Spring Config File Location</description> <
</context-param> 会话设置
用于配置 Web 利用会话，包含 超时工夫、Cookie 配置以及会话追踪模式。它将笼罩 server.xml 和 context.xml 中的配置。
<session-config>
<session-timeout>30</session-timeout>
<cookie-config>
<name>JESSIONID</name>
<domain>www.itcast.cn</domain>
<path>/</path>
<comment>Session Cookie</comment>
<http-only>true</http-only>
<secure>false</secure>
<max-age>3600</max-age>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>1）session-timeout：会话超时工夫，单位：分钟
2）cookie-config：用于配置会话追踪 Cookie
name：Cookie 的名称
domain：Cookie 的域名
path：Cookie 的门路
comment：正文
http-only：cookie 只能通过 HTTP 形式进行拜访，JS 无奈读取或批改，此项能够减少网站拜访的安全性。
secure：此 cookie 只能通过 HTTPS 连贯传递到服务器，而 HTTP 连贯则不会传递该信息。留神是从浏览器传递到服务器，服务器端的 Cookie 对象不受此项影响。
max-age：以秒为单位示意 cookie 的生存期，默认为 - 1 示意是会话 Cookie，浏览器敞开时就会隐没。
3）tracking-mode：用于配置会话追踪模式，Servlet3.0 版本中反对的追踪模式：COOKIE、URL、SSL
A. COOKIE : 通过 HTTP Cookie 追踪会话是最罕用的会话追踪机制，而且 Servlet 标准也要求所有的 Servlet 标准都须要反对 Cookie 追踪。
B. URL : URL 重写是最根本的会话追踪机制。当客户端不反对 Cookie 时，能够采纳 URL 重写的形式。当采纳 URL 追踪模式时，申请门路须要蕴含会话标识信息，Servlet 容器会依据门路中的会话标识设置申请的会话信息。如：http：//www.myserver.com/user/index.html;jessionid=1234567890。
C. SSL : 对于 SSL 申请，通过 SSL 会话标识确定申请会话标识。
Servlet 配置
Servlet 的配置次要是两局部，servlet 和 servlet-mapping：
<servlet>
<servlet-name>myServlet</servlet-name>
<servlet-class>cn.itcast.web.MyServlet</servlet-class>
<init-param>
<param-name>fileName</param-name>
<param-value>init.conf</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
<enabled>true</enabled>
</servlet>
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>*.do</url-pattern>
<url-pattern>/myservet/*</url-pattern>
</servlet-mapping> 1）servlet-name : 指定 servlet 的名称，该属性在 web.xml 中惟一。
2）servlet-class : 用于指定 servlet 类名
3）init-param：用于指定 servlet 的初始化参数，在利用中能够通过 HttpServlet.getInitParameter 获取。
4）load-on-startup：用于管制在 Web 利用启动时，Servlet 的加载程序。值小于 0，web 利用启动时，不加载该 servlet, 第一次拜访时加载。
5）enabled：true，false。若为 false，示意 Servlet 不解决任何申请。
6）url-pattern：用于指定 URL 表达式，一个 servlet-mapping 能够同时配置多个 url-pattern。
Servlet 中文件上传配置：
<servlet>
<servlet-name>uploadServlet</servlet-name>
<servlet-class>cn.itcast.web.UploadServlet</servlet-class>
<multipart-config>
<location>C://path</location>
<max-file-size>10485760</max-file-size>
<max-request-size>10485760</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>
</servlet>1）location：寄存生成的文件地址。
2）max-file-size：容许上传的文件最大值。默认值为 -1，示意没有限度。
3）max-request-size：针对该 multi/form-data 申请的最大数量，默认值为 -1，示意无限度。
4）file-size-threshold：当数量量大于该值时，内容会被写入文件。
Listener 配置
Listener 用于监听 servlet 中的事件，例如 context、request、session 对象的创立、批改、删除，并触发响应事件。Listener 是观察者模式的实现，在 servlet 中次要用于对 context、request、session 对象的生命周期进行监控。在 servlet2.5 标准中共定义了 8 中 Listener。在启动时，ServletContextListener 的执行程序与 web.xml 中的配置程序统一，进行时执行程序相同。
<listener>
<listener- class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>Filter 配置
fifilter 用于配置 web 利用过滤器，用来过滤资源申请及响应。常常用于认证、日志、加密、数据转换等操作，配置如下：
<filter>
<filter-name>myFilter</filter-name>
<filter-class>cn.itcast.web.MyFilter</filter-class>
<async-supported>true</async-supported>
<init-param>
<param-name>language</param-name>
<param-value>CN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>myFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping> 1）filter-name：用于指定过滤器名称，在 web.xml 中，过滤器名称必须惟一。
2）filter-class：过滤器的全限定类名，该类必须实现 Filter 接口。
3）async-supported：该过滤器是否反对异步
4）init-param：用于配置 Filter 的初始化参数，能够配置多个，能够通过 FilterConfig.getInitParameter 获取
5）url-pattern：指定该过滤器须要拦挡的 URL。
欢送页面配置
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>尝试申请的程序，从上到下。
谬误页面配置
error-page 用于配置 Web 利用拜访异样时定向到的页面，反对 HTTP 响应码和异样类两种模式。
<error-page>
<error-code>404</error-code>
<location>/404.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/500.html</location>
</error-page>
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>平安与优化
平安
配置平安
1）删除 webapps 目录下的所有文件，禁用 tomcat 治理界面；
2）正文或删除 tomcat-users.xml 文件内的所有用户权限；
3）更改敞开 tomcat 指令或禁用；tomcat 的 server.xml 中定义了能够间接敞开 Tomcat 实例的治理端口（默认 8005）。能够通过 telnet 连贯上该端口之后，输出 SHUTDOWN（此为默认敞开指令）即可敞开 Tomcat 实例（留神，此时尽管实例敞开了，然而过程还是存在的）。因为默认敞开 Tomcat 的端口和指令都很简略。默认端口为 8005，指令为 SHUTDOWN。
计划一：更改端口号
<Server port="8456" shutdown="itcast_shut">计划二：禁用 8005 端口，设为 -1。
<Server port="-1" shutdown="SHUTDOWN">4）定义谬误页面，如果不定义在产生异样后会显示代码类名以及地位，会透露目录构造。在 webapps/ROOT 目录下定义谬误页面 404.html，500.html；而后在 tomcat/conf/web.xml 中进行配置，配置谬误页面：
<error-page>
<error-code>404</error-code>
<location>/404.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/500.html</location>
</error-page>利用平安
利用平安是指在某些隐衷页面应该是登陆用户或者管理员用户能力拜访的，而对于这些页面在权限不够时应该被拦挡，能够应用拦截器或者一些平安框架，比方 SpringSecurity、Shiro 等。
传输平安
传统的网络应用协定 HTTP 并不平安，此时能够应用 HTTPS 来代替，它在 HTTP 的根底上退出 SSL/TLS 来进行数据加密，爱护替换数据不被透露、窃取。
HTTPS 和 HTTP 的区别次要为以下四点：
1）HTTPS 协定须要到证书颁发机构 CA 申请 SSL 证书, 而后与域名进行绑定，HTTP 不必申请证书；
2）HTTP 是超文本传输协定，属于应用层信息传输，HTTPS 则是具备 SSL 加密传安全性传输协定，对数据的传输进行加密，相当于 HTTP 的升级版；
3）HTTP 和 HTTPS 应用的是齐全不同的连贯形式，用的端口也不一样，前者是 8080，后者是 8443。
4）HTTP 的连贯很简略，是无状态的；HTTPS 协定是由 SSL+HTTP 协定构建的可进行加密传输、身份认证的网络协议，比 HTTP 协定平安。
HTTPS 协定劣势：
1）进步网站排名，有利于 SEO。谷歌曾经公开申明两个网站在搜寻后果方面雷同，如果一个网站启用了 SSL，它可能会取得略高于没有 SSL 网站的等级，而且百度也表明对装置了 SSL 的网站示意敌对。因而，网站上的内容中启用 SSL 都有显著的 SEO 劣势。
2）隐衷信息加密，避免流量劫持。特地是波及到隐衷信息的网站，互联网大型的数据泄露的事件频发产生，网站进行信息加密势在必行。北京市昌平区建材城西路金燕龙办公楼一层 电话：400-618-9090
3）浏览器受信赖。自从各大支流浏览器大力支持 HTTPS 协定之后，拜访 HTTP 的网站都会提醒“不平安”的正告信息。
性能优化
性能测试
ApacheBench（ab）是一款 ApacheServer 基准的测试工具，用户测试 Apache Server 的服务能力（每秒解决申请数），它不仅能够用户 Apache 的测试，还能够用于测试 Tomcat、Nginx、lighthttp、IIS 等服务器。
装置：yum install httpd-tools
执行：b -n 1000 -c 100 -p data.json -T application/json http://localhost:9000/course/search.do?page=1&pageSize=10
参数阐明：
如果此申请须要携带 Post 数据，那么须要自定义一个文件来保留这个数据，个别应用 json 格局来保留传输
执行后果局部：
参数阐明：
重点须要关注的参数：
JVM 优化
因为 Tomcat 是一台 Java 服务器，所以它的优化就能够归结到 JVM 的优化上，而 Tomcat 在 JVM 上的优化能够分为垃圾回收器的抉择以及一些参数配置。对于垃圾回收器和相干参数配置这里就不过多论述了，这里只介绍下如何在 Tomcat 启动时携带咱们想要的配置。
windows 下：批改 bin/catalina.bat 文件，在第一行增加：set JAVA_OPTS=-server -Dfile.encoding=UTF-8 具体配置
linux 下：批改 bin/catalina.sh 文件，在第一行增加：JAVA_OPTS=” -server 具体配置 ”
Tomcat 配置优化
连接器的配置是决定 Tomcat 性能的要害，在个别状况下应用默认的就能够了，然而在程序比拟吃力时，就须要手动配置它来提高效率，残缺的配置如下：
<Connector port="8080"
protocol="HTTP/1.1"
executor="tomcatThreadPool"
maxThreads="1000"
minSpareThreads="100"
acceptCount="1000"
maxConnections="1000"
connectionTimeout="20000"
compression="on"
compressionMinSize="2048"
disableUploadTimeout="true"
redirectPort="8443"
URIEncoding="UTF-8" />相干参数：
maxThreads：示意 Tomcat 可创立的最大的线程数；
minSpareThreads：最小闲暇线程数，Tomcat 初始化时创立的线程数，该值应该少于 maxThreads，缺省值为 4；
acceptCount：指定当所有能够应用的解决申请的线程数都被应用时，能够放到解决队列中的申请数，超过这个数的申请将不予解决，默认为 10 个；
maxConnections：服务器在任何给定工夫承受和解决的最大连接数。
connectionTimeout：网络连接超时工夫，单位为毫秒，如果设置为“0”则示意永不超时，不倡议这样设置；
compression：默认为 off，开启是连接器在试图节俭服务器的带宽应用 HTTP/1.1 GZIP 压缩。敞开会主动在压缩和传输之间进行衡量。
compressionMinSize：在 compression 开启时，能够通过这个来配置进行压缩的最小数据量。默认为 “2048”。
disableUploadTimeout：上传文件时是否应用超时机制，默认开启，由 ConnectionTimeout 决定，如果为 false，那么只会在设置的 connectionUploadTimeout 设置的工夫后才会断开。
redirectPort：如果此连接器反对非 SSL 申请，并且收到匹配须要 SSL 传输的申请，Catalina 将主动将申请重定向到此处指定的端口号。
其余参数可参考博客 tomcat(4)连接器。
如果只是想简略配置，能够只配置 maxConnections、maxThreads、acceptCount。
Tomcat 附加性能 WebSocket
咱们在浏览网页时，个别应用的是 HTTP 协定或者 HTTPS 协定，这种形式是一种 “ 申请 — 响应 ” 模式，也就是只反对从客户端发送申请，服务器收到后进行解决，而后返回一个响应，然而不能被动发送数据给客户端，这样某些场景下的实现就比拟艰难，甚至无奈实现，比方聊天室实时聊天，可能有人会说间接将在 servlet 中解决向要发送音讯的客户端发送不就行了，然而因为是 “ 申请 - 响应 ” 模式，当其余客户端与服务器一段时间没有通信，连贯就会断开，服务器也就无奈转发音讯了。而 WebSocket 则是基于 HTTP 的一种长连贯协定，并且是双向通道，能够实现服务器被动向客户端发送音讯。
WebSocket 申请过程
WebSocket 申请和一般的 HTTP 申请有几点不同：
\1. GET 申请的地址不是相似 http://，而是以 ws:// 结尾的地址；
\2. 申请头 Connection: Upgrade 和 申请头 Upgrade: websocket 示意这个连贯将要被转换为 WebSocket 连贯；
\3. Sec-WebSocket-Key 是用于标识这个连贯，是一个 BASE64 编码的密文, 要求服务端响应一个对应加密的 Sec-WebSocket-Accept 头信息作为应答；
\4. Sec-WebSocket-Version 指定了 WebSocket 的协定版本;
\5. HTTP101 状态码表明服务端曾经辨认并切换为 WebSocket 协定 , Sec-WebSocket-Accept 是服务端与客户端统一的秘钥计算出来的信息。
Tomcat 的 7.0.5 版本开始反对 WebSocket, 并且实现了 Java WebSocket 标准 (JSR356), 而在 7.0.5 版本之前(7.0.2 之后) 则采纳自定义 API, 即 WebSocketServlet 实现。Java WebSocket 利用由一系列的 WebSocketEndpoint 组成。Endpoint 是一个 java 对象，代表 WebSocket 链接的一端，对于服务端，咱们能够视为解决具体 WebSocket 音讯的接口，就像 Servlet 之与 http 申请一样。咱们能够通过两种形式定义 Endpoint:
1). 第一种是编程式，即继承类 javax.websocket.Endpoint 并实现其办法。
2). 第二种是注解式, 即定义一个 POJO, 并增加 @ServerEndpoint 相干注解。Endpoint 实例在 WebSocket 握手时创立，并在客户端与服务端链接过程中无效，最初在链接敞开时完结。在 Endpoint 接口中明确定义了与其生命周期相干的办法，标准实现者确保生命周期的各个阶段调用实例的相干办法。生命周期办法如下：
通过为 Session 增加 MessageHandler 音讯处理器来接管音讯，当采纳注解形式定义 Endpoint 时，咱们还能够通过 @OnMessage 注解指定接管音讯的办法。发送音讯则由 RemoteEndpoint 实现，其实例由 Session 保护，依据应用状况，咱们能够通过 Session.getBasicRemote 获取同步音讯发送的实例，而后调用其 sendXxx()办法就能够发送音讯，能够通过 Session.getAsyncRemote 获取异步音讯发送实例。