[Spring / SpringBoot] Dispatcher Servlet(디스패처 서블릿) 동작 과정 / SpringBoot(스프링부트) 요청, 응답 흐름

Dispatcher Servlet이란?

DispatcherServlet은 HTTP 프로토콜로 들어오는 모든 요청을 먼저 받아서 적합한 컨트롤러에 위임(Delegate Request)하는 역할을 하는 Front Controller라고 정의할 수 있다. Front Controller란 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로서, MVC 구조에서 함께 사용되는 디자인 패턴이다.

*스프링부트의 주요 기능 중 하나는 자동 구성이다. 따라서 스프링부트 구동시 DispatcherServlet을 서블릿으로 자동 등록하고, 모든 경로"/"에 대해 매핑한다. 

 

https://mozzi-devlog.tistory.com/8

정적 자원(Static Resources)의 처리

Dispatcher Servlet이 모든 요청을 처리하다보니 이미지, css, javascript등과 같은 정적 자원에 대한 요청마저 모두 가로채며 정적 자원을 불러오지 못하는 상황이 발생함.

해결방법1. 정적자원 요청과 애플리케이션 요청을 분리

- /apps의 엔드포인트로 접근하면 Dispatcher Servlet이 담당

- /resources의 URL로 접근하면 Dispatcher Servlet이 컨트롤할 수 없으므로 담당 x

-> 모든 엔드포인트에 apps와 resources를 붙여줘야 하므로 직관적인 설계 불가능

해결방법2. 애플리케이션 요청을 탐색하고 없으면 정적 자원 요청으로 처리

Dispatcher Servlet이 요청에 대한 컨트롤러를 찾고 없으면 2차적으로 자원(resources)경로를 탐색하여 자원 탐색.

-> 효율적인 리소스 관리를 지원 / 추후에 확장 용이

Dispatcher Servlet의 장점

과거에 Dispatcher Servlet이 등장하기 전에는 모든 서블릿에 대해 URL을 매핑하기 위해 관련 설정을 해주어야하는 번거로움이 존재했다. 기존에는 모든 서블릿에 대해서 URL 매핑을 하기 위해 web.xml파일에 모두 등록해야 했지만, Dispatcher Servlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링하고 공통 작업을 처리하면서 매우 편리해졌다. 한마디로 Dispatcher Sevlet은 클라이언트로부터 오는 모든 요청을 가로채서 공통으로 관리하기 때문에 web.xml에 대한 의존을 극적으로 낮출 수 있게 해주면서, 하나의 서블릿으로 모든 것을 관리하기 때문에 공통되는 코드의 양도 줄일 수 있다.

우리가 컨트롤러를 구현하기만 한다면 Dispatcher Servlet이 알아서 일치하는 Controller로 위임을 해주는 구조가 되었다.

+ Servlet이란?

: 자바 웹 앱에서 클라이언트 요청을 다루기 위해 사용되는 자바 클래스

Dispatcher Servlet의 동작 과정

https://mangkyu.tistory.com/18

1. 클라이언트가 디스패처 서블릿에 요청을 보냄

디스패처 서블릿은 프론트 컨트롤러로서 Web Context에서 필터들을 지나 스프링 컨텍스트에서 디스패처 서블릿이 가장 먼저 요청을 받게된다. 클라이언트는 URL(ex. /follow/{fromUser}/{toUser})로 접근하여 정보를 요청한다.

2. 해당 요청의 엔드포인트를 매핑한 컨트롤러가 있는지 찾는다. 

디스패처 서블릿은 요청을 처리할 핸들러(컨트롤러)를 찾고 해당 객체의 메소드를 호출한다. 어떤 컨트롤러가 요청을 처리할 수 있는지를 식별하도록 해주는 것이 HandlerMapping이다. 예를들어서 클라이언트가  "follow/{userId}/post"엔드포인트로 서버에게 요청을 보낸다면 HandlerMapping이 @Controller중 Follow를 구현한 @Controller를 찾는 것이다. 

3. 요청을 Controller로 위임할 핸들러 어댑터를 찾아서 전달.

요청을 처리할 @Controller를 찾았으면 요청을 위임해야 하는데, 디스패처 서블릿은 컨트롤러로 바로 요청을 위임하지 않고, HandlerAdapter를 통해 위임한다. 왜냐하면 컨트롤러의 구현 방식이 다양하기 때문이다. 따라서 다양하게 작성되는 컨트롤러에 대응하기 위해 스프링은 HandlerAdapter라는 어댑터 인터페이스를 통해 어댑터 패턴을 적용함으로써 컨트롤러의 구현 방식에 상관없이 요청을 위임하도록 하였다.

4. HandlerAdapter가 Controller로 요청을 위임.

핸들러 어댑터는 요청을 위임한 전/후에 공통적인 전/후처리 까지 해준다. @RequestParam, @RequestBody등의 전처리와 요청에 대한 응답인 ResponseEntity의 Body를 Json으로 직렬화하는 등의 처리를 해준다. 

5. 비즈니스 로직 처리

클라이언트가 요청한 로직을 처리해준다.

6. Controller가 반환값을 반환

일반적으로 ResponseEntity를 가장 많이 반환.

return ResponseEntity.ok().body(responseDTO);

예를들어 이런식으로 반환한다.

7. 핸들러 어댑터가 반환값을 처리해준다. 

아까 4번에서 HandlerAdapter는 요청을 위임한 전처리 뿐만 아니라 후처리까지 해준다고 하였다. 컨트롤러로부터 받은 응답을 응답 처리기인 ReturnValueHandler가 후처리한 후에 디스패처 서블릿으로 돌려준다. 만약 컨트롤러가 ResponseEntity를 반환하면 HttpEntityMethodProcessor가 MessageConverter를 사용하여 응답 객체를 직렬화 하고 응답 상태를 설정. 만약 View이름을 반환하면 ViewResolver를 통해 View를 반환.

8. 서버의 응답을 클라이언트로 반환

응답이 데이터라면 그대로 반환되고, 화면이라면 View의 이름에 맞는 View를 찾아서 반환해주는 ViewResolver가 적절한 화면을 내려준다.

 

References

가장 많이 참고한 글:

https://mangkyu.tistory.com/18

[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정

https://jake-seo-dev.tistory.com/435

https://mozzi-devlog.tistory.com/8