Spring DispatcherServlet(디스패처서블릿) 개념부터 동작 과정까지

🔗 DispatcherServlet

안녕하세요, 이번 포스팅에서는 Spring에서 HTTP 요청 및 응답과 관련하여 가장 핵심 기술인 DispatcherServlet에 대해 살펴보고자 합니다.

 

평소에 개념에 대해서는 어느 정도 알고 있었지만 어떠한 과정을 통해 디스패처 서블릿이 클라이언트의 요청을 받고, 메서드의 파라미터 정보를 처리하고 응답을 반환하는지 내부 동작은 잘 몰랐었는데요, 이번 기회에 정리해 보았습니다.

(틀린 내용이 존재할 수 있으니 말씀해 주시면 감사하겠습니다. 🙏)

---

| DispatcherServlet 개념

프론트 컨트롤러(Front Controller)라고도 불리는 DispatcherServlet은 HTTP 프로토콜로 들어오는 모든 요청을 먼저 받아서 적합한 컨트롤러에 위임(Delegate request)는 역할을 합니다.

(아래이미지에서 Front controller 부분을 DispatcherServlet이라고 생각하면 됩니다.)

https://docs.spring.io/spring-framework/docs/3.0.0.M4/spring-framework-reference/html/ch15s02.html

 

 

| DispatcherServlet 장점

과거 DispatcherServlet이 등장하기 전에는 모든 서블릿에 대해 URL을 매핑하기 위해 관련 설정을 해주어야 하는 번거로움이 존재했습니다. (web.xml 파일) >> 댓글 참고 바랍니다. 🙏

 

그러나 DispatcherServlet이 등장한 이후에는 DispatcherServlet이 모든 요청을 먼저 받아서 직접 적합한 컨트롤러로 위임을 해주기 때문에 위와 같은 작업은 필요없어졌고, 이로 인해 개발이 굉장히 편리해졌습니다.

 

개발자의 입장에서 굉장히 편리해진 만큼 DispatcherServlet의 내부 코드는 굉~장히 추상화가 되어있고 복잡한데요, 어떠한 과정을 거쳐 위와 같은 마법(?)을 부리게 해주는지 살펴보겠습니다.

 

 

| DispatcherServlet 동작 과정

https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/en/Overview/SpringMVCOverview.html#overview-of-spring-mvc-processing-sequence

DispatcherServlet의 동작 과정에 대해 조금 더 자세히 살펴보면 다음과 같습니다.

1. DispatcherServlet이 클라이언트의 모든 요청을 받습니다.
2. 요청 정보에 대해 HandlerMappinng에 위임하여 처리할 Handler(Controller)을 찾습니다.
3. 2번에서 찾은 Handler을 수행할 수 있는 HandlerAdapter를 찾습니다.
4. HandlerAdapter는 Controller에 비즈니스 로직 처리를 호출합니다.
5. Controller는 비즈니스 로직을 수행하고, 처리 결과를 Model에 설정하며 HandlerAdapter에 view name을 반환합니다.
   • 모델을 반환하면 View가 렌더링이 되고, 그렇지 않은 경우(ex. @RestController 등) View가 렌더링이 되지 않습니다. 
6. 5번에서 반환받은 view name을 ViewResolver에게 전달하고, ViewResolver은 해당하는 View 객체를 반환합니다.
7. DispatcherServlet은 View에게 Model을 전달하고 화면 표시를 요청합니다.
8. 최종적으로 서버의 응답을 클라이언트에게 반환합니다.

 

 

🔗 DispatcherServlet 내부 코드

DispatcherServlet의 내부 코드를 살펴보면 Spring 팀에서 개발한 여러 디자인 패턴이 존재합니다.

아래 패턴들은 전부 코드에서 나오는 개념들이니 간략히 살펴보시고 해당 포스팅을 보시면 이해하시기에 보다 수월할 듯 합니다. 😅

• 어댑터 패턴
• 템플릿 메서드 패턴
• 전략 패턴
• 컴포지트 패턴

---

자 그럼 길고도 긴 DispatcherServlet 내부 속으로의 여정을 떠나 보겠습니다..

 

DispatcherServrlet은 Spring MVC의 핵심 요소로 위 사진과 같은 계층 구조를 가지고 있습니다.

(DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet -> GenericServlet -> Servlet)

 

