Tomcat学习笔记

安装和使用

地址：http://tomcat.apache.org/

目录结构

bin
bin目录主要是用来存放tomcat的命令文件，主要有两大类，一类是以.sh结尾的（linux命令），另一类是以.bat结尾的（windows命令）。

conf
conf目录主要是用来存放tomcat的一些配置文件。

lib
lib目录主要用来存放tomcat运行需要加载的jar包。

log
logs目录用来存放tomcat在运行过程中产生的日志文件。
temp
temp目录用户存放tomcat在运行过程中产生的临时文件。（清空不会对tomcat运行带来影响）
webapps
webapps目录用来存放应用程序，当tomcat启动时会去加载webapps目录下的应用程序。可以以文件夹、war包的形式发布应用。
work
work目录用来存放tomcat在运行时的编译后文件，例如JSP编译后的文件。

部署项目

方法1



方法2
localhost中添加配置文件
<Context path=“/myProject” docBase=“d:/myProject”/>
建议配置文件名和项目名相同

常见配置

Tomcat配置文件介绍
Tomcat 的配置文件由4个xml组成，分别是 context.xml、web.xml、server.xml、tomcat-users.xml。每个文件都有自己的功能与配置方法。
context.xml
Context.xml 是 Tomcat 公用的环境配置。 Tomcat 服务器会定时去扫描这个文件。一旦发现文件被修改（时间戳改变了），就会自动重新加载这个文件，而不需要重启服务器。
web.xml
Web应用程序描述文件，都是关于是Web应用程序的配置文件。所有Web应用的 web.xml 文件的父文件。
server.xml
是 tomcat 服务器的核心配置文件，server.xml的每一个元素都对应了 tomcat中的一个组件，通过对xml中元素的配置，实现对 tomcat中的各个组件和端口的配置。
tomcat-users.xml
配置访问Tomcat的用户以及角色的配置文件。
解决控制台乱码
控制台产生乱码的原因是在Tomcat在输出日志中使用的是UTF-8编码，而我们中文的Windows操作系统使用的是GBK编码。由于编码格式不统一，所以出现了乱码。
解决方式：
修改conf目录中的logging.properties文件重新指定的编码方式。如果还是不行,那么 就删除该行即可
java.util.logging.ConsoleHandler.encoding = GBK
修改Tomcat监听端口
Tomcat默认监听端口为8080。可以通过修改server.xml文件来改变Tomcat的监听端口。

80是http协议默认的端口号:在http:1.1中,如果不写端口号那么默认端口号就是80
配置Tomcat并发数
Tomcat的最大并发数是可以配置的，实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。
这个并发能力还与应用的逻辑密切相关，如果逻辑很复杂需要大量的计算，那并发能力势必会下降。如果每个请求都含有很多的数据库操作，那么对于数据库的性能也是非常高的。
对于单台数据库服务器来说，允许客户端的连接数量是有限制的。并发能力问题涉及整个系统架构和业务逻辑、系统环境不同、Tomcat版本不同、JDK版本不同、以及修改的设定参数不同。并发量的差异还是满大的。并发数设置参数有如下几个
maxThreads=“1000” 最大并发数
minSpareThreads=“100” 初始化时创建的线程数
maxSpareThreads=“500” 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。
acceptCount=“700” 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
配置实例：

