整体架构

image.png

Service

对外提供Web服务, 主要包含连接器和容器, 以及其他的功能组件. Tomcat可以管理多个Service, 各个Service之间相互独立

Connector

负责对外接受反馈请求. 是Tomcat与外界的交通枢纽, 监听端口接受外界请求, 将处理后的请求传递给容器做业务处理, 将处理后的结果反馈给外界

连接器框架—Coyote(草原狼)

功能:

  1. 监听网络端口, 接受和响应网络请求
  2. 网络字节流处理
    1. 网络字节流->Tomcat Request->ServletRequest
    2. ServletResponse->Tomcat Response->网络字节流

image.png

ProtocolHandler

协议处理器. 将不同的协议和通信方式组合封装成对应的协议处理器, Http11NioProtocol就是Http+Nio

Endpoint

端点. 处理Socket接受和发送的逻辑.包括如下组件

  1. Acceptor监听请求
  2. Handler处理请求

  3. AsyncTimeout检查请求超时

    Processor

    处理器. 负责构建Tomcat Request和Tomcat Response对象

    Adapter

    适配器. 实现Tomcat Request->ServletRequest和Tomcat Response->ServletResponse的转换. 采用经典的适配器设计模式

    Container

    负责对内业务逻辑处理. 内部由Engine, Host, Context, Wrapper四个容器组成, 管理和调用Servlet逻辑

    核心框架—Catalina

    每一个Service都有一个容器, 一个容器由一个Engine管理多个Host, 每个Host管理多个Web应用, 每个Web应用有多个Servlet封装器.
    image.png

  4. Engine: 引擎 管理多个Host

  5. Host: 虚拟主机 负责Web应用的部署
  6. Context: Web应用 包含多个Servlet封装器
  7. Wrapper: 封装器, 最底层, 对Servlet封装, 负责实例的创建, 执行和销毁功能

容器处理过程如下
image.png
每一个组件中都有一个Valve来处理Request和Response, 图片中错误

Tomcat的处理请求=连接器处理流程+容器的处理流程

Tomcat的请求流程

Mapper—请求路径匹配对应的虚拟站点

提供请求路径的路由映射, 根据URL地址匹配哪个容器处理. 每个Container都有自己Mapper.

HTTP请求流程

打开 tomcat/conf 目录下的 server.xml 文件来分析一个http://localhost:8080/docs/api 请求。 第一步：连接器监听的端口是8080。由于请求的端口和监听的端口一致，连接器接受了该请求。 第二步：因为引擎的默认虚拟主机是 localhost，并且虚拟主机的目录是webapps。所以请求找到了 tomcat/webapps 目录。 第三步：解析的 docs 是 web 程序的应用名，也就是 context。此时请求继续从 webapps 目录下找 docs 目录。有的时候我们也会把应用名省略。 第四步：解析的 api 是具体的业务逻辑地址。此时需要从 docs/WEB-INF/web.xml 中找映射关系，最后调用具体的函数。