Servlet

• Servlet은 웹 서버 내에서 실행되는 자바 프로그램입니다.
• HTTP 통신을 사용하여 웹 클라이언트로부터 요청을 받고 응답하는 기술입니다.
• 일반적인 서블릿을 상속하는 GenericServlet, HTTP 서블릿을 상속하는 HttpServlet이 존재합니다.
• 서블릿의 생명주기 - init(), service(), destory()
• Servlet에 대한 추가적인 내용은 해당 포스팅을 참고해 주세요.

GenericServlet

• 프로토콜에 독립적인 일반 서블릿입니다.
• 웹에서 사용할 HTTP 서블릿을 작성하려면 HttpServlet을 상속받습니다.

HttpServlet

• 웹 사이트에 적합한 HTTP 서블릿 입니다.
• HttpServlet의 하위 클래스는 아래 메서드 중 최소 하나의 메서드는 재정의를 해야 합니다.
  • doGet(), doPost(), doPut(), doDelete()
  • init(), destory(): 서블릿 라이프 사이클의 초기화 및 파기
  • getServletInfo(): 서블릿에 대한 정보

HttpServletBean

• HttpServlet의 단순 확장 클래스로 Spring이 구현한 모든 서블릿 유형에 적합한 서블릿 (spring 패키지)

FrameworkServlet

• 스프링 웹 프레임워크의 기본 서블릿입니다.
• 하위 클래스는 요청을 처리하기 위해 doService() 메서드를 구현해야 합니다.

DispatcherServlet

• HTTP 요청을 처리하는 중앙 집중형 Dispatcher (Front-Controller)
• 적절한 어댑터 클래스를 통해 어떠한 workflow와도 사용이 가능할 만큼 매우 유연합니다.
• Mapping, Adapter, Exception 관련 클래스는 다음과 같습니다.
  • HandlerMapping - RequestMappingHandlerMapping
  • HandlerAdapter - RequestMappingHandlerAdapter
  • HandlerExceptionResolver - ExceptionHandlerExceptionResolver

 

실제로 클라이언트의 요청을 DispatcherServlet이 받아서 처리하는 과정을 하나씩 보겠습니다.

(API 정보, 클래스 및 메서드 정보, 쿼리 파라미터 등등)

 

예제에 사용될 간단한 API는 다음과 같고, 호출 URI는 '/test?name=juhyun' 입니다.

 

DispatcherServlet이 요청을 받아서 처리하는 과정을 크게 살펴보면 다음과 같습니다.

1. HttpServlet: 서블릿의 Request/Response를 HttpServlet의 Request/Response로 변환

2~5. FrameworkServlet: 클라이언트 요청의 Http Method에 따라 분기 처리 - doXXX 메서드

6. DispatcherServlet: 요청 정보에 대해 이를 처리할 Handler를 찾고, HandlerAdapter를 통해 Controller에 요청 위임

    6-1. 요청에 매핑되는 HandlerMapping(HandlerExecutionChain) 조회

    6-2. Handler을 수행할 수 있는 HandlerAdapter 조회

    6-3. HandlerAdapter를 통해 실제 Controller의 비즈니스 로직 호출

 

1. HttpServlet: Servlet의 Request, Response를 HttpServlet의 Request,Response로 변환

• HttpServlet.service()

HttpServlet

먼저 클라이언트의 요청은 DispatcherServlet의 부모 추상 클래스인 HttpServlet의 service() 메서드에서 요청을 받습니다.

위 코드의 13, 14라인에서 서블릿의 요청 및 응답을 HttpServlet의 요청 및 응답으로 변환합니다.

 

이후 18번째 라인의 service() 메서드는 FrameworkServlet 추상 클래스에서 오버라이드된 service() 메서드를 호출합니다.

위 req, res는 Facade 클래스이며 HttpServletRequest, HttpServletResponse 인터페이스를 구현하기 때문에 변환이 가능합니다. 

 

2. FrameworkServlet: HTTP 메서드에 따라 분기 처리

• HttpServlet.service() -> FrameworkServlet.service()

FrameworkServlet

Http Method가 PATCH일 경우 processRequest() 메서드를 호출하고, 그 외의 메서드는 14라인의 super.service() 메서드를 호출합니다. (super = HttpServlet)

 