配置Tomcat Manager
Tomcat Manager是Tomcat自带的、用于对Tomcat自身以及部署在Tomcat上的应用进行管理的web应用。默认情况下，Tomcat Manager是处于禁用状态的。准确的说，Tomcat Manager需要以用户角色进行登录并授权才能使用相应的功能，不过Tomcat并没有配置任何默认的用户，因此我们需要先进行用户配置后才能使用Tomcat Manager。
配置Tomcat Manager的访问用户
Tomcat Manager中没有默认用户，我们需要在tomcat-users.xml文件配置。Tomcat Manager的用户配置需要配置两个部分：角色配置、用户名及密码配置。
Tomcat Manager中的角色分类
manager-gui角色： 允许访问HTML GUI和状态页面(即URL路径为/manager/html/*)
manager-script角色： 允许访问文本界面和状态页面(即URL路径为/manager/text/*)
manager-jmx角色： 允许访问JMX代理和状态页面(即URL路径为/manager/jmxproxy/*)
manager- status角色： 仅允许访问状态页面(即URL路径为/manager/status/*)
配置用户及角色

主要组件

Server组件
启动一个server实例（即一个JVM），它监听在8005端口以接收shutdown命令。Server的定义不能使用同一个端口，这意味着如果在同一个物理机上启动了多个Server实例，必须配置它们使用不同的端口。

port:接收shutdown指令的端口，默认为8005；
shutdown：发往此Server用于实现关闭tomcat实例的命令字符串，默认为SHUTDOWN；
Service组件
Service主要用于关联一个引擎和与此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收请求并将其转发至关联的引擎进行处理。困此，Service要包含一个引擎、一个或多个连接器。

name：此服务的名称，默认为Catalina；
Connector组件
支持处理不同请求的组件，一个引擎可以有一个或多个连接器，以适应多种请求方式。默认只开启了处理Http协议的连接器。如果需要使用其他协议，需要在Tomcat中配置该协议的连接器。
在Tomcat中连接器类型通常有4种：
1)HTTP连接器
2)SSL连接器
3)AJP 1.3连接器
4)proxy连接器

port：监听的端口
protocol：连接器使用的协议，默认为HTTP/1.1;
connectionTimeout：等待客户端发送请求的超时时间，单位为毫秒;
redirectPort：如果某连接器支持的协议是HTTP，当接收客户端发来的HTTPS请求时，则转发至此属性定义的端口;
maxThreads：支持的最大并发连接数，默认为200个;
Engine组件
Engine是Servlet处理器的一个实例，即servlet引擎，定义在server.xml中的Service标记中。Engine需要defaultHost属性来为其定义一个接收所有发往非明确定义虚拟主机的请求的host组件。

name：Engine组件的名称;
defaultHost：Tomcat支持基于FQDN(Fully Qualified Domain Name 全限定域名)的虚拟主机，这些虚拟主机可以通过在Engine容器中定义多个不同的Host组件来实现；但如果此引擎的连接器收到一个发往非非明确定义虚拟主机的请求时则需要将此请求发往一个默认的虚拟主机进行处理，因此，在Engine中定义的多个虚拟主机的主机名称中至少要有一个跟defaultHost定义的主机名称同名；
Host组件
位于Engine容器中用于接收请求并进行相应处理的虚拟主机。通过该容器可以运行Servlet或者JSP来处理请求。

name：虚拟主机的名称，Tomcat通过在请求URL中的域名与name中的值匹配，用于查找能够处理该请求的虚拟主机。如果未找到则交给在Engine中defaultHost指定的主机处理；
appBase：此Host的webapps目录，即指定存放web应用程序的目录的路径；
autoDeploy：在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy；默认为true；
unpackWARs：在启用此webapps时是否对WAR格式的归档文件先进行展开；默认为true；
Context组件
Context是Host的子标签，代表指定一个Web应用，它运行在某个指定的虚拟主机（Host）上；每个Web应用都是一个WAR文件，或文件的目录；

path：context path既浏览器访问项目的访问路径。
docBase：相应的Web应用程序的存放位置；也可以使用相对路径，起始路径为此Context所属Host中appBase定义的路径；
Tomcat处理请求过程

1、用户访问localhost:8080/test/index.jsp，请求被发送到Tomcat，被监听8080端口并处理HTTP/1.1 协议的Connector获得。
2、Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。
3、Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host。
4、Engine匹配到名为localhost的Host虚拟主机来处理/test/index.jsp请求（即使匹配不到会请求交给默认Host处理），Host会根据/test匹配它所拥有的所有的Context。
5、匹配到的Context获得请求/index.jsp。
6、构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）.执行业务逻辑、数据存储等程序。
7、Context把执行完之后的结果通过HttpServletResponse对象返回给Host。
8、Host把HttpServletResponse返回给Engine。
9、Engine把HttpServletResponse对象返回Connector。
10、Connector把HttpServletResponse对象返回给客户Browser。

HTTP

http1.0
最早在1996年在网页中使用，内容简单，所以浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）,请求只能由客户端发起（单向性）。
http1.1
到1999年广泛在各大浏览器网络请求中使用，HTTP/1.0中默认使用Connection: close。在HTTP/1.1中已经默认使用Connection: keep-alive（长连接），避免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。通过Content-Length字段来判断当前请求的数据是否已经全部接收。不允许同时存在两个并行的响应。
1.1中最重要的一个特点是支持“长连接”，即“一次连接可以多次请求”。

HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
http2.0

• 长连接
  在HTTP/2中，客户端向某个域名的服务器请求页面的过程中，只会创建一条TCP连接，即使这页面可能包含上百个资源。 单一的连接应该是HTTP2的主要优势，单一的连接能减少TCP握手带来的时延。HTTP2中用一条单一的长连接，避免了创建多个TCP连接带来的网络开销，提高了吞吐量。

• 多路复用 (Multiplexing)
  HTTP2.0中所有加强性能的核心是二进制传输，在HTTP1.x中，我们是通过文本的方式传输数据。在HTTP2.0中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。
  
  多路复用，连接共享。不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）。

HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）。
帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。
所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求。在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能。

• 首部压缩（Header Compression）
  由于1.1中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小。

• 服务端推送（Server Push）
  在HTTP2.0中，服务端可以在客户端某个请求后，主动推送其他资源。
  可以想象一下，某些资源客户端是一定会请求的，这时就可以采取服务端push的技术，提前给客户端推送必要的资源，就可以相对减少一点延迟时间。在浏览器兼容的情况下也可以使用prefetch。

• 更安全
  HTTP2.0使用了tls的拓展ALPN做为协议升级，除此之外，HTTP2.0对tls的安全性做了近一步加强，通过黑名单机制禁用了几百种不再安全的加密算法。
  

请求

Request 消息分为3部分，第一部分叫Request line, 第二部分叫Request header, 第三部分是Request body。Request header和Request body之间有个空行。

请求的主要组成部分
请求行 request Line GET /myProject/img/logo.png HTTP/1.1
1请求方式 默认 GET
2资源路径
3请求使用的协议

请求头 request headers
请求体 request body

请求方式
GET
向指定的资源发出“显示”请求。GET请求中会将请求中传递的数据包含在URL中并在浏览器的地址栏中显示。GET请求传递数据时要求数据必须是ASCII字符。GET请求可以被浏览器缓存。

POST
向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求传递数据时，数据可以试试ASCII字符也可以是字节型数据，默认为字符型。POST请求默认情况下不会被浏览器所缓存。

HEAD
向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头度中的元信息。

PUT
向指定资源位置上传其最新内容。

DELETE
请求服务器删除Request-URI所标识的资源。

TRACE
回显服务器收到的请求，主要用于测试或诊断。

OPTIONS
这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

GET和POST的区别(重要,面试常问)
Ø GET在浏览器回退时是无害的，而POST会再次提交请求。
Ø GET产生的URL地址可以被Bookmark，而POST不可以。
Ø GET请求会被浏览器主动cache，而POST不会，除非手动设置。
Ø GET请求只能进行url编码，而POST支持多种编码方式。
Ø GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
Ø GET请求在URL中传送的参数是有长度限制的，而POST则没有。对参数的数据类型GET只接受ASCII字符，而POST即可是字符也可是字节。
Ø GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
Ø GET参数通过URL传递，POST放在Request body中。

响应

响应行：HTTP/1.1 200
和请求消息相比，响应消息多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。
状态码

在idea开发和部署

项目结构

开发

选择Java Enterprise
1_Project SDK选项 推荐 1.8 如果没有SDK 可以通过后面的 NEW按钮选择自己的JDK安装路径即可 (注意选择的是bin的上一层)
2_Java EE version 推荐JAVA EE 8
3_Application Server 关联Tomcat容器,如果没有, NEW按钮选择自己的Tomcat安装路径即可 (注意选择的是bin的上一层)
4_Additional Libraries and Freameworks 中 必须勾选 Web Applicaiton(4.0)选项 同时注意 create web.xml勾选上

运行

启动项目之前,先对项目进行配置
点击Edit Configurations 对项目进行启动之前的配置

在Deployment中, Deployed at the server startup里确认要部署的项目是不是我们要运行的项目
在Application context中指定我们项目访问的路径名,
idea默认是 项目名+“_war_exploded”,在这里我们可以对项目的访问名进行修改,如果不修改,也OK,可以一样使用

在Server选项中,
勾选Open browser中的After launch选项,这样idea在启动项目之后可以自动帮助我们打开浏览器并访问URL中的资源
On Update action : 当代码改变的时候，需要IDEA为你做什么；选项选为 Update classes and resources ,意义为:更新字节码和其他资源
On Frame deactivation : 当失去焦点（比如你最小化了IDEA窗口），需要IDEA为你做什么。选项选为 Update resources ,意义为:更新其他资源
HTTP port 默认为8080 不用修改
JMX port 默认为 1099 不用修改
然后点击OK


启动之后 用浏览器打开对应文件,
控制台网络一栏共发现4个有效请求
firstpage.html为我们请求的页面
myjs.js mycss.css logo.png 这三个请求和响应是因为 firstpage.html中引入的 这三个文件,浏览器自动发送请求获得这三个文件
favicon.ico 是在请求Tomcat中的"小狮子" 图片,这里请求失败,响应码是404 无所谓,暂时当它不存在即可,后续会解释
第一种 Idea部署JAVAWEB项目并运行的方式(掌握)
在Idea中默认的并不会把web项目真正的部署到Tomcat的webapps目录中，而是通过为每个web项目创建一个独立的Tomcat副本并在Tomcat副本中通过的Tomcat的Context组件完成项目的目录指定，在Context组件的docBase属性中会指定Idea对web项目编译后的目录out/artifacts/…。

默认部署方式
Idea会在C:\Users\Administrator.IntelliJIdea2019.2\system\tomcat中为每个Web项目创建一个独立的Tomcat副本。
C:\Users\Administrator.IntelliJIdea2019.2\system\tomcat\Tomcat_9_0_34_demo_4\conf\Catalina\localhost目录中生成一个该项目的xml文件名称为：”项目名.xml”。
Idea通过执行Tomcat的catalina.bat启动脚本启动Tomcat，通过启动参数来指定启动Tomcat副本运行指定目录中的web项目。

Idea在启动Tomcat之前会先在操作系统中设置一些临时环境变量，这些变量会被Tomcat的启动脚本所读取。

CATALINA_BASE：是Tomcat副本的工作目录
CATALINA_HOME：是Tomcat的安装目录

在Catalina.bat启动脚本运行时，会先去判断脚本中的CATALINA_HOME以及CATALINA_BASE是否有默认值，如果没有则直接读取系统环境变量中的值作为他们的默认值。由于Idea在启动Tomcat之前已经设置了临时环境变量，所以tomcat在启动后就会运行部署在Tomcat副本中的web项目。

第二种部署方式(了解)
将web项目部署到Tomcat的webapps中
点击项目结构选项
指定输出artifacts的目录为Tomcat的webapps中的demo目录。

在tomcat的webapps中创建一个目录。
启动Tomcat，查看demo目录中的内容。