Tomcat原理剖析

Tomcat原理剖析

系统架构

请求流程

  • HTTP 服务器接收到请求之后把请求交给Servlet容器来处理,Servlet 容器通过Servlet接⼝调⽤业务
    类。Servlet接⼝和Servlet容器这⼀整套内容叫作Servlet规范。
  • 注意:Tomcat既按照Servlet规范的要求去实现了Servlet容器,同时它也具有HTTP服务器的功能
  • Tomcat的两个重要身份
    • http服务器
    • Tomcat是⼀个Servlet容器

Tomcat Servlet容器处理流程

当⽤户请求某个URL资源时

  • HTTP服务器会把请求信息使⽤ServletRequest对象封装起来
  • 进⼀步去调⽤Servlet容器中某个具体的Servlet
  • 在 上一步中,Servlet容器拿到请求后,根据URL和Servlet的映射关系,找到相应的Servlet
  • 如果Servlet还没有被加载,就⽤反射机制创建这个Servlet,并调⽤Servlet的init⽅法来完成初始化
  • 接着调⽤这个具体Servlet的service⽅法来处理请求,请求处理结果使⽤ServletResponse对象封装
  • 把ServletResponse对象返回给HTTP服务器,HTTP服务器会把响应发送给客户端

Tomcat系统总体架构

通过上⾯的讲解,我们发现tomcat有两个⾮常重要的功能需要完成

  1. 和客户端浏览器进⾏交互,进⾏socket通信,将字节流和Request/Response等对象进⾏转换
  2. Servlet容器处理业务逻辑

Tomcat 设计了两个核⼼组件连接器(Connector)和容器(Container)来完成 Tomcat 的两⼤核⼼
功能。
连接器,负责对外交流: 处理Socket连接,负责⽹络字节流与Request和Response对象的转化;
容器,负责内部处理:加载和管理Servlet,以及具体处理Request请求;

Tomcat 连接器组件 Coyote

Coyote 是Tomcat 中连接器的组件名称 , 是对外的接⼝。客户端通过Coyote与服务器建⽴连接、发送请
求并接受响应 。

  1. Coyote 封装了底层的⽹络通信(Socket 请求及响应处理)
  2. Coyote 使Catalina 容器(容器组件)与具体的请求协议及IO操作⽅式完全解耦
  3. Coyote 将Socket 输⼊转换封装为 Request 对象,进⼀步封装后交由Catalina 容器进⾏处理,处
    理请求完成后, Catalina 通过Coyote 提供的Response 对象将结果写⼊输出流
  4. Coyote 负责的是具体协议(应⽤层)和IO(传输层)相关内容

在 8.0 之前 ,Tomcat 默认采⽤的I/O⽅式为 BIO,之后改为 NIO。 ⽆论 NIO、NIO2 还是 APR, 在性
能⽅⾯均优于以往的BIO。 如果采⽤APR, 甚⾄可以达到 Apache HTTP Server 的影响性能。

Coyote 组件及作⽤

组件 作⽤描述
EndPoint EndPoint 是 Coyote 通信端点,即通信监听的接⼝,是具体Socket接收和发送处理器,是对传输层的抽象,因此EndPoint⽤来实现TCP/IP协议的
Processor Processor 是Coyote 协议处理接⼝ ,如果说EndPoint是⽤来实现TCP/IP协议的,那么Processor⽤来实现HTTP协议,Processor接收来⾃EndPoint的Socket,读取字节流解析成Tomcat Request和Response对象,并通过Adapter将其提交到容器处理,Processor是对应⽤层协议的抽象
ProtocolHandler Coyote 协议接⼝, 通过Endpoint 和 Processor , 实现针对具体协议的处理能⼒。Tomcat 按照协议和I/O 提供了6个实现类 : Ajp NioProtocol ,Ajp AprProtocol, Ajp Nio2Protocol , Http11NioProtocol ,Http11Nio2Protocol ,Http11AprProtocol
Adapter 由于协议不同,客户端发过来的请求信息也不尽相同,Tomcat定义了⾃⼰的Request类来封装这些请求信息。ProtocolHandler接⼝负责解析请求并⽣成Tomcat Request类。但是这个Request对象不是标准的ServletRequest,不能⽤Tomcat Request作为参数来调⽤容器。Tomcat设计者的解决⽅案是引⼊CoyoteAdapter,这是适配器模式的经典运⽤,连接器调⽤CoyoteAdapter的Sevice⽅法,传⼊的是Tomcat Request对象, CoyoteAdapter负责将Tomcat Request转成ServletRequest,再调⽤容器