아래에서 살펴보겠지만 doXXX 메서드에서 doPatch() 라는 메서드만 유일하게 존재하지 않는데요, 이유는 다음과 같다고 합니다.

Servlet api 3.0을 정의한 JSR 315에서 patch 메서드에 대해 인식하지 못했기 때문에 doPatch() 메서드를 구현하지 못했고, 이후 PATCH 메서드가 HTTP 프로토콜에 추가되면서 Spring 패키지에 속하는 FrameworkServlet 클래스에서 분기 처리를 통해 Http Method가 PATCH인 케이스와 그 외의 케이스를 구분하여 처리하도록 대응했습니다.
- https://stackoverflow.com/questions/47080677/java-httpservlet-patch-method

현재 요청한 Http Method는 GET이므로 14라인의 super.service() 메서드를 호출하여 다시 HttpServlet 클래스의 service() 메서드를 호출합니다.

 

3. HttpServlet: service()

• HttpServlet.service() -> FrameworkServlet.service() -> HttpServlet.service()

HttpServlet

HttpServlet 추상 클래스의 service() 메서드는 Http Method에 따라 doXXX 메서드를 호출합니다.

실제 호출은 HttpServlet 클래스를 상속받고, doXXX 메서드를 오버라이딩하고 있는 자식 클래스의 doXXX 메서드입니다.

(여담이지만 위 lastModified 값은 항상 -1인데, 따로 분기 처리를 해놓은 이유가 궁금하네요.. 🧐)

 

HttpServlet 추상 클래스에서 템플릿을 제공하고, 실제 비즈니스 로직은 이를 상속받는 FrameworkServlet에서 구현되어 있는데요, 이는 디자인 패턴에서 템플릿 메서드 패턴이 적용되었음을 확인할 수 있습니다.

 

4. FrameworkServlet: doXXX() -> processRequest() -> doService()

• HttpServlet.service() -> FrameworkServlet.service() -> HttpServlet.service() -> FrameworkServlet.doXXX(), processRequest(), doService()

FrameworkServlet

자식 클래스에서 오버라이딩된 doXXX 메서드는 위와 같이 모두 processRequest() 메서드를 호출하도록 되어있습니다.

 

FrameworkServlet

FrameworkServlet 추상 클래스의 processRequest() 메서드에서 핵심 로직은 7번째 라인의 doService() 입니다.

doService() 메서드가 드디어 DispatcherServlet 클래스를 호출하는 진입점입니다!

 

그럼 DispatcherServlet의 doService() 메서드에서는 어떠한 과정이 일어나는지 살펴보겠습니다.

 

5. DispatcherServlet: doService()

• HttpServlet.service() -> FrameworkServlet.service() -> HttpServlet.service() -> FrameworkServlet.doXXX(), processRequest(), doService() -> DispatcherServlet.doService(), doDispatch()

doService() 메서드에서는 Request에 대해 log를 남기고, 복원할 수 있도록 요청 정보에 대해 snapshot을 남기는 등 로직이 존재하지만, 핵심 로직은 아니기 때문에 패스하겠습니다.

 

해당 메서드에서 가장 중요한 부분은 16번째 라인의 doDispatch() 메서드인데요, 이 함수에서 아래의 작업을 진행합니다.

• 요청에 매핑되는 HandlerMapping(HandlerExecutionChain) 조회
• Handler을 수행할 수 있는 HandlerAdapter 조회
• HandlerAdapter를 통해 Controller 호출 (실제 로직)

DispatcherServlet.doDispatch()
  - Process the actual dispatching to the handler.
  - The handler will be obtained by applying the servlet's HandlerMappings in order. The HandlerAdapter will be obtained by querying the servlet's installed HandlerAdapters to find the first that supports the handler class.
  - All HTTP methods are handled by this method. It's up to HandlerAdapters or handlers themselves to decide which methods are acceptable.

https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/en/Overview/SpringMVCOverview.html#overview-of-spring-mvc-processing-sequence

 

6. DispatcherServlet: doDispatch() - HandlerMapping, HandlerAdapter, Handle Controller

• HttpServlet.service() -> FrameworkServlet.service() -> HttpServlet.service() -> FrameworkServlet.doXXX(), processRequest(), doService() -> DispatcherServlet.doService(), doDispatch() - HandlerMapping, HandlerAdapter, handle Controller

