Tomcat系列(一)- 整体架构

整体架构

  我们想要了解一个框架,首先要了解它是干什么的,Tomcat我们都知道,是用于处理连接过来的Socket请求的。那么Tomcat就会有两个功能:

    • 对外处理连接,将收到的字节流转化为自己想要的Request和Response对象
    • 对内处理Servlet,将对应的Request请求分发到相应的Servlet中

  那么我们整体的骨架就出来了,Tomcat其实就分为两大部分,一部分是连接器(Connnector)处理对外连接和容器(Container)管理对内的Servelet。

  大体的关系图如下:

  

  描述:

    最外层的大框就是代表一个Tomcat服务,一个Tomcat服务可以对应多个Service。每个Service都有连接器和容器。

    这些对应的关系我们也可以打开在Tomcat目录配置文件中 server.xml中看出来。

<Server port="8006" shutdown="SHUTDOWN">
    <Service name ="Catalina">
        <Connector port ="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>
        <Connector port="8010" protocol="AJP/1.3" redirectPort="8443"/>
        <Engine name="Catalina" defaultHost="localhost">
            <Realm className="org.apache.catalina.realm.LockOutRealm">
                <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
            </Realm>
            <Host name="localhost" appBase="webapps"></Host>
        </Engine>
    </Service>
</Server>

  这里我们可以看到连接器其实就是 Connector,一个Service中可以有多个连接器,容器其实对应的就是 Engine

  Tomcat的整体架构简单来说就是这样的对应关系。接下来我们简单的介绍连接器的整体架构和容器的整体架构。

连接器

  我们可以看到上图中连接器传给容器的是 ServletRequest对象,而容器传给连接器的是 ServletResponse对象,这些在网络传输过程中是肯定不行的,因为网络传输中传送的字节流。

  所以连接器的功能需求我们大概能总结出来以下几点。

    • Socket连接
    • 读取请求网络中的字节流
    • 根据相应的协议(Http/AJP)解析字节流,生成统一的 TomcatRequestt对象
    • 将 TomcatReques传给容器
    • 容器返回 TomcatResponse对象
    • 将 TomcatResponse对象转换为字节流
    • 将字节流返回给客户端

  其实上面的细分都能总结为以下的三点

    • 网络通信
    • 应用层协议的解析
    • Tomcat的 Request/Response与 ServletRequest/ServletResponse对象的转化

  而在Tomcat中它也用了三个类来实现上面的三个功能,分别对应如下

    • EndPoint
    • Processor
    • Adapter

  用图表示他们的关系的话就是这样

   

容器

  容器,顾名思义就是装东西的器具,那么这个Tomcat容器是装什么的呢?其实主要的就是装了Servlet的。

  那么容器是如何设计的呢?Tomcat的容器设计其实是用了组合设计模式(不了解组合设计模式的可以看我之前的文章不学无数——组合模式)。

  其实从 Server.xml中我们也能看到其关系了。

<Engine name="Catalina" defaultHost="localhost">
    <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"></Host>
</Engine>

  在这里面我们只能看到容器中的两个模块,一个是顶层模块 Engine,另一个是 Host

  其实还有两个模块:

    一个是 Context对应的是我们webapp里面的每个应用文件夹,每个文件夹就是对应一个 Context

    还有一个模块 Wrapper对应的是我们 Context中的所有servlet, Wrapper管理了访问关系与具体的Servlet的对应。图表示就是下面这样。

  

  Tomcat中容器所有模块都实现了 Container接口,而组合模式的意义就是使得用户对于单个对象和组合对象的使用具有一致性,

  即无论添加多少个 Context其使用就是为了找到其下面的Servlet,而无论添加多少个Host也是为了找个下面的Servlet。

  而在容器中设计了这么多的模块,一个请求过来Tomcat如何找到对应的Servlet进行处理呢?

请求如何定位

  我们就举个最简单的例子,我们本机应用上启动了一个Tomcat,webapp下有我们部署的一个应用 buxuewushu

  我们在浏览器上输入 http://localhost:8080/buxuewushu/add.do是如何找到对应Servlet进行处理呢?

  在我们启动Tomcat的时候,连接器就会进行初始化监听所配置的端口号,这里我们配置的是8080端口对应的协议是HTTP。

    • 请求发送到本机的8080端口,被在那里监听的HTTP/1.1的连接器Connector获得
    • 连接器Connector将字节流转换为容器所需要的 ServletRequest对象给同级 Service下的容器模块Engine进行处理
    • Engine获得地址 http://localhost:8080/buxuewushu/add。匹配他下面的Host主机
    • 匹配到名为localhost的Host(就算此时请求为具体的ip,没有配置相应的Host,也会交给名为localhost的Host进行处理,因为他是默认的主机)
    • Host匹配到路径为 /buxuewushu的Context,即在webapp下面找到相应的文件夹
    • Context匹配到URL规则为*.do的servlet,对应为某个Servlet类
    • 调用其 doGet或者 doPost方法
    • Servlet执行完以后将对象返回给Context
    • Context返回给Host
    • Host返回给Engine
    • Engine返回给连接器Connector
    • 连接器Connector将对象解析为字节流发送给客户端

  

原文地址:https://www.cnblogs.com/JimmyThomas/p/12078736.html

时间: 2024-10-30 10:17:58

Tomcat系列(一)- 整体架构的相关文章

tomcat原理解析(二):整体架构