Tomcat Servlet 容器 Catalina

结构

Tomcat(我们往往有⼀个认识,Tomcat就是⼀个Catalina的实例,因为Catalina是Tomcat的核⼼)

Tomcat/Catalina实例

可以认为整个Tomcat就是⼀个Catalina实例,Tomcat 启动的时候会初始化这个实例,Catalina

实例通过加载server.xml完成其他实例的创建,创建并管理⼀个Server,Server创建并管理多个服务,

每个服务⼜可以有多个Connector和⼀个Container。

⼀个Catalina实例(容器)

⼀个 Server实例(容器)

多个Service实例(容器)

每⼀个Service实例下可以有多个Connector实例和⼀个Container实例

  • Catalina
    负责解析Tomcat的配置⽂件(server.xml) , 以此来创建服务器Server组件并进⾏管理
  • Server
    服务器表示整个Catalina Servlet容器以及其它组件,负责组装并启动Servlaet引擎,Tomcat连接
    器。Server通过实现Lifecycle接⼝,提供了⼀种优雅的启动和关闭整个系统的⽅式
  • Service
    服务是Server内部的组件,⼀个Server包含多个Service。它将若⼲个Connector组件绑定到⼀个
    Container
  • Container
    容器,负责处理⽤户的servlet请求,并返回对象给web⽤户的模块

Container 组件的具体结构

Container组件下有⼏种具体的组件,分别是Engine、Host、Context和Wrapper。这4种组件(容器)
是⽗⼦关系。Tomcat通过⼀种分层的架构,使得Servlet容器具有很好的灵活性。

  • Engine
    表示整个Catalina的Servlet引擎,⽤来管理多个虚拟站点,⼀个Service最多只能有⼀个Engine,
    但是⼀个引擎可包含多个Host
  • Host
    代表⼀个虚拟主机,或者说⼀个站点,可以给Tomcat配置多个虚拟主机地址,⽽⼀个虚拟主机下
    可包含多个Context
  • Context
    表示⼀个Web应⽤程序, ⼀个Web应⽤可包含多个Wrapper
  • Wrapper
    表示⼀个Servlet,Wrapper 作为容器中的最底层,不能包含⼦容器

源码剖析

源码追踪部分我们关注两个流程:Tomcat启动流程和Tomcat请求处理流程

Tomcat启动流程

Tomcat请求处理流程

  • 请求处理流程分析

  • 请求处理流程示意图

Tomcat 的类加载机制

Tomcat 的类加载机制相对于 Jvm 的类加载机制做了⼀些改变。

没有严格的遵从双亲委派机制,也可以说打破了双亲委派机制

⽐如:有⼀个tomcat,webapps下部署了两个应⽤

app1/lib/a-1.0.jar com.lagou.edu.Abc

app2/lib/a-2.0.jar com.lagou.edu.Abc

不同版本中Abc类的内容是不同的,代码是不⼀样的

  • 引导类加载器 和 扩展类加载器 的作⽤不变
  • 系统类加载器正常情况下加载的是 CLASSPATH 下的类,但是 Tomcat 的启动脚本并未使⽤该变
    量,⽽是加载tomcat启动的类,⽐如bootstrap.jar,通常在catalina.bat或者catalina.sh中指定。
    位于CATALINA_HOME/bin下
  • Common 通⽤类加载器加载Tomcat使⽤以及应⽤通⽤的⼀些类,位于CATALINA_HOME/lib下,
    ⽐如servlet-api.jar
  • Catalina ClassLoader ⽤于加载服务器内部可⻅类,这些类应⽤程序不能访问
  • Shared ClassLoader ⽤于加载应⽤程序共享类,这些类服务器不会依赖
  • Webapp ClassLoader,每个应⽤程序都会有⼀个独⼀⽆⼆的Webapp ClassLoader,他⽤来加载
    本应⽤程序 /WEB-INF/classes 和 /WEB-INF/lib 下的类。
  • tomcat 8.5 默认改变了严格的双亲委派机制
    • ⾸先从 Bootstrap Classloader加载指定的类
    • 如果未加载到,则从 /WEB-INF/classes加载
    • 如果未加载到,则从 /WEB-INF/lib/*.jar 加载
    • 如果未加载到,则依次从 System、Common、Shared 加载(在这最后⼀步,遵从双亲委派
      机制)