서블릿은 자바 기반의 CGI(Common Gateway Interface) 프로그램이며 CGI 규칙에 따라 웹 서버와 데이터를 주고받으며 서블릿의 구현체인 톰캣과 같은 서블릿 컨테이너(애플리케이션 서버)에서 동작한다.
HTTP 요청을 클라이언트가 보내면 서버는 인증, 로깅과 같은 필터링 작업을 수행하는 필터 리스트를 통과한다. 요청이 필터를 통과하면 애플리케이션 서버는 특정 패턴과 일치하는 URI를 처리하도록 애플리케이션 서버에 등록된 서블릿으로 요청을 넘겨준다. 서블릿이 요청을 처리하면 응답은 다시 필터 세트를 거쳐 클라이언트로 전송된다.
자바 EE에서 모든 HTTP 요청에 대해 HttpServletRequest 인스턴스가 생성되고 응답에 대해선 HttpServletResponse 인스턴스가 생성된다.
이러한 서블릿 사용 방식은 요청처리를 위한 서블릿 객체를 일일이 모두 정의하여 web.xml 파일에 등록해야한다. 이는 매우 비효율적이고 코드도 지저분해졌다.
스프링 MVC에서는 위와 같은 서블릿은 사용할 필요가 없다. 스프링 MVC에서는 @Controller 어노테이션으로 컨트롤러를 등록하고 @RequestMapping 어노테이션을 통해 특정 요청 URI 패턴에 매핑한다.
디스패처 서블릿은 가장 앞단에서 필터를 거친 HTTP 요청을 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)다. 각 요청을 받는 서블릿이 여러개 존재하던 자바 EE 서블릿과 다르게 디스패처 서블릿은 모든 요청을 받고 @RequestMapping으로 등록된 URI 패턴과 일치하는 컨트롤러를 찾아 요청을 전달해준다.
디스패처 서블릿이 모든 요청을 처리하기 때문에 생기는 문제점이 있는데 바로 정적 자원에 대한 요청도 디스패처 서블릿이 처리하기 때문에 정적 자원에 대해서도 컨트롤러로 등록이 필요했다.
이러한 문제는 요청 URI와 매핑되는 컨트롤러를 찾지 못하면 2차적으로 설정된 자원(스프링부트의 경우 /resources) 경로를 탐색하여 자원을 찾아내어 응답하는 방식으로 해결하였다.
References
- 디스패처 서블릿이란?
- 실전! 스프링5와 Vue.js2로 시작하는 모던 웹 애플리케이션 개발, 위키북스