doDispatch() 메서드는 위에서 말씀드렸듯이 세 가지 핵심 작업을 진행 합니다.

• 18 라인: HandlerMapping(HandlerExecutionChain) 조회
• 26라인: Handler을 수행할 HandlerAdapter 조회
• 45라인: HandlerAdapter를 통해 Controller의 실제 로직 호출

 

6-1. 요청에 매핑되는 HandlerMapping(HandlerExecutionChain) 조회

DispatcherServlet

HandlerExecutionChain은 HandlerMethod, Interceptor들로 구성되어 HandlerMapping에 해당하는 클래스 입니다.

HandlerExecutionChain
 - Handler execution chain, consisting of handler object and any handler interceptors.
 - Returned by HandlerMapping's HandlerMapping.getHandler method.

DispatcherServlet이 HandlerExecutionChain 객체를 얻는 이유는 doDispatch() 메서드에 등록된 
인터셉터를 처리 하는 로직이 존재하기 때문입니다.(applyPreHandle, applyPostHandle)

위 코드에서 5번 라인의 mapping.getHandler(request) 메서드를 내부로 계속 들어가보겠습니다.

(DispatcherServlet.getHandler() -> AbstractHandlerMapping.getHandler() -> RequestMappingInfoHandlerMapping.getHandlerInternal() -> AbstractHandlerMethodMapping.getHandlerInternal())

getHandler() 메서드를 계속 타고 들어가보면 AbstractHandlerMethodMapping 추상 클래스의 getHandlerInternal() 메서드에서 HandlerMethod를 찾고, AbstractHandlerMapping 추상 클래스에서 HandlerExecutionChain 객체를 생성하여 리턴하는 것을 확인할 수 있습니다.

• lookupPath: URI
• mappingRegistry: 매핑 정보를 관리하는 클래스
• handlerMethod: bean, beanFactory, Controller의 method 정보 등

 

이제 빠져나와서 AbstractHandlerMapping.getHandler() 부분을 살펴 보겠습니다.

getHandlerInternal() 메서드를 수행한 후 handler의 타입은 HandlerMethod 이고, 수행될 수 있는 인터셉터들을 포함하여 getHandlerExecutionChain() 메서드를 통해 HandlerExecutionChain 객체를 생성합니다. (13라인, 22라인 ~)

 

위와 같은 과정을 통해 HandlerMapping을 찾고, HandlerExecutionChain 객체를 생성하여 반환합니다.

다음으로 HandlerExecutionChain을 통해 HandlerAdapter를 찾는 과정을 살펴보겠습니다.

 

 

6-2. Handler을 수행할 수 있는 HandlerAdapter 조회 (28번째 라인)

getHandlerAdapter(): HandlerExecutionChain를 통해 HandlerAdapter를 찾습니다.

예제 코드에서 작성했던 @GetMapping 어노테이션 내부에 @RequestMapping 어노테이션이 존재하기 때문에 위의 for문에서는 RequestMappingHandlerAdapter 어댑터를 반환합니다.

(네이밍만 봐도 클래스의 역할이 유추가 가능하네요,, Spring 역시 대단하네요.. 🙏)

 

또한 위에서 handler은 HandlerMethod로 매핑되는 컨트롤러의 메서드 및 빈, 빈 팩토리 등이 저장되어 있습니다.

 

 

6-3. HandlerAdapter를 통해 실제 Controller의 비즈니스 로직 호출 (40번째 라인)

6-1, 6-2에서 HandlerExecutionChain, HandlerAdapter를 찾는 과정을 살펴보았습니다.

(두 과정도 복잡했지만 이번 6-3 과정이 더 복잡합니다...😭)

 

마지막으로 HandlerAdapter를 통해 실제 Controller의 로직을 실행하는(invoke) 과정을 살펴보겠습니다.

HandlerAdapter가 Controller를 실행하여 결과를 얻는 과정은 많이 복잡하기 때문에 많은 인내심(?)이 필요합니다... 😂

 

HandlerAdapter의 handle() 메서드를 타고 들어가 보겠습니다. 

RequestMappingHandlerAdapter 클래스의 handleInternal() 메서드에서 Controller를 호출하는 로직이 존재합니다. (invokeHandlerMethod())

 

