[Spring] Dispatcher-Servlet의 동작 과정을 알아보자.

TIlearn 2024. 2. 5. 17:56

Dispatcher - Servlet이란?

Dispatcher Servlet에 앞서, _Servlet_이란 자바를 사용하여 웹 페이지를 동적으로 생성하는 서버 측 프로그램 혹은 그 사양을 뜻한다. 자바의 Servlet은 웹 서버의 성능을 향상시키기 위해서 사용되는데, 간단하게 생각하자면 클라이언트의 요청을 처리하고 결과를 반환하는 웹 프로그래밍 기술이다.

_Dispatcher-Servlet_또한 _Servlet_의 일종으로 그 역할을 살펴보자면 Dispatcher의 의미를 찾아보면 된다. 이는 "급파자"라는 뜻으로 가장 먼저 요청을 받아 처리할 함수인 컨트롤러를 정해주는 역할을 가진다.

즉, _Dispatcher-Servlet_은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아서 적합한 컨트롤러에게 위임해주는 프론트 컨트롤러이다. 정확히는 클라이언트 측으로 부터 요청이 들어오면 가장 먼저 Tomcat과 같은 _Servlet Container_에게 요청이 들어오고, 이러한 요청을 Dispatcher-Servlet이 가장 먼저 받게된다.

Dispatcher - Servlet은 모든 요청을 핸들링해주면서 공통작업을 수행해준다는 점에 있어 매우 편리하다. 하지만, 이미지나 HTML/CSS/JS와 같은 정적파일에 대한 요청 또한 모두 가로채는 바람에 정적자원을 불러오지 못한다는 단점이 있다.

이러한 문제를 해결하기 위한 두 가지 방법으로 첫 번째는 URL로 클라이언트 요청을 구분하는 것이다. 예를 들어, /apps로 접근하면 dispatcher servlet이 담당하도록 하고, /resources로 접근하면 dispatcher servlet이 담당하지 않도록 한다.

하지만, 코드가 더러워지고 직관적이지 못하다는 단점때문에 두 번째 방법을 사용한다. 두 번째 방법은 컨트롤러에서 찾을 수 없는 요청에 대해서는 전부 Resource 경로로 탐색하도록 하는 것이다. 이렇게 만든다면, 확장에 용이할 뿐만이 아니라 관리도 편해진다.

Dispatcher Servlet은 내부적으로 HttpServlet을 상속 받고 있다.
(정확히는 DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet 상속 구조이다.)

🔶 HttpServlet

Http 서블릿을 구현하기 위한 J2EE 스펙의 추상 클래스이다. 템플릿 메서드를 사용하며 특정 HTTP 메서드를 지원하기 위해서는 doX 메소드를 오버라이드 해야 한다.

🔶 HttpServletBean

HttpServlet을 Spring이 구현한 추상 클래스이다.

🔶 FrameworkServlet

Spring 웹 프레임워크의 기반이 되는 서블릿이다. HttpServlet의 doX 메서드를 오버라이드 하고 있다.(이때, PATCH요청은 따로 처리) 각 doX 메서드는 요청을 처리하는 메서드인 processRequest를 호출한다.

processRequest의 실제 요청 핸들링은 템플릿 메서드 패턴이 적용되었기에 doService로 위임된다.

🔶 DispatcherServlet

실제 요청을 처리하는 doService를 구현한다.

디스패처 서블릿은 Servlet WebApplicationContext를 생성하고, Root WebApplicationContext를 생성한다. 여기안에 Controller, ViewResolver, HandlerMapping등이 있다.

Root WebApplicationContext를 생성할 경우, Infra Bean이 생성되는 데 Repository나 Service가 이에 해당된다.

Dispatcher - Servlet의 동작 과정

1️⃣ 클라이언트의 요청을 디스패처 서블릿이 받는다.

프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 요청을 받는다.

2️⃣ 요청 정보를 통해서 요청을 위임할 컨트롤러를 찾는다.

이 단계 부터 아래 그림의 _doService_ 메서드가 수행된다. _DispatcherServlet_은 요청을 처리하기 위해 실제 작업을 위임하는데, 이렇게 위임받는 컴포넌트를 스페셜 빈(Special Bean)이라고 부른다.

