목차
1.Dispatcher-Servlet(디스패처 서블릿) 이란?
2.Dispatcher-Servlet(디스패처 서블릿)의 장점
3.
참조사이트 1

[Dispatcher-Servlet(디스패처 서블릿) 이란?]

목차로 이동

디스패처 서블릿의 dispatch는 "보내다"라는 뜻을 가지고 있습니다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)라고 정의할 수 있습니다.

[ Dispatcher-Servlet(디스패처 서블릿)의 장점 ]

목차로 이동
Spring MVC는 DispatcherServlet이 등장함에 따라 web.xml의 역할을 상당히 축소시켜주었습니다
dispatcher-servlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링해주고 공통 작업을 처리면서 상당히 편리하게 이용할 수 있게 되었습니다.

[ 정적 자원(Static Resources)의 처리 ]

목차로 이동
Dispatcher Servlet이 요청을 Controller로 넘겨주는 방식은 효율적으로 보입니다. 하지만 Dispatcher Servlet이 모든 요청을 처리하다보니 이미지나 HTML/CSS/JavaScript 등과 같은 정적 파일에 대한 요청마저 모두 가로채는 까닭에 정적자원(Static Resources)을 불러오지 못하는 상황도 발생하곤 했습니다. 이러한 문제를 해결하기 위해 개발자들은 2가지 방법을 고안했습니다.

1.정적 자원에 대한 요청과 애플리케이션에 대한 요청을 분리
2.애플리케이션에 대한 요청을 탐색하고 없으면 정적 자원에 대한 요청으로 처리

1. 정적 자원에 대한 요청과 애플리케이션에 대한 요청을 분리

이에 대한 해결책은 두가지가 있는데 첫번째는 클라이언트의 요청을 2가지로 분리하여 구분하는 것입니다.

/apps 의 URL로 접근하면 Dispatcher Servlet이 담당한다.
/resources 의 URL로 접근하면 Dispatcher Servlet이 컨트롤할 수 없으므로 담당하지 않는다.
이러한 방식은 괜찮지만 상당히 코드가 지저분해지며, 모든 요청에 대해서 저런 URL을 붙여주어야 하므로 직관적인 설계가 될 수 없습니다. 그래서 이러한 방법의 한계를 느끼고 다음의 방법으로 처리를 하게 되었습니다.

2. 애플리케이션에 대한 요청을 탐색하고 없으면 정적 자원에 대한 요청으로 처리

두번째 방법은 Dispatcher Servlet이 요청을 처리할 컨트롤러를 먼저 찾고, 요청에 대한 컨트롤러를 찾을 수 없는 경우에, 2차적으로 설정된 자원(Resource) 경로를 탐색하여 자원을 탐색하는 것입니다. 이렇게 영역을 분리하면 효율적인 리소스 관리를 지원할 뿐 아니라 추후에 확장을 용이하게 해준다는 장점이 있습니다

어떤말이냐면 지금 스프링 구조를 보면 컨트롤러를 만들어서 자바 파일이 있는 java폴더부분과 이미지나 html이 저장되어있는 resource폴더로 나누어서 두고 여기서 처음에 디스패치 서블릿이 java폴더에 controller부근에 가서 요청을 찾는데 없으면 resource부분으로 이동하여 해당 요청을 찾아서 보내주는것이다.

[Dispatcher Servlet(디스패처 서블릿)의 동작과정]

목차로 이동
1.

1.클라이언트의 요청을 디스패처 서블릿이 받음
2.요청 정보를 통해 요청을 위임할 컨트롤러를 찾음
3.요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달함
4.핸들러 어댑터가 컨트롤러로 요청을 위임함
5.비지니스 로직을 처리함
6.컨트롤러가 반환값을 반환함
7.HandlerAdapter가 반환값을 처리함
8.서버의 응답을 클라이언트로 반환함

2.그림

3. 그림3
   

Dispatcher Servlet(디스패처 서블릿)의 동작과정 상세설명

목차로 이동

1. 클라이언트의 요청을 디스패처 서블릿이 받음

앞서 설명하였듯 디스패처 서블릿은 가장 먼저 요청을 받는 프론트 컨트롤러입니다. 서블릿 컨텍스트(웹 컨텍스트)에서 필터들을 지나 스프링 컨텍스트에서 디스패처 서블릿이 가장 먼저 요청을 받게됩니다. 이를 그림으로 표현하면 다음과 같습니다. 실제로는 Interceptor가 Controller로 요청을 위임하지는 않으므로 아래의 그림은 처리 순서를 도식화한 것으로만 이해하면 됩니다.

2. 요청 정보를 통해 요청을 위임할 컨트롤러를 찾음

디스패처 서블릿은 요청을 처리할 컨트롤러를 찾고 해당 메소드를 호출해야 합니다. HandlerMapping의 구현체 중 하나인 RequestMappingHandlerMapping은 @Controller로 작성된 모든 컨트롤러 빈을 파싱하여 HashMap으로 (요청 정보, 처리할 대상)을 관리합니다. 엄밀히는 컨트롤러가 아닌, 요청에 매핑되는 컨트롤러와 해당 메소드 등을 갖는 HandlerMethod 객체를 찾습니다.
그래서 HadlerMapping은 요청이 오면 Http Method, URI 등을 사용해 Key 객체인 요청 정보를 만들고, Value인 요청을 처리할 HandlerMethod를 찾아 HandlerMethodExecutionChain으로 감싸서 반환합니다. HandlerMethodExecutionChain으로 감싸는 이유는 컨트롤러로 요청을 넘겨주기 전에 처리해야 하는 인터셉터 등을 포함하기 위해서입니다.

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