그래서 invokeHandlerMethod() 메서드의 내부는 ..?

RequestMappingHandlerAdapter (이제 거의 다 왔습니다....)

invokeHandlerMethod 함수에서 살펴볼 부분은 크게 두 가지 입니다.

• 10번째 라인: ServletInvocableHandlerMethod invocableMethod = createInvocableHandlerMethod(...)
• 23번째 라인: invokeAndHandle(...)

10번째 라인에서 createInvocableHandlerMethod(handlerMethod) 메서드를 통해 ServletInvocableHandlerMethod 객체를 생성하고 있습니다.

 

그럼 ServletInvocableHandlerMethod 클래스는 무엇일까요??

HandlerMethod를 상속받고 있는 클래스 중 하나입니다. 

 

클래스 상단의 주석을 설명해보면 다음과 같습니다. (오역이 존재할수도..?)

등록된 HandlerMethodReturnValueHandler를 통해 반환 값을 처리하는 기능으로 InvocableHandlerMethod를 상속받고, 메서드 레벨에서의 @ResponseStatus 어노테이션을 통해 응답 상태를 설정할 수 있습니다.

 

그럼 InvocableHandlerMethod는??

HandlerMethodArgumentResolver 리스트를 통해 현재 HTTP 요청에서 받은 인수 값으로 기본 메서드를 호출(invoke)하는 HandlerMethod를 상속받는 클래스입니다.

아하! 완벽하게 이해를 한 건 아니지만, ServletInvocableHandlerMethod는 HandlerMethod와 함께 컨트롤러의 파라미터(HandlerMethodArgumentResolver) 및 반환값(HandlerMethodReturnValueHandler)을 처리하기 위해 필요한 객체라고 말하는 것 같습니다.

 

설명이 길어졌네요! 다시 RequestMappingHandlerAdapter의 코드로 돌아가보겠습니다.

RequestMappingHandlerAdapter (이제 거의 다 왔습니다....)

위 10번째 라인의 createInvocableHandlerMethod() 메서드를 통해 ServletInvocableHandlerMethod 객체를 생성하는 코드를 따라가보면 bean, beanFactory, method, parameters 등의 변수가 초기화되어 생성이 됩니다.

ServletInvocableHandlerMethod -> InvocableHandlerMethod -> HandlerMethod

 

ServletInvocableHandlerMethod 객체의 생성 및 설정이 끝나면 위 23번째 라인의 invokeAndHandle() 메서드가 실행됩니다.

ServletInvocableHandlerMethod

invokeAndHandle()는 Controller의 메서드를 실행하고 반환 값을 처리하는 메서드입니다.

(여기에서 리턴 타입에 따라 ModelAndView, ReponseEntity, ResponseBody 등을 각 Handler가 처리합니다.)

 

실제 처리는 부모 클래스 InvocableHandlerMethod의 invokeForRequest() 메서드에서 이루어지게 됩니다.

 

이쯤 되면 처음 클라이언트가 요청한 URI가 무엇인지 기억이 나지 않을 수도 있기에 기억을 되살려보면.... 😭

URI와 Controller의 test() 메서드를 리마인드 하는 이유는 드디어! 메서드의 파라미터를 가져오는 값이 아래 로직에 존재하기 때문입니다.

 

자 그럼 다시 InvocableHandlerMethod의 invokeForRequest() 메서드를 보겠습니다.

InvocableHandlerMethod

invokeForRequest() 메서드에서는 getMethodArgumentValues() 메서드를 통해 Controller의 메서드를 호출하기 위해 필요한 인자 값들을 처리합니다.

 

위 예제에서는 test() 메서드에 쿼리 스트링을 처리하기 위해 @RequestParam 어노테이션이 선언되어 있는데 이 외에도 @PathVariable, @RequestHeader 등의 어노테이션이 스프링의 ArgumentResolver에 의해 처리가 되고, 이와 관련한 작업이 수행되는 곳이 getMethodArgumentValues() 메서드입니다.

 

getMethodArgumentValues() 메서드의 네이밍을 통해 메서드의 인자 값을 가져온다는 것을 유추할 수 있습니다.

실제 가져오는 과정을 타고 들어가 보면 다음 클래스들을 거쳐서 인자 값을 가져옵니다... 😱