그 중에서도 _HandlerMapping_이라는 스페셜 빈을 통해서 컨트롤러를 찾을 수 있다.

_DispatcherServlet_에서 위임하는 스페셜 빈은 아래와 같다.

1. _HandlerMapping_ : 요청을 처리할 컨트롤러를 찾는다.
2. _HandlerAdapter_ : 요청을 컨트롤러로 전달한다.
3. _handlerExceptionResolver_ : 요청에 대한 예외 발생 시 처리한다.
4. _viewResolver_ : 리턴 값에 대한 뷰 컴포넌트를 반환한다. 이때, String으로 뷰 이름을 받는다면 modelAndView와 같은 객체로 반환한다.
5. _LocalResolver_ : Local을 결정하는데, 이는 유저의 언어나 지역이나 출력형식을 지정하는 문자열이다.
6. _MultipartResolver_ : 멀티 파트 파일 업로드를 처리한다. 멀티 파트란 클라이언트 측에서 바디를 여러 번 나누어 보낼 때 파일 형식을 의미한다.

Spring boot 개발 시 자주 사용하는 _@Controller_ 방식은 _RequestMappingHandlerMapping_이 처리한다. 여기서 모든 컨트롤러를 탐색하고 HashMap으로 요청 정보와 그 대상을 관리할 수 있다.

관리 대상은 _HandlerMethod_ 객체가 오게 되는데 이 안에는 컨트롤러와 메서드가 들어있다. _HandlerMethod_는 그 자체로 저장되지 않고 _HandlerExceptionChain_으로 감싸서 보관된다. 그 이유는 전/후 "인터셉터"를 포함하기 때문이다.

3️⃣ 핸들러 어댑터를 찾아서 요청을 위임한다.

_DispatcherServlet_은 앞서 컨트롤러에 대한 정보가 저장된 _HandlerExceptionChain_을 그대로 사용하지 않는다. 대신 _HandlerAdapter_라는 어댑터 인터페이스를 통해서 실행한다.

굳이 바로 쓰지 않고 이렇게 인터페이스를 통하는 이유는 현재 다양한 형태의 어노테이션 기법으로 컨트롤러를 만들 수 있기 때문이다. 그래서 포맷이 다르더라도 _DispatcherServlet_의 입장에서는 _HandlerAdapter_를 통해 자신의 코드를 바꾸지 않아도 된다.

_HandlerAdapter_를 찾기 위해서 _getHandlerAdapter()_함수를 호출한다. 이렇게 얻어진 _HandlerAdapter_를 통해서 이제 컨트롤러 메서드를 호출할 것이다.

_HandlerAdapter_가 컨트롤러로 요청을 위임한 전/후에 공통적으로 전/후처리 과정이 필요하다. 이 과정에서 대표적으로 인터셉터를 포함하여 _@RequestParam_과 _@RequestBody_를 처리하는 _ArgumentResolver_와 직렬화 처리를 위한 _ReturnValueHandler_ 등이 _HandlerAdapter_에서 처리된다.

4️⃣ 비즈니스 로직을 처리한다.

컨트롤러는 _Root WebApplicationContext_ 속의 _Service_와 _Repository_등을 호출해가며 비즈니스 로직을 처리한다.

5️⃣ 컨트롤러가 반환값을 내놓고, _HandlerAdapter_가 처리한다.

_HandlerAdapter_는 반환값을 받아서 _Dispatcher Servlet_으로 돌려주는데, 이때 반환 형식에 따라 다른 행동을 한다.

만약, 컨트롤러가 _ResponseEntity_를 반환한다면 _MessageConverter_를 통해서 직렬화 이후 응답 상태를 설정해 반환할 것이지만, 컨트롤러가 View이름을 반환한다면 _ViewResolver_를 반환할 것이다.

6️⃣ 서버의 응답을 클라이언트로 반환한다.

_DispatcherServlet_ 을 통해서 반환되는 응답은 필터를 거치고 클라이언트에게 반환된다. 응답이 만약 데이터라면 그대로 반환될 것이고, 화면이라면 _ViewResolver_를 통해 적절하게 화면을 보여줄 것이다.