Tomcat组件架构学习

tomcat组件架构以及配置文件详解

前言

们在学习一个新技术的时候,首先就是要了解这个技术的架构,要清楚整体都有哪些组件构成,每个组件提供了什么功能?工作原理又是怎么样的?tomcat的结构比较复杂,但是tomcat非常模块化,找到了tomcat最核心的模块,问题才可以迎刃而解。下面我和大家一起学习tomcat的整体架构以及配置文件。

tomcat架构

下图为tomcat顶层架构图

我们从外向内看,最顶层的容器是Server,代表整个服务器。也就是tomcat本身。一个tomcat只有一个server,一个Server可以包含至少一个service,service用于对外提供服务一个service 又是由多个connector(连接器)和container(容器)组成。而这两个组件就是tomcat的心脏,我们会对这两个组件详细解释。

1.一个tomcat实例只有一个server,一个server可以用多个service。

2.serivive是对外提供服务的

3.connetor是tomcat的连接器,用于处理连接相关的事情,每个service可以有多个connector,建立的连接协议可能有http/https协议也可能有AJP协议,每个协议对应不同的connector,也有可能是相同协议不同端口的连接也多应不同的connector。

4.container用于封装和管理Servlet,以及具体处理Request请求。提供Socket与Request和Response相关的转化。

备注:tomcat高度模块化,各个模块之间有嵌套的父子关系。如果使用配置文件来描述,可以大致简化为如下:


上图细化了当请求通过connector建立连接后,会发送给Engine,一个Engine包含多个Host,Engine会根据请求的报文头选择对应的Host去处理,然后每个Host还包含多个Context。

具体流程参照下图:

connector与container的关系

根据上述内容,我们知道当tomcat收到一个请求,首先会经过service 与对应的connector 建立好连接,并将请求和响应封装为Requetst 和Response来具体处理,封装好后交给container进行处理,Container处理完后返回给Connector,最后再由Connector通过Socker将处理的结果返回给客户端。整个请求就处理完了.

注意:

connector最底层使用的是Socket四层建立连接的,Request和Response是按照http 七层协议封装的,所以Connector要实现TCP/IP协议和HTTP协议。另外任何的web访问原理都是相同的,先建立tcp连接,然后在建立http/https连接。由下层到上层的连接需要封装。这里我们的connector功能之一就是封装

Connector的架构以及原理

 

Connector使用ProtocolHandle来处理请求的,不同的ProtocolHandle代表不同的连接类型,比如:Http11Protocol使用的是普通Socket来连接的,Http11NioProtocol使用的是NioSocket来连接的。其中ProtocolHandler由包含了三个部件:Endpoint、Processor、Adapter。

  • EndPoint 用来处理底层的Socket网络连接,Processor用于将Endpoint接受到的Socket封装成Request,Adapter将Request交给Container进行具体的处理。
  • Endpoint由于是处理底层的Socket网络连接,因此Endpoint是用来实现TCP/IP协议的,而Processor用来实现HTTP协议的,Adapter将请求适配到Servlet容器进行具体的处理。
  • Endpoint的抽象实现AbstractEndpoint里面定义的Acceptor和AsyncTimeout两个内部类和一个Handler接口。Acceptor用于监听请求,AsyncTimeout用于检查异步Request的超时,Handler用于处理接收到的Socket,在内部调用Processor进行处理。

那么Container是怎么处理Request的?处理后又是如何把结果返回给Connector的呢?请看Container架构分析。

Container架构分析

Container用于封装和管理Servlet,以及具体处理Request请求,在Connector内部包含了4个子容器,结构图如下

container包含四个子容器,分别是Engine Host Context Wrapper

  • Engine:引擎,是站点的管理员,一个Service只能有一个Engine
  • Host:代表一个站点,也可以叫做虚拟主机,通过Host可以添加
  • Context:代表一个应用程序,对应着平时开发的一套程序,或者一个WEB-INF目录以及下面的web.xml文件;
  • Wrapper:没一个Wrapper封装着一个Servlet;

下面找一个Tomcat的文件目录对照一下,如下图所示:

Context和Host的区别是Context表示一个应用,我们的Tomcat中默认的配置下的webapps下面的的每一个文件夹目录都是一个Context,其中ROOT目录中存放着主应用,其他目录存放着子应用,而整个webapps就是一个Host站点。

我们访问应用Context的时候,如果是ROOT下的则直接使用域名就可以访问,例如:www.ledouit.com,如果是Host(webapps)下的其他应用,则可以使用www.ledouit.com/docs进行访问,当然默认指定的根应用(ROOT)是可以进行设定的,只不过Host站点下默认的主营用是ROOT目录下的。

Container是如何处理请求的

Container处理请求是使用Pipline-Value管道来处理的!

Pipline-Value是责任链模式,也就是说一个请求处理的过程中有很多处理者依次对请求进行处理,每个处理者只负责自己的任务,处理完后将处理后的请求返回,再让下一个处理者继续处理。

注意:Pipeline-Value的责任模式和普通的责任链模式是不同的,区别如下:

  • 每个Pipline都有特定的Value,而且是在管道的最后一个执行,这个Value叫做BaseValue,BaseValue是不可以删除的
  • 在上层容器的管道的BaseValue中会调用下层容器的管道。我们知道Container包含四个子容器,而这四个子容器对应的BaseValue分别在:StandardEngineValue、StandardHostValue、StandardContextValue、StandardWrapperValue。

1.Connector在接收到请求后会首先调用最顶层容器的Pipeline来处理,这里的最顶层容器的Pipeline就是EnginePipeline(Engine的管道);

2.在Engine的管道中依次会执行EngineValue1、EngineValue2等等,最后会执行StandardEngineValue,在StandardEngineValue中会调用Host管道,然后再依次执行Host的HostValue1、HostValue2等,最后在执行StandardHostValue,然后再依次调用Context的管道和Wrapper的管道,最后执行到StandardWrapperValue

3.当执行到StandardWrapperValue的时候,会在StandardWrapperValue中创建FilterChain,并调用其doFilter方法来处理请求,这个FilterChain包含着我们配置的与请求相匹配的Filter和Servlet,其doFilter方法会依次调用所有的Filter的doFilter方法和Servlet的service方法,这样请求就得到了处理!

4.所有的Pipeline-Value都执行完之后,并且处理完了具体的请求,这个时候就可以将返回的结果交给Connector了,Connector在通过Socket的方式将结果返回给客户端。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Loading...