关于如何我们是如何访问Springboot服务器

记一次失败的面试经历中的面试题

你是怎么访问你项目中的端口的。这个访问请求时长连接的嘛？

我蒙了，不都是直接访问的嘛？应该是长连接吧，都http了

其实这些要追溯到Spring MVC时期，你还记得Tomcat嘛哈哈哈。

这里我们简单复习一下哈。

首先Springboot是一站式J2EE的解决？？？

内置的Servlet服务器其实就是Tomcat

功能组件

Tomcat 的核心功能有两个，分别是负责接收和反馈外部请求的连接器 Connector，和负责处理请求的容器 Container。

其中连接器和容器相辅相成，一起构成了基本的 web 服务 Service。每个 Tomcat 服务器可以管理多个 Service。

然后就是Service组件，这个组件目的就是对外提供Web服务，包含上面提到的两个核心组件和其他功能组件，并且Tomcat可以管理多个Service，它们之间相互独立。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pCSidV2o-1618465996683)(C:\Users\windows\AppData\Roaming\Typora\typora-user-images\image-20210414204920111.png)]

连接器功能：

1. 监听网络端口，接收和响应网络请求
2. 网络字节流处理，将收到的网络字节流转换成Tomcat Request再转成标准的ServletRequest给容器，同时将容器传来的 ServletResponse 转成 Tomcat Response 再转成网络字节流。

容器框架

每个 Service 会包含一个容器。容器由一个引擎可以管理多个虚拟主机。每个虚拟主机可以管理多个 Web 应用。每个 Web 应用会有多个 Servlet 包装器。Engine、Host、Context 和 Wrapper，四个容器之间属于父子关系。

容器请求处理

容器的请求处理过程就是在 Engine、Host、Context 和 Wrapper 这四个容器之间层层调用，最后在 Servlet 中执行对应的业务逻辑。各容器都会有一个通道 Pipeline，每个通道上都会有一个 Basic Valve（如StandardEngineValve）， 类似一个闸门用来处理 Request 和 Response 。其流程图如下。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-57DJoqkE-1618465996688)(C:\Users\windows\AppData\Roaming\Typora\typora-user-images\image-20210414205237064.png)]

Tomcat 请求处理流程

上面的知识点已经零零碎碎地介绍了一个 Tomcat 是如何处理一个请求。简单理解就是连接器的处理流程 + 容器的处理流程 = Tomcat 处理流程。哈！那么问题来了，Tomcat 是如何通过请求路径找到对应的虚拟站点？是如何找到对应的 Servlet 呢？

映射器功能介绍

这里需要引入一个上面没有介绍的组件 Mapper。顾名思义，其作用是提供请求路径的路由映射。根据请求URL地址匹配是由哪个容器来处理。其中每个容器都会它自己对应的Mapper，如 MappedHost。不知道大家有没有回忆起被 Mapper class not found 支配的恐惧。在以前，每写一个完整的功能，都需要在 web.xml 配置映射规则，当文件越来越庞大的时候，各个问题随着也会出现

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 中找映射关系，最后调用具体的函数。

那么回到最初的问题，我们知道了我们是如何通过浏览器访问到我们的服务器的，那么这个访问请求是长连接还是短连接？

其实Tomcat服务器的请求都是短连接的，因为它默认是短连接的。