tomcat

文章目录

  • 1.Tomcat的安装和使用
    • 1.1 Tomcat安装启动
    • 1.2 Tomcat结构介绍
    • 1.3 Tomcat项目部署
    • 1.4 Tomcat创建配置
      • 1.4.1 默认访问
      • 1.4.2 解决控制台乱码
      • 1.4.3 修改Tomcat监听端口
      • 1.4.4 配置Tomcat并发数
      • 1.4.5 配置Tomcat Manager
    • 1.5 Tomcat主要组件
      • 1.5.1 Tomcat体系结构图
      • 1.5.2 Server组件
      • 1.5.3 Service组件
      • 1.5.4 Connector组件
      • 1.5.5 Engine组件
      • 1.5.6 Host组件
      • 1.5.7 Context组件
      • 1.5.8 tomcat请求过程
    • 1.6 HTTP协议
      • 1.6.1 HTTP协议介绍
      • 1.6.2 HTTP协议特点
      • 1.6.3 HTTP协议发展和版本
    • 1.7 HTTP请求
    • 1.8 HTTP响应
  • 2 JAVAWEB项目
    • 2.1 认识JAVAWEB项目结构
    • 2.2创建JAVAWEB项目
    • 2.3使用idea运行项目

1.Tomcat的安装和使用

1.1 Tomcat安装启动

下载地址:https://tomcat.apache.org/

Tomcat启动
运行startup文件

tomcat的启动需要java环境
需要配置JAVA环境变量

Tomcat关闭
运行shutdown文件或者直接关闭掉启动窗口

访问Tomcat

访问Tomcat的URL格式:http://ip:port
访问本机Tomcat的URL格式:http://localhost:8080

1.2 Tomcat结构介绍

1.3 Tomcat项目部署

如下图所示 我们都知道tomcat部署项目之后是访问的Webapps文件夹下的,如果我们把项目的位置移动了应该怎么办呢,
如下案例 编译好的项目名称myProject,我们把项目移动到D盘之后访问myProject文件中的index.html是找不到的
tomcat_第1张图片
这时候我们需要在如下位置中创建项目名的xml文件(Catalina下会虚拟我们的主机)
tomcat_第2张图片
文件夹中如下配置,告诉tomcat去哪里找项目,然后在启动tomcat就可以正常访问到啦
在这里插入图片描述

1.4 Tomcat创建配置

1.4.1 默认访问

我们正常启动tomcat之后他会默认访问
apache-tomcat-9.0.85\webapps\ROOT\index.jsp

1.4.2 解决控制台乱码

控制台产生乱码的原因是在Tomcat在输出日志中使用的是UTF-8编码,而我们中文的Windows操作系统使用的是GBK编码。由于编码格式不统一,所以出现了乱码。

解决方式:
修改conf目录中的logging.properties文件重新指定的编码方式。如果还是不行,那么就删除该行即可
在这里插入图片描述

1.4.3 修改Tomcat监听端口

Tomcat默认监听端口为8080。可以通过修改server.xml文件来改变Tomcat的监听端口。
tomcat_第3张图片
80是http协议默认的端口号:在http:1.1中,如果不写端口号那么默认端口号就是80

1.4.4 配置Tomcat并发数

Tomcat的最大并发数是可以配置的,实际运用中,最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件,更多的处理器都会使Tomcat支持更多的并发。
这个并发能力还与应用的逻辑密切相关,如果逻辑很复杂需要大量的计算,那并发能力势必会下降。如果每个请求都含有很多的数据库操作,那么对于数据库的性能也是非常高的。
对于单台数据库服务器来说,允许客户端的连接数量是有限制的。并发能力问题涉及整个系统架构和业务逻辑、系统环境不同、Tomcat版本不同、JDK版本不同、以及修改的设定参数不同。并发量的差异还是满大的。并发数设置参数有如下几个

maxThreads=“1000”
最大并发数

minSpareThreads=“100”
初始化时创建的线程数

maxSpareThreads=“500”
一旦创建的线程超过这个值,Tomcat就会关闭不再需要的socket线程。

acceptCount=“700”
指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予外理

1.4.5 配置Tomcat Manager

关于调优大话题 这里不做具体解释

什么是Tomcat Manager
Tomcat Manager是Tomcat自带的、用于对Tomcat自身以及部署在Tomcat上的应用进行管理的web应用。默认情况下,Tomcat Manager是处于禁用状态的。准确的说,Tomcat Manager需要以用户角色进行登录并授权才能使用相应的功能,不过Tomcat并没有配置任何默认的用户,因此我们需要先进行用户配置后才能使用Tomcat Manager。
配置Tomcat Manager的访问用户
Tomcat Manager中没有默认用户,我们需要在conf/tomcat-users.xml文件配置。Tomcat Manager的用户配置需要配置两个部分:角色配置、用户名及密码配置。
tomcat_第4张图片