一 整体结构 前面tomcat实现原理(一)里面描述了整个tomcat接受一个http请求的简单处理,这里面我们讲下整个tomcat的架构,以便对整体结构有宏观的了解.tomat里面由很多个容器结合在一起,主要有server,service,context,host,engine,wrapper,connector这7个容器来组装.当然了tomcat里面还有其它容器这里就不一一列举,因为我只看重点的.这7个容器存着父子关系,即可以通过当前容器找自己的父容器和自己的子容器.说到这我画了一个简单的结

Flutter系列(三) 整体架构

您好,欢迎关注我的专栏,本篇是关于 Flutter 系列的第三篇,从简单的 Flutter 介绍开始,一步步带你了解进入 Flutter 的世界.你最好有一定的移动开发经验,如果没有也不要担心,在我的专栏底部给我留言,我会尽我的能力给你解答. 上篇文章我们介绍了用 Flutter 开发第一个跨平台应用程序,相信大家一定印象深刻,本篇文章介绍 Flutter 平台的整体架构. 一.核心原则 之前专栏有提到过,Flutter 的SDK中包括一个现代的响应式框架.一个2D渲染引擎.现成的widget和

Tomcat源码分析二:先看看Tomcat的整体架构

Tomcat源码分析二:先看看Tomcat的整体架构 Tomcat架构图 我们先来看一张比较经典的Tomcat架构图: 从这张图中,我们可以看出Tomcat中含有Server.Service.Connector.Container等组件,接下来我们一起去大致的看看这些组件的作用和他们之间的相互联系.在这之前,我们先补充一个知识点,也就是Tomcat它实现的功能点是什么呢?通过查找一些资料,这里参考下极客时间<深入拆解Tomcat_Jetty>中的总结,即Tomcat 要实现 2 个核心功能:

Tomcat是如何运行的?整体架构又是怎样的?

在许多的高端开发的岗位中都会或多或少有要求面试人员要研究过一些常用中间件源码.这是因为一切的秘密都是藏在源码中,阅读源码能够让我们对框架或者中间件的理解更加深刻,而我们也能够在源码的研究中获得其中一些优秀的设计方式.而我们的中间件和源码那么多,我们该从何入手呢?其实大部分的中间件或者框架都有一些共性的部分,例如网络编程.多线程.反射和类加载等技术.所以深入研究透了一两个中间件的话,那么再回过头来看其它的中间件,那么就会很容易理解它里面所用的技术以及原理.而作为一个老牌的WEB端框架Tomcat,

深入理解Tomcat系列之一:系统架构

前言 Tomcat是Apache基金组织下的开源项目,性质是一个Web服务器.下面这种情况很普遍:在eclipse床架一个web项目并部署到Tomcat中,启动tomcat,在浏览器中输入一个类似http://localhost:8080/webproject/anyname.jsp的url,然后就可以看到我们写好的jsp页面的内容了.一切都是那么自然和顺理成章,然而这一切都是源于tomcat带给我们的,那么在tomcat背后,这一切又是怎么样发生的呢?带着对tomcat工作原理的好奇心,我决定

【Spring源码深度解析系列 】Spring整体架构

一.Spring的整体架构和模块 二.模块分类: 1.Core Container Core Container包含有Core .Beans.Context.和Expression  Language模块 2.Data Access/Integration Data Access/Integration包含有JDBC.ORM.OXM.JMS和Transaction模块 3.Web Web层包含了Web.Web-Servlet.Web-Struts.Web-Porlet模块. 4.AOP 5.Te

修改android4.4图库系列四(五)——android4.4.2图库整体架构分析

到今天为止,修改了一个多月的android图库源码结束了!修改的具体内容就是将图库中原有的ActionBar干掉,然后自定义ActionBar.为了达到效果,自定义ActionBar的所有事件还必须与原有的ActionBar上的点击事件绑定.为此,必须要分析图库的整体架构.各个界面之间的转化关系,以及大部分类的作用. 修改后的效果图如下: 首先,不得不说,图库源码真的很强大,光本地的java代码就有500多个类,还有很多JNI代码.能从中学到很多的东西. 一.界面之间的转换 主要界面就三个:一个

【深入浅出jQuery】源码浅析--整体架构(转)

最近一直在研读 jQuery 源码,初看源码一头雾水毫无头绪,真正静下心来细看写的真是精妙,让你感叹代码之美. 其结构明晰,高内聚.低耦合,兼具优秀的性能与便利的扩展性,在浏览器的兼容性(功能缺陷.渐进增强)优雅的处理能力以及 Ajax 等方面周到而强大的定制功能无不令人惊叹. 另外,阅读源码让我接触到了大量底层的知识.对原生JS .框架设计.代码优化有了全新的认识,接下来将会写一系列关于 jQuery 解析的文章. 我在 github 上关于 jQuery 源码的全文注解,感兴趣的可以围观一下

【深入浅出jQuery】源码浅析--整体架构

最近一直在研读 jQuery 源码,初看源码一头雾水毫无头绪,真正静下心来细看写的真是精妙,让你感叹代码之美. 其结构明晰,高内聚.低耦合,兼具优秀的性能与便利的扩展性,在浏览器的兼容性(功能缺陷.渐进增强)优雅的处理能力以及 Ajax 等方面周到而强大的定制功能无不令人惊叹. 另外,阅读源码让我接触到了大量底层的知识.对原生JS .框架设计.代码优化有了全新的认识,接下来将会写一系列关于 jQuery 解析的文章. 我在 github 上关于 jQuery 源码的全文注解,感兴趣的可以围观一下