Tomcat 1—— 结构分析

最新推荐文章于 2022-12-20 18:12:01 发布

郗富琦

最新推荐文章于 2022-12-20 18:12:01 发布

阅读量1k

点赞数

分类专栏： Java技术文章标签： tomcat

本文链接：https://blog.csdn.net/cheviko/article/details/79755080

版权

Java技术专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Tomcat 一结构分析

本系列包含如下几个内容：
1. tomcat结构分析
2. 配置tomcat多域名访问
3. 配置https访问

1 几个重要概念

Tomcat是常用的servlet容器，要了解其结构首先需要清楚几个基本概念：

图1 URL解析
* http，是通讯协议，类似的协议还可以是https
* www.zzt.com，是域名或者称之为主机 host
* 8080 是端口号，常用的http协议端口号是80，https协议端口号是443
* web1 该路径关系到server.xml中context的配置，engine根据该配置决定如何解析路径。
* URI，uniform resource identifier URI。就是在某一规则下能把一个资源独一无二地标识出来。假设这个世界上所有人的名字都不能重复，那么名字就是URI的一个实例，通过名字这个字符串就可以标识出唯一的一个人。现实当中名字当然是会重复的，所以身份证号才是URI。
* URL，uniform resource locator。通过描述是哪个主机上哪个路径上的文件来唯一确定一个资源，也就是定位的方式来实现的URI。
* 不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。*

2 模块组成结构

先通过一个实例说明浏览器是如何跟tomcat通讯的，假设用户访问http://www.zzt.com:8080/web1/hello.jsp

• 1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1(也可能是nio或者apr)Connector获得
• 2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
• 3) Engine获得请求www.zzt.com/web1/hello.jsp，匹配它所拥有的所有虚拟主机Host
• 4) Engine匹配到名为www.zzt.com的Host（如果匹配不到把请求交给该Engine的默认主机）
• 5) www.zzt.com Host获得请求/web1/hello.jsp，匹配它所拥有的所有Context
• 6) Host匹配到路径为/web1的Context（如果匹配不到就把该请求交给路径名为”“的Context去处理）
• 7) path=”/web1”的Context获得请求/hello.jsp，在它的mapping table中寻找对应的servlet(或者path=”“的context获得请求/web1/hello.jsp)
• 8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类
• 9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法
• 10)Context把执行完了之后的HttpServletResponse对象返回给Host
• 11)Host把HttpServletResponse对象返回给Engine
• 12)Engine把HttpServletResponse对象返回给Connector
• 13)Connector把HttpServletResponse对象返回给客户browser

上述过程也可以参考下面的组成结构分析：

3 文档组成结构

tomcat的核心配置文档是server.xml，该文档的组成结构如下

<Server>
    <Listener />
    <GlobaNamingResources>
    </GlobaNamingResources>
    <Service>
        <Connector />
        <Engine>
            <Logger />
            <Realm />
                <host>
                    <Logger />
                    <Context />
                </host>
        </Engine>
    </Service>
</Server>

server：代表整个容器,是Tomcat实例的顶层元素.由org.apache.catalina.Server接口来定义。一个server可包含多个“service”实例，服务器默认在8005端口监听shutdown命令。

备注：一个“Server”自身不是一个“Container”（容器），因此不可以定义诸如“Valves”或者“Loggers”子组件。8005是安全隐患，建议改为其他端口。
测试：
telnet localhost 8005
输入：SHUTDOWN
结果：关闭tomcat

service 元素，由org.apache.catalina.Service接口定义。Service包含一个或多个connector元素，而这些connector共享一个Engine元素。即：Service是一组Connector的集合，它们共用一个Engine来处理所有Connector收到的请求。

注意：一个“Service”自身不是一个容器，因此，不可定义诸如“Valves”或“Loggers”子组件。

connector元素，由Connector接口定义.元素代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果。配置http为https主要是修改connector。
Engine元素。每个Service元素只能有一个Engine元素.处理在同一个中所有元素接收到的客户请求.由org.apahce.catalina.Engine接口定义. Engine用来处理Connector收到的Http请求它将匹配请求和自己的虚拟主机，并把请求转交给对应的Host来处理。
Host元素。一个Engine元素可以包含多个元素.每个的元素定义了一个虚拟主机.它包含了一个或多个Web应用.

备注：
appBase : 指定虚拟主机的目录,可以指定绝对目录,也可以指定相对于的相对目录.如果没有此项,默认为/webapps. 它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
autoDeploy:如果此项设为true,表示Tomcat服务处于运行状态时,能够监测appBase下的文件,如果有新有web应用加入进来,会自运发布这个WEB应用
unpackWARs:如果此项设置为true,表示把WEB应用的WAR文件先展开为开放目录结构后再运行.如果设为false将直接运行为WAR文件
alias:指定主机别名,可以指定多个别名
deployOnStartup:如果此项设为true,表示Tomcat服务器启动时会自动发布appBase目录下所有的Web应用.如果Web应用中的server.xml没有相应的元素,将采用Tomcat默认的Context

context 元素。由Context接口定义.是使用最频繁的元素，对应于一个Web App。

path : 该Context的路径名是”“，故该Context是该Host的默认Context。
docBase : 该Context的根目录是webapps/mycontext/
reloadable:如果这个属性设为true, Tomcat服务器在运行状态下会监视在WEB-INF/classes和Web-INF/lib目录CLASS文件的改运.如果监视到有class文件被更新,服务器自重新加载Web应用
useNaming:指定是否支持JNDI,默认值为了true
cookies指定是否通过Cookies来支持Session,默认值为true

** 参考资料：
https://www.cnblogs.com/yanghua1012/p/5869192.html