面试官：听说你很懂SpringMVC,那讲讲其内部对于请求的处理吧！

本系列文章皆在分析SpringMVC的核心组件和工作原理，让你从SpringMVC浩如烟海的代码中跳出来，以一种全局的视角来重新审视SpringMVC的工作原理.

思考，输出，沉淀。用通俗的语言陈述技术，让自己和他人都有所收获。

作者：毅航😜

在过去的很长一段时间内，笔者对SpringMVC中的核心控制器DispatcherServlet中doDispatch的处理逻辑进行了详细的分析，并以doDispatch的执行逻辑为切入点，详细的拆解了SpringMVC中的MultipartResolve(上传请求处理器)、HandlerMapping(处理器映射器)、HandlerInterceptor(拦截器)、HttpMessageConverter(消息转换器)等组件信息。更详细的内容可参考专栏：SpringMVC流程分析。

在专栏的前几章中我们主要介绍了SpringMVC内部在处理Http请求过程中会需要一些组件，毫无疑问这些组件在处理Http请求过程中发挥着至关重要的作用，但某种程度上来说其可能有一些太过于细节，读完后你可能只是搞懂了 SpringMVC中某些组件的作用以及作用的时机。 同时，你可能会面临这样一个问题，就是 似乎自己搞懂了很多SpringMVC的组件，但却很难将其串起来，仿佛每个知识都是孤立的。

针对这一问题，笔者今天想从更加宏观角度来谈一谈一个HTTP请求在SpringMVC内部处理的全过程。以方便读者更加深入理解专栏SpringMVC流程分析的内容，所以本文可以算作是对前几章内容的一个回顾和总结。

前言

在当下这个时代，我们每天都会借助浏览器浏览很多内容。但你是否有考虑过当你在浏览器中访问某一个网址时候，这背后都发生了那些事情呢？

事实上，当在浏览器中键入url后，其背后的处理逻辑可大致如下图所示：

可以看到，键入url后其大致会经历如下几个步骤：

DNS解析： 首先，浏览器会解析网址中的主机名，以获取服务器的IP地址。这个过程通过DNS（域名系统）完成。
建立TCP连接： 一旦浏览器知道了服务器的IP地址，它会尝试建立到服务器的TCP连接。通常这个过程会包括三次握手，以确保客户端和服务器之间的连接建立成功。
发送HTTP请求： 一旦TCP连接建立，浏览器会发送一个Http请求到服务器。这个请求包括了要访问的资源路径、HTTP方法（GET、POST等）、请求头（包含用户代理、接受的数据类型等）以及任何附加数据（例如，表单数据或请求体）。
服务器处理请求： 服务器收到HTTP请求后，会根据请求的路径和方法来确定如何处理请求。这通常涉及到后端应用程序的控制器 （例如，SpringMVC的Controller）处理请求，执行相应的业务逻辑。
生成HTTP响应,发送响应： 一旦服务器完成请求处理，它会生成一个Http响应。而这个响应通常包括:状态码、响应头以及响应体。
浏览器渲染： 浏览器接收到HTTP响应后，根据响应的内容类型（例如，HTML、CSS、JavaScript等）来渲染页面。

实际上Http请求的处理流程会涉及到很多复杂细节，笔者在此也只是做一个抛砖引玉的介绍，其主要目的也是在于让读者对于Http请求的大致处理过程有一个大致的认识。

简化`Http`请求的处理流程

虽然上述已经对Http请求的处理流程进行了极大的简化，但可能你还是会觉得上述对于Http请求处理的有些繁琐。那能不能对上述步骤再进行一层抽象，让其更容易理解呢？答案当然是肯定的！

基于此，我们对上图所示的Http请求处理流程进行再一次抽象，得到下图所示内容：

可以看到当对复杂事物进行抽象后，一切似乎好像开始变得简单了。接下来，我们大致来分析下图中的大致流程：