• InvocableHandlerMethod: this.resolvers.resolveArgument() -- (위 코드에서 32번째 라인)
• HandlerMethodArguemtnResolverComposite: resolveArgument()
• AbstractNamedValueMethodArgumentResolver: resolveArgument()
• RequestParamMethodArguemtnResolver: resolveName()
• ServletWebRequest: getParameterValues()
• RequestFacade: getParameterValues()
• Request: getParameterValues()
• Paramteters: getParameterValues() --- apache.tomcat.util.http

위와 같이 타고 타고 타고 .... 계속 들어가다보면 apache.tomcat의 Parameters클래스의 getParameterValues() 메서드에서 Map을 이용해 @RequestParam의 key에 해당하는 value를 가져옵니다.

 

인자값을 처리하고 나면 InvocableHandlerMethod로 돌아와서 doInvoke() 메서드를 호출합니다.

요청을 처리하면 이후 응답에 대한 처리를 하기 위해 ServletInvocableHandlerMethod에서 HandlerMethodReturnValueHandlerComposite를 사용하여 후처리를 진행 합니다.

(아래 코드에서 135번째 라인 ~ )

ServletInvocableHandlerMethod

위 HandlerMethodReturnValueHandlerComposite 클래스는 List에 등록되어 있는 Handler 중에 위임하여 메서드 반환값을 처리하는 컴포지트 패턴을 적용하고 있습니다.

HandlerMethodReturnValueHandler: handler method 실행 후 반환 값을 처리하기 위한 전략 인터페이스
 - supportsReturnType() 메서드를 통해 주어진 메서드의 리턴 타입이 처리가 가능한지 판별
 - handleReturnValue() 메서드에서 주어진 반환 값을 토대로 처리

HandlerAdapter가 Controller에게 요청이 끝나면 다음에는 응답에 대한 후처리로 returnValueHandlers를 통해 처리됩니다.

API의 return type은 String인데요, 여기에 맞는 returnValueHandlers는 RequestResponseBodyMethodProcessor 입니다.

(주로 사용하는 ResponseEntity가 리턴 타입인 경우 HttpEntityMethodProcessor을 Handler로 사용합니다.)

 

또한 @RestController 어노테이션을 사용했기 때문에 ModelAndView가 아닌 String 문자열이 그대로 응답 값으로 반환이 됩니다.

 

RequestResponseBodyMethodProcessor 내부에서는 input, output Message를 생성하여  AbstractMessageConverterMethodProcessor 추상 클래스의 writeWithMessageConverters() 메서드를 호출하고, MediaType을 검사하여 적절한 HttpMessageConverter를 찾아 응답을 처리하고 결과를 반환합니다.

 

 

✍️ 정리

이상으로 Spring에서 DispatcherServlet에 대해 살펴보았습니다.

 

DispatcherServlet이라는 하나의 개념만 보아도 무수히 많은 로직과 여러 패턴들, Spring의 철학 등을 볼 수 있어서 좋았습니다.

또한 디자인 패턴이 실제 코드 속에서 사용되는 예시를 보니 기존에 개념만 보던 것과는 달리 이해가 더 잘 되는 것 같습니다.

(사실 DispatcherServlet 내에서도 핵심 기능만 봤기 때문에 보지 못한 코드도 굉장히 많습니다...)

 

스프링은 매우 오래전에 만들어진 프레임워크에도 불구하고 아직까지 아무 문제 없이 많이 잘 사용되는 것을 보면... 정말 대단하네요.

완벽한 설계와 아키텍처는 없겠지만, 소프트웨어에 있어서 굉장히 중요한 요소라고 다시끔 느낀 것 같습니다.

 

다음 시간에는 아주 간단한 DispatcherServlet을 직접 만들어보며 조금 더 이해도를 높여보겠습니다.

 

 

📄 참고 문서

• https://docs.spring.io/spring-framework/docs/3.0.0.M4/spring-framework-reference/html/ch15s02.html
• https://terasolunaorg.github.io/guideline/5.0.1.RELEASE/en/Overview/SpringMVCOverview.html#overview-of-spring-mvc-processing-sequence
• https://mangkyu.tistory.com/18
• https://mangkyu.tistory.com/216
• https://tecoble.techcourse.co.kr/post/2021-07-15-dispatcherservlet-part-2/