디스패처 서블릿은 컨트롤러로 요청을 직접 위임하는 것이 아니라 HandlerAdapter를 통해 컨트롤러로 요청을 위임합니다. 이때 어댑터 인터페이스를 통해 컨트롤러를 호출하는 이유는 컨트롤러의 구현 방식이 다양하기 떄문입니다. 최근에는 @Controller에 @RequestMapping 관련 어노테이션을 사용해 컨트롤러 클래스를 주로 작성하지만, Controller 인터페이스를 구현하여 컨트롤러 클래스를 작성할 수도 있습니다. 스프링은 HandlerAdapter라는 어댑터 인터페이스를 통해 어댑터 패턴을 적용함으로써 컨트롤러의 구현 방식에 상관없이 요청을 위임할 수 있는 것입니다.

4. 핸들러 어댑터가 컨트롤러로 요청을 위임함

핸들러 어댑터가 컨트롤러로 요청을 넘기기 전에 공통적인 전/후처리 과정이 필요합니다. 대표적으로 인터셉터들을 포함해 요청 시에 @RequestParam, @RequestBody 등을 처리하기 위한 ArgumentResolver들과 응답 시에 ResponseEntity의 Body를 Json으로 직렬화하는 등의 처리를 하는 ReturnValueHandler 등이 어댑터에서 컨트롤러로 전달되기 전에 처리됩니다. 그리고 컨트롤러의 메소드를 호출하도록 요청을 위임합니다. 실제로 요청이 위임되는 과정에서는 리플렉션이 사용됩니다.
요청을 처리할 대상 정보인 HandlerMethod 객체에는 컨트롤러 정보와 메소드 객체가 있으므로 리플렉션의 메소드 객체를 invoke 합니다. 사실 실제로는 HandlerMethod에 컨트롤러 빈 이름과 메소드, 빈 팩토리가 있어서 빈 팩토리에서 컨트롤러 빈을 찾습니다. 그리고 해당 컨트롤러 빈 객체로부터 리플렉션을 사용하는데, 그렇게 중요하지는 않으므로 따로 관심이 있는 사람들은 이 글을 참고해주세요.

5. 비지니스 로직을 처리함

이후에 컨트롤러는 서비스를 호출하고 우리가 작성한 비지니스 로직들이 진행됩니다.

6. 컨트롤러가 반환값을 반환함

비지니스 로직이 처리된 후에는 컨트롤러가 반환값을 반환합니다. 요즘 프론트엔드와 백엔드를 분리하고, MSA로 가고 있는 시대에서는 주로 ResponseEntity를 반환합니다. 물론 컨트롤러에서 View 이름을 반환할 수도 있습니다.

7. HandlerAdapter가 반환값을 처리함

HandlerAdapter는 컨트롤러로부터 받은 응답을 응답 처리기인 ReturnValueHandler가 후처리한 후에 디스패처 서블릿으로 돌려줍니다. 만약 컨트롤러가 ResponseEntity를 반환하면 HttpEntityMethodProcessor가 MessageConverter를 사용해 응답 객체를 직렬화하고 응답 상태(HttpStatus)를 설정합니다. 만약 컨트롤러가 View 이름을 반환하면 ViewResolver를 통해 View를 반환합니다.

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

디스패처 서블릿을 통해 반환되는 응답은 다시 필터들을 거쳐 클라이언트에게 반환됩니다.

1. 처음 클라이언트에서 요청이 오면 디스패처 서블릿이 해당 요청을 받는다.
2. Handler Mapping을 통해 요청에 알맞은 컨트롤러를 찾아낸다.
3. 찾아낸 컨트롤러를 Handler Adapter를 통해 해당 컨트롤러의 메서드를 실행시킨다.
4. 컨트롤러는 요청을 처리한 뒤 처리한 결과와 해당 뷰 정보(ModelAndView)를 다시 디스패처 서블릿에게 전달한다.
5. 받은 정보로 디스패처 서블릿은 View Resolver를 통해 View 파일을 찾는다.
6. 찾은 값을 필터를 거쳐 클라이언트에게 반환한다.

동작의 흐름을 간단히 말하면 요청을 처리할 컨트롤러를 찾아서 위임하고 처리된 결과를 받는것이다.

Servlet을 지원하는 WAS가 하는 역할

서버에서 처리해야 하는 업무

목차로 이동

• 서버 TCP/IP대기, 소켓연결
• HTTP 요청 메시지를 파싱해서 읽기
• POST방식, /save URL 인지
• Content Type 확인
• HTTP 메시지 바디 내용 파싱
  - username, age 데이터를 사용할 수 있게 파싱
• 저장 프로세스 실행

비즈니스 로직 실행

- 데이터베이스에 저장요청

• HTTP 응답 메시지 생성시작
  - HTTP 시작 라인 생성
  • Header 생성
  • 메시지 바디에 HTML 생성해서 입력
• TCP/IP에 응답 전달, 소켓 종료

빨간색 테투리 내의 내용을 제외한 모든 것을 Servlet이 대신 처리해준다.