浏览器发起Http请求至中间件,这个中间件可以概括很多东西。比如：反向代理，路由跳转、网络分发等。
Http请求到达后端服务器Tomcat，其实你可以将Tomcat理解为一个接待请求Http请求的接待员，其主要负责统筹处理请求，而不是所有的事情都自己做。进一步，其会将处理逻辑委托给进程。

为了进一步方便理解，我们举一个网购的例子来分析Http请求处理的大致逻辑。首先，当我们在浏览器键入发起购物的Http请求后，这个Http请求在不丢包的前提下，最终会历经万水千山到达Tomcat；然后，Tomcat会将Http请求分发给专门管理订单的进程，并记录其对于某个商品的购买数量。此外，还需要告诉管理库存的进程，进行库存的扣减，同时，还要告诉支付的进程，应该支付的金额。最后，在将处理结果返回给浏览器进行解析。

可以看到Tomcat会将Http请求分发给专门的进程来处理Http请求，而具体到Java后端搭建的服务来看，其会将Http请求交给交给SpringMVC来进行处理。

其实讲了这么多，重点在于分析清楚Http请求是如何到达后端服务的；在此基础上，我们重点关注后端服务SpringMVC内部是如何来完成对Http请求的处理。

`SpringMVC`内部对于`Http`请求的处理

在开始分析之前，我们先来看看后端服务是如何来定义前端待访问的url的：

java 复制代码

@RestController
@RequestMapping("/demo")
public class HelloWorldController {

 @GetMapping(value="/say-hello")
 public String sayHello(){
     return "helloworld";
  }
}

观察上述代码你会发现，其主要做了如下工作：

定义了一个待访问的url信息，即暴露给前端的地址信息为/demo/say-hello；
该url的请求方式为Get方式；
url对应的处理逻辑为sayHello方法。

明白了这些后，不妨思考一个问题，如果你来处理前端传来的/demo/say-hello请求，你该如何处理？ 我想你的思路大致如下：

获取请求的url信息；
根据url信息获取对应的处理逻辑，具体到SpringMVC中即寻找url对应的方法信息；
处理请求中的参数信息，执行url中对应的方法，并将结果返回。

进一步，将上述逻辑翻译为代码即有如下内容：

java 复制代码

public class HttpRequestHandler {
    // 定义url信息和方法间的映射关系
    Map<RequestUrl， Method> mapper = new HashMap<>();
    
