개요

• DispatcherServlet 클래스의 doDispatch가 세부적으로 어떻게 동작하는지 확인합니다.
• 일반적인 API 서버 기준의 @RestController, @RequestMapping 애너테이션을 활용했습니다. HTTP 요청의 흐름을 따라갑니다.
  • 인자와 반환 타입에 대한 경우의 수는 고려하지 않았습니다.
  • 큰 흐름에서 바라보기에 MultiPart, Async 관련 세부사항은 생략합니다.
• 스프링부트 버전은 2.6.11입니다.
• 텍스트로만 이뤄져 있어 가독성이 떨어집니다 😂 김영한님 스프링 강의에서 제공되는 MVC 구조 이미지와 함께 보시면 좋습니다(아래 이미지의 순서 번호와 본문의 문단 번호는 관련이 없습니다).

https://www.inflearn.com/course/스프링-mvc-1# 강의 내용 중 일부 발췌 (이미지 사용 허가 완료)

1. DispatcherServlet에 들어오기 전까지

• ThreadPoolExecutor가 HTTP 요청을 처리하기 위한 새로운 워커 스레드(Worker)를 실행시킵니다.
• 워커 스레드는 함수형 인터페이스 Runnable → SocketProcessorBase를 상속하는 NioEndpoint.SocketProcessor 클래스의 doRun()을 호출합니다.
  • 내부적으로 소켓을 다룹니다. (세부사항은 생략합니다, 추후 자세하게 다룰 (수 있다면 다룰) 예정입니다)
• Filter을 순회하며 지정된 동작들을 처리합니다.

  • Filter를 순회시키는 역할은 ApplicationFilterChain 클래스의 doFilter()가 수행합니다.

    *Invoke the next filter in this chain, passing the specified request and response. If there are no more filters in this chain, invoke the service() method of the servlet itself. 체인의 다음 필터를 호출해 지정된 요청과 응답을 전달합니다. 더 이상 필터가 없으면 서블릿 자체의 service() 메서드를 호출합니다.

    • ApplicationFilterChain.doFilter(..) 주석*

  • 스프링에서 제공하는 CharacterEncodingFilter, WebMvcMetricsFilter, FormContentFilter, RequestContextFilter 등을 순회하며 동작을 수행합니다.

  • 스프링 시큐리티 관련 필터들을 순회하며 동작을 수행합니다.

  • 개발자가 커스텀하게 적용한 필터들을 순회하며 동작을 수행합니다.

• 필터 체인의 순회를 마치면 HttpServlet.service()를 실행해 DispatcherServlet으로 흐름이 넘어갑니다.
  • HTTP Method에 해당되는 메서드들을 호출합니다. → ex) doGet(req, resp), doHead(req, resp), doPost(req, resp), doPut(req, resp) 등
  • FrameworkServlet.processRequest(request, response) 내에서 DispatcherServlet.doService(..)를 호출하며, 내부에서 doDispatch(..)가 실행됩니다.

2. DispatcherServlet.doDispatch(..)의 실행 흐름

1. DispatcherServlet.getHandler(request) 메서드를 호출해 현재 요청에 대해 적합한 핸들러를 결정합니다.
   • 매핑할 핸들러의 목록은 HandlerMapping 타입 배열에 저장되어 있으며, 이를 순회하며 적합한 핸들러를 탐색합니다.
   • 핸들러 탐색 작업이 끝납니다. getHandler(..) 메서드는 위 작업들을 통해 생성된 HandlerExecutionChain을 반환합니다.
     • 만약 발견된 핸들러가 없다면 noHandlerFound()를 호출해 HttpServletResponse.SC_NOT_FOUND → 404를 반환합니다.
2. 핸들러를 결정했으니 핸들러 어댑터를 결정해야겠죠. DispatcherServlet.getHandlerAdapter(..)를 호출합니다.
   • 핸들러와 마찬가지로 HandlerAdapter를 가지는 배열인 handlerAdapters 인스턴스 변수가 DispatcherServlet 내에 존재합니다. 이를 순회하며 어댑터들은 HandlerAdapter.supports()를 호출해 발견한 핸들러의 지원 여부를 확인합니다.

     • supports() 메서드는 발견된 핸들러가 HandlerMethod 타입인지 확인합니다. 이후 supportsInternal(..)를 호출하는데 이땐 항상 true를 반환합니다. 이유는 주석에 적혀있습니다.

       *Always return true since any method argument and return value type will be processed in some way. A method argument not recognized by any HandlerMethodArgumentResolver is interpreted as a request parameter if it is a simple type, or as a model attribute otherwise. A return value not recognized by any HandlerMethodReturnValueHandler will be interpreted as a model attribute.

       메서드 인수 및 반환 값 타입은 어떤 방식으로든 처리되므로 항상 true를 반환합니다. 어떤 HandlerMethodArgumentResolver에서도 인식되지 못하는 메서드 인수가 단순한 타입이면 request parameter로 해석되고 그렇지 않다면 modelAttribute 특성으로 해석됩니다. HandlerMethodReturnValueHandler에서 인식하지 못하는 반환 값은 model attribute 특성으로 해석됩니다.*

   • 위 과정을 거쳐 HandlerAdapter도 결정됩니다.
3. 요청의 HTTP Method가 GET, HEAD 이라면 Last-Modified 헤더 관련 처리를 수행합니다. (Mozilla - ‘HTTP Headers → Last-Modified’)
   • 세부사항은 생략합니다.
4. HandlerExecutionChain.applyPreHandler(..)를 호출해 체인 내에 등록된 인터셉터의 preHandle, afterCompletion 메서드를 실행합니다.
   • 체인 내의 HandlerInterceptor를 담은 배열인 interceptorList을 순회하며 preHandle 메서드를 호출해 afterCompletion 메서드 호출 여부를 결정합니다.
   • 만약 preHandle에서 true가 반환되면 triggerAfterCompletion(..)를 호출해 인터셉터의 afterCompletion()를 호출합니다.