Web容器处理Http请求流程分析

Alleria Windrunner 2020-11-02

670

之前的两篇我们介绍完了SpringMvc处理Web请求的流程，但是SpringMvc毕竟只是个框架，一次Web请求或者说Http请求到底是怎么到我们的SpringMvc中的？你难道不想知道？本篇让我们一起来揭开这个神秘的面纱。

网络小知识

首先我们要来看一下一次Http请求在底层网络层面是怎么回事，具体示意图如下：

我们的Http请求从客户端到服务器就像上图一样网络包要经过这样的处理，我们的Web容器会监听Web应用的端口，然后拿到请求报文，然后丢给SpringMvc去处理。那么网络这一块我们就算说完了。接下来我们仔细看一下Web容器，这里以Tomcat为例。

Tomcat的体系结构

Tomcat是一个Web应用服务器，同时也是一个Servlet/JSP容器。Tomcat作为Servlet容器，负责处理客户端请求，把请求传送给Servlet，并将Servlet的响应返回给客户端。

server.xml文件源代码如下：

<?xml version="1.0" encoding="UTF-8"?>
<!--顶层类元素，可以包含多个Service-->
<Server port="8005" shutdown="SHUTDOWN">  
  <Listener className="org.apache.catalina.startup.VersionLoggerListener" >
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" >
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" >
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" >
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" >
  <GlobalNamingResources>
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml" >
  </GlobalNamingResources>
  <!--顶层类元素，可包含一个Engine（container），多个connector-->
  <Service name="Catalina">
  <!--连接器类元素，代表通信接口-->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" >
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" >
    <!--容器类元素，为特定的service组件处理客户请求-->
    <Engine name="Catalina" defaultHost="localhost">
        <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
               resourceName="UserDatabase"/>
        </Realm>
        <!--容器类元素，为特定的虚拟主机组件处理客户请求-->
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true">
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t "%r" %s %b" >
      </Host>
    </Engine>
  </Service>
</Server>

从这个配置文件我们可以抽象出Tomcat的体系结构如下：

由上图可以看出Tomcat的心脏是两个核心组件：Connector和Container。其中一个Container可以选择多个Connector。

Tomcat的两个核心组件

Connector

一个Connector组件将在某个指定的端口上侦听客户请求，接收浏览器发过来的tcp连接请求，创建一个Request和一个Response对象分别用于交换数据，然后会产生一个线程来处理这个请求并把产生的Request和Response对象传给Engine，从Engine中获得响应并返回给客户端。Tomcat有两个经典的Connector，一个直接侦听来自浏览器的HTTP请求，另外一个侦听来自其他的WebServer的请求。Cotote HTTP/1.1 Connector在端口8080处侦听来自客户浏览器的HTTP请求，Coyote JK2 Connector在端口8009处侦听其他WebServer的Servlet/JSP请求。Connector 最重要的功能就是接收连接请求然后分配线程让 Container来处理这个请求，所以这必然是多线程的，多线程的处理是 Connector 设计的核心。

Containtner

Container是容器的父接口，该容器的设计用的是典型的责任链的设计模式，它由四个自容器组件构成，分别是Engine、Host、Context、Wrapper。这四个组件是负责关系，存在包含关系。通常一个Servlet class对应一个Wrapper，如果有多个Servlet则定义多个Wrapper，如果有多个Wrapper就要定义一个更高的Container，如Context。Context定义在父容器 Host 中，其中Host 不是必须的，但是要运行 war 程序，就必须要 Host，因为 war 中必有 web.xml 文件，这个文件的解析就需要 Host 了，如果要有多个 Host 就要定义一个 top 容器 Engine 了。而 Engine 没有父容器了，一个 Engine 代表一个完整的 Servlet 引擎。

Engine 容器比较简单，它只定义了一些基本的关联关系 Host 容器。

Host 是 Engine 的子容器，一个 Host 在 Engine 中代表一个虚拟主机，这个虚拟主机的作用就是运行多个应用，它负责安装和展开这些应用，并且标识这个应用以便能够区分它们。它的子容器通常是 Context，它除了关联子容器外，还有就是保存一个主机应该有的信息。

Context 代表 Servlet 的 Context，它具备了 Servlet 运行的基本环境，理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。Context 最重要的功能就是管理它里面的 Servlet 实例，Servlet 实例在 Context 中是以 Wrapper 出现的，还有一点就是 Context 如何才能找到正确的 Servlet 来执行它呢？Tomcat5 以前是通过一个 Mapper 类来管理的，Tomcat5 以后这个功能被移到了 request 中，在前面的时序图中就可以发现获取子容器都是通过 request 来分配的。

Wrapper 代表一个 Servlet，它负责管理一个 Servlet，包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器，它没有子容器了，所以调用它的 addChild 将会报错。Wrapper 的实现类是 StandardWrapper，StandardWrapper 还实现了拥有一个 Servlet 初始化信息的 ServletConfig，由此看出 StandardWrapper 将直接和 Servlet 的各种信息打交道。

除了上述组件外，Tomcat中还有其他重要的组件，如安全组件security、logger日志组件、session、mbeans、naming等其他组件。这些组件共同为Connector和Container提供必要的服务。

Tomcat处理一个Http请求

介绍完这些让我们一起来看一下Tomcat Server如何处理一个HTTP请求。示意图和步骤如下：

用户在浏览器中输入网址localhost:8080/test/index.jsp，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得；
Connector把该请求交给它所在的Service的Engine（Container）来处理，并等待Engine的回应；
Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host；
Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机），名为localhost的Host获得请求/test/index.jsp，匹配它所拥有的所有Context。Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为“ ”的Context去处理）；
path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。Context匹配到URL Pattern为*.jsp的Servlet，对应于JspServlet类；
构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet()或doPost(),执行业务逻辑、数据存储等；
Context把执行完之后的HttpServletResponse对象返回给Host；
Host把HttpServletResponse对象返回给Engine；
Engine把HttpServletResponse对象返回Connector；
Connector把HttpServletResponse对象返回给客户Browser。

数据库

文章转载自Alleria Windrunner，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Web容器处理Http请求流程分析

评论