    /**
    * 处理前端传来的请求信息
    */
    public Object handle(HttpRequest httpRequest {
        // 获取前端传来的url信息
        RequestUrl requestKey = getRequestUrl(httpRequest);
        // 根据url信息获取对应的处理逻辑
        Method method = this.mapper.getValue(requesUrl);
       // 解析前端传递的参数信息
       Object[] args = resolveArgsAccordingToMethod(httpRequest， method);
       // 执行方法，将结果进行返回
      return method.invoke(controllerObject, args);
}

事实上，这也就是SpringMVC中处理Http请求的底层了逻辑。虽然上述代码中省略了很多方法的编写，但这并不影响理解。

熟悉了SpringMVC处理Http请求的底层逻辑后，我们再来进一步看看SpringMVC在处理Http请求时的具体细节。

`Http`请求从`Tomcat`转交到`SpringMVC`控制器

我们首先来看Tomcat内部是如何将对Http请求的处理权转交给SpringMVC的。

众所周知，对于 SpringBoot应用而言，其本身并不提供通信层的支持，它是依赖于 Tomcat、Jetty 等容器来完成通信层的支持。而在SpringBoot应用中Tomcat是如何被启动的我们在此便不再赘述了，具体可参考：一文讲透SpringBoot应用在内嵌Tomcat容器与外置容器下的启动原理。

进一步，当Tomcat启动后，此时遇到HTTP 请求访问，其会触发 Tomcat 底层提供的 NIO 通信来完成数据的接收，并最终将请求事件丢入线程池去处理，进而根据servlet-mapping配置的url-pater来选取对应的Servlet来进行处理。

这就是为什么使用SpringMVC时，需要将DispatcherServlet中的url-pattern改为/*拦截所有请求的原因。 而有关DispatcherServlet的相关介绍可参考：SpringMVC流程分析(二)：揭开DispatcherServlet的神秘面纱。

`SpringMVC`控制器对于请求的处理

进一步，当url请求到达DispatcherServlet后，最终会调用到其中的doDispatch方法。而这个方法我们之前曾具体分析过，其大致处理逻辑如下：

这个过程具体会涉及到哪些处理逻辑，在此我们在此就不再赘述了。但其总结来看无非完成如下逻辑：

分发，即根据请求寻找对应的执行方法。 这个过程主要涉及到url与处理器之间的匹配。这一过程中会涉及到的组件有：HandlerMapping(处理器映射器)、HandlerAdapter(处理器适配器)等。
执行，反射执行寻找到的执行方法。 这一过程的本质就是通过反射机制来调用被@ReqeustMapping标注的方法。

进一步，在SpringMVC流程分析(六)：为处理器进行合适的"适配"我们曾提到过："对于前端传来的url信息，最终会交由RequestMappingHandlerAdapter中的handleInternal来进行处理" 。更进一步，其本质会将方法反射执行的逻辑委托给ServletInvocableHandlerMethod来处理，其相关调用链如下：

(注：SpringMVC内部这块通过反射执行方法的逻辑相对来说还是比较复杂的，由于笔者自身水平有限，所以在之前分析中一笔带过，感兴趣的读者可私下自行其内部执行逻辑，笔者期待你的佳作~~~)

总结

最后，我们来回顾下本文的内容。首先，我们从Http请求的处理过程入手，详细讨论了Http请求处理的全过程。以此为基础，我们重点分析了在后端服务中Http请求在SpringMVC中处理的全过程。总结来看SpringMVC在处理前端传来的url请求时，主要完成了两项任务：

请求分发，即根据url寻找对应的处理器；
方法执行，即执行与对应url绑定的方法信息，并将执行结果返回到客户端。

进一步，SpringMVC内部对于Http请求的处理过程如下所示：

这张图是笔者从网上找的，上述的ViewResolver、View其实现在已经很少用了。更多的还是在处处理器上使用@RestController或者@ResponseBody注解，以指示返回的数据应该以JSON格式响应给客户端。而完成这一工作的组件即为我们之前介绍的HttpMessageConverter，有关HttpMessageConverter相关介绍可参考：SpringMVC流程分析(七)：HttpMessageConverter------SpringMVC中的消息转换。

其实细心的读者已经注意到了，笔者在介绍SpringMVC内部对于Http请求的处理逻辑时，并没有其他文章一样以上述这样为基础来向写流水账一样的告诉读者SpringMVC内部处理Http请求会经历那些过程，然后使用那些组件。

这样的介绍在笔者看来其只是告诉了一个零散的知识点，即SpringMVC内部对于Http请求的处理 。而这与你之前学到的知识是割裂的，其相互无法产生直接的联系。这导致最直接的后果就是你一直在不断的学习，看似学了很多但其实很多时候其实都在做无用功。

所以笔者更希望在介绍知识时能将当前知识点与之前所需知识串联起来，进而将零碎的知识点串联起来，这样才能授人以鱼的同时授人以渔，进而当日后遇到相似问题时也才能举一反三。

如果觉得笔者文章对你很有启发的话，不妨点赞、收藏、关注三连走起，以免错过日后的每一次更新。

面试官：听说你很懂SpringMVC,那讲讲其内部对于请求的处理吧！

前言

简化Http请求的处理流程

SpringMVC内部对于Http请求的处理

Http请求从Tomcat转交到SpringMVC控制器

SpringMVC控制器对于请求的处理

总结

简化`Http`请求的处理流程

`SpringMVC`内部对于`Http`请求的处理

`Http`请求从`Tomcat`转交到`SpringMVC`控制器

`SpringMVC`控制器对于请求的处理