配置完成用户和角色之后直接访问 如下项目中的index.jsp文件即可
tomcat_第5张图片

tomcat_第6张图片
tomcat_第7张图片

权限说明
admin-gui — 可访问 “host管理” 页面,但"APP管理" 和 “服务器状态” 页面无查看权限
manager-gui — 无 “host管理” 页面访问权限,有"APP管理" 和 “服务器状态” 页面查看权限
manager-status — 只有"服务器状态" 页面查看权限
manager-script — 有脚本方式管理接口访问权限和"服务器状态" 页面查看权限
manager-jmx — JMX 代理接口访问权限和"服务器状态" 页面查看权限
admin-script — 只有host-manager脚本方式管理接口访问权限

1.5 Tomcat主要组件

1.5.1 Tomcat体系结构图

tomcat_第8张图片

1.5.2 Server组件

启动一个server实例(即一个VM),它监听在80O5端口以接收shutdown命令。Server的定义不能使用同一个端口,这意味着如果在同一个物理机上启动了多个Server实例,必须配置它们使用不同的端口。

	<Server port="8005"
	shutdown="SHUTDOWN">

port:接收shutdown指令的端口,默认为8005;
shutdown:发往此Server用于实现关闭tomcat实例的命令字符串,默认为SHUTDOWN;

1.5.3 Service组件

Service主要用于关联一个引擎和与此引擎相关的连接器,每个连接器通过一个特定的端口和协议接收请求并将其转发至关联的引擎进行处理。困此,Service要包含一个引擎、一个或多个连接器。

<Service name="Catalina">

name:此服务的名称,默认为Catalina;

1.5.4 Connector组件

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

<Connector port="8888" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443/>

port:监听的端口
protocol:连接器使用的协议,默认为HTTP/1.1;
connectionTimeout:等待客户端发送请求的超时时间,单位为毫秒;
redirectPort:如果某连接器支持的协议是HTTP,当接收客户端发来的HTTPS请求时,则转发至此属性定义的端口;maxThreads:支持的最大并发连接数,默认为200个;

1.5.5 Engine组件

Engine是Servlet处理器的一个实例,即servlet引擎,定义在server.xml中的Service标记中。Engine需要defaultHost属性来为其定义一个接收所有发往非明确定义虚拟主机的请求的host组件。

<Engine name="Catalina"
defaultHost="localhost" >

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

1.5.6 Host组件

位于Engine容器中用于接收请求并进行相应处理的虚拟主机。通过该容器可以运行Servlet或者JSP来处理请求。

<Host name="localhost"appBase="webapps"
unpackWARs="true" autoDeploy="true">

name:虚拟主机的名称,Tomcat通过在请求URL中的域名与name中的值匹配,用于查找能够处理该请求的虚拟主机。如果未找到则交给在Engine中defaultHost指定的主机处理;
appBase: 此Host的webapps目录,即指定存放web应用程序的目录的路径;
autoDeploy:在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy;默认为true;unpackWARs:在启用此webapps时是否对WAR格式的归档文件先进行展开;默认为true;

1.5.7 Context组件

Context是Host的子标签,代表指定一个Web应用,它运行在某个指定的虚拟主机(Host)上;每个Web应用都是一个WAR文件,或文件的目录;

<Context path="/test"
docBase="D:\mashibing.war"/>

path: context path既浏览器访问项目的访问路径。
docBase:相应的Web应用程序的存放位置;也可以使用相对路径,起始路径为此Context所属Host中appBase定义的路径;

上边操作过Context 组件Tomcat项目部署目录中,本质就是操作的Context 组件,只不过我们是把它写到了虚拟主机下边,跟早server.xml操作是一样的

1.5.8 tomcat请求过程

tomcat_第9张图片

1、用户访问localhost8080/test/indexjsp请求被发送到Tomcat,被监听8080端口并处理HTTP/1.1协议的Connector获得。
2、Connector把该请求交给它所在的Service的Engine来处理,并等待E
ngine的回应。
3、Engine获得请求localhost/test/index.jsp,匹配所有的虚拟主机Ha
ost。
4、Engine匹配到名为localhost的Host虚拟主机来处理/test/indexjsp请求(即使匹配不到会请求交给默认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。

1.6 HTTP协议

1.6.1 HTTP协议介绍

什么是超文本
html页面上全是文字,但是浏览器解析之后,展现出来的页面是非常丰富的
超文本是用超链接的方法,将各种不同空间的文字信息组织在一起的网状文本。超文本更是一种用户界面范式,用以显示文本及与文本之间相关的内容。

什么是HTTP协议
HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,HTTP是万维网(WWw:World Wide Web)的数据通信的基础。
HTTP是一个简单的请求-响应协议,它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
tomcat_第10张图片
HTTP是一个基于TCP/IP通信协议来传递数据(HTML文件,图片文件,查询结果等)。
tomcat_第11张图片

1.6.2 HTTP协议特点

1支持客户/服务器模式
HTTP协议支持客户端服务端模式,需要使用浏览器作为客户端来访问服务端。
2简单快速
客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、POST等。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
3灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type (Content-Type是HTTP包中用来表示内容类型的标识)加以标记.
4无连接
每次请求一次,释放一次连接。所以无连接表示每次连接只能处理一个请求。优点就是节省传输时间,实现简单。我们有时称这种无连接为短连接。对应的就有了长链接,长连接专门解决效率问题。当建立好了一个连接之后,可以多次请求
但是缺点就是容易造成占用资源不释放的
问题。当HTTP协议头部中字段Connection: keep-alive表示支持长链接。
5单向性
服务端永远是被动的等待客户端的请求。
6无状态
HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。为了解决HTTP协议无状态,于是,两种用于保持HTTP连接状态的技术就应运而生了,一个是Cookie,而另一个则是Session。

1.6.3 HTTP协议发展和版本

http协议在1991年发布第一个版本版本号为0.9。随后WWW联盟(WWW Consortium-W3C)于1994年成立,http协议被纳入到W3C组织中进行维护和管理。

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

1.1中最重要的一个特点是支持“长连接”,即“一次连接可以多次请求”。
tomcat_第12张图片
HTTP1.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中引入了新的编码机制,所有传输的数据都会被分割,并采用二进制格式编码。
tomcat_第13张图片
多路复用,连接共享。不同的request可以使用同一个连接传输(最后根据每个request上的id号组合成正常的请求)。
HTTP2.0中,有两个概念非常重要:帧(frame)和流(stream)。
帧是最小的数据单位,每个帧会标识出该帧属于哪个流,流是多个帧组成的数据流。
所谓多路复用,即在一个TCP连接中存在多个流,即可以同时发送多个请求,对端可以通过帧中的表示知道该帧属于哪个请求。在客户端,这些帧乱序发送,到对端后再根据每个帧首部的流标识符重新组装。通过该技术,可以避免HTTPI旧版本的队头阻塞问题,极大提高传输性能。
tomcat_第14张图片
首部压缩(Header Compression)
由于1.1中header带有大量的信息,并且得重复传输,2.0使用encoder来减少需要传输的hearder大小。

服务端推送(Server Push)

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

更安全

HTTP2.0使用了tis的拓展ALPN做为协议升级,除此之外,HTP2.0对ts的安全性做了近一步加强,通过黑名单机制禁用了几百种不再安全的加密算法。
tomcat_第15张图片

1.7 HTTP请求

一个http请求可以分为3三个部分,分别是请求行,请求头,请求体

tomcat_第16张图片
请求行
tomcat_第17张图片

请求头
tomcat_第18张图片

请求体

get方式提交的请求数据通过地址栏提交没有请求体
post方式提交请求数据单独放到请求体中,
请求时所携带的数据(post方式)

http支持的请求方式
tomcat_第19张图片

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中。I

1.8 HTTP响应

http响应部分可以分为三部分:响应行,响应头,响应体

响应行
tomcat_第20张图片
响应状态码列表如下
tomcat_第21张图片
响应头
Content-Type:响应内容的类型(MIME)
tomcat_第22张图片
响应实体
服务器响应回来的内容

2 JAVAWEB项目

2.1 认识JAVAWEB项目结构

  • project项目的根目录
    • 静态资源文件/jsp
    • WEB-INF受保护的资源目录
      • lib jar包目录
      • classes java字节码目录、
      • web.xml项目的配置文件
      • 其他资源

层级关系图如下

结构图1
tomcat_第23张图片
结构图2
tomcat_第24张图片

2.2创建JAVAWEB项目

tomcat_第25张图片
结构图
tomcat_第26张图片

2.3使用idea运行项目

tomcat_第27张图片
可以模拟上图准备一些项目资源

运行之前先调试tomcat
tomcat_第28张图片
tomcat_第29张图片
IDEA运行tomcat原理: idea会虚拟一个tomcat,然后使用tomcat虚拟的主机来配置项目的打包位置(原理请看1.3 Tomcat项目部署

你可能感兴趣的:(tomcat,java)