꾸준히 듣게되는 Servlet과 Dispatcher Servlet에 대해 알아보자

 

WAS, Servlet, Spring bean.. 배워보면 별 거 아닌데 막상 누가 물어보면 뭐라고 설명할 지 잘 모르겠는 친구들 중 하나인 서블릿이다. 핵심만 간단하게 알아보자.

이름이 귀여운 WAS에 대해 알고 있으면 Servlet을 이해하는 것에 도움이 된다. 잘 모르면 이전에 작성한 글을 읽어보자.

1분 컷 가능하다. (https://7357.tistory.com/179)

 

 

 

 

1. Servlet 

 

서블릿은 클라이언트의 요청(Request)을 처리하고 그 결과를 반환(Response)하는 자바의 웹 프로그래밍 기술이다.

풀어서 설명하자면 우리가 서버에 "이거 내놔"라고 보냈을 때, 그 요청이 WAS 문지기인 서블릿한테 날아가면 "어어ㅇㅋ"하면서 보내준다는 말이다.

물론 검증 로직을 통과했을 때의 이야기지만 이것은 지금 다룰 문제는 아니다.

 

서블릿의 특징은 다음과 같다.

 

- 클라이언트의 Request에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트이다. (WAS 문지기다)

- HTML을 사용하여 요청에 응답한다.

- Java Thread를 이용하여 동작한다.

- Request, Response 객체를 통해 개발자가 직접 HTTP 요청을 Parsing하지 않고 편리하게 사용할 수 있도록 돕는다.

 

기타 다른 특징들이 있는데 의미가 아주 없지는 않지만 네줄 요약으로 충분하니 넘어가자.

어차피 깊이 파려면 이렇게 겉핥기로 볼 게 아니라 코드를 뜯어놓고 봐야한다.

 

서블릿의 통신 방식은 다음 이미지와 같다.

 

재탕

1. 브라우저에서 URL을 입력하여 Servlet Container로 Request를 전송한다. (HTTP Request)

2. 요청을 받은 Servlet Container는 HttpServletRequest, HttpServletResponse라는 객체를 호출한다.

3. 해당 서블릿에서 service 메서드를 호출한 뒤, GET, POST 여부에 따라 메서드를 호출한다.

 - DB, Service 계층에서 적절한 로직 수행 -

4. HttpServletResponse에 응답할 데이터를 담아 전송한다.

 

 

 

 

2. Servlet Container

 

 

서블릿을 관리하기 위해서는 서블릿 컨테이너가 필요하다. 

일반적으로 톰캣(Tomcat)처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 부른다. (WAS가 더 큰 개념이다.)

서블릿 컨테이너는 상당히 많은 역할을 가지고 있는데, 다음과 같다.

 

1. 서블릿 객체를 생성하고 초기화하며 호출하고 종료하는 일련의 생명주기를 관리한다.

2. 웹 서버와의 손쉬운 통신을 지원해준다. (소켓 생성, listen, accept 등)

3. XML파일 하나로 보안을 관리할 수 있다.

4. 멀티쓰레드 지원 및 관리.

: 서블릿 컨테이너 내부에는 ThreadPool이라는 공간이 존재해서 필요한 쓰레드를 미리 쓰레드 풀에 보관해놓고 관리한다.

개발자의 설정으로 최대치를 관리할 수 있으며, 서블릿 컨테이너는 쓰레드가 필요하면 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용하고, 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.

최대 쓰레드 수를 너무 높게 잡으면 서버 리소스가 과하게 사용될 수 있고, 너무 낮게 잡으면 클라이언트가 접속에 불편을 겪게될 수 있기 때문에 개발자가 적절하게 컨트롤할 수 있어야 한다.

 

 

 

3. 그럼 Dispatcher Servlet은 뭔데요?

 

사실 지금 시점에 Spring에서 Servlet을 사용한다면 기본적으로 Dispatcher Servlet을 사용하고 있을 것이다.

Dispatcher Servlet을 이요한 요청, 응답 흐름은 아래의 글에서 다루고 있다.

 

https://7357.tistory.com/135?category=1067676 

MVC패턴이란? Spring MVC의 기본 흐름을 알아보자.

 

기존의 서블릿도 당시에는 나름 획기적인 기술이였으나 기존의 서블릿은 객체를 일일히 생성하고 web.xml 문서에 기록해줘야 했다.

굳이 자세히 어떤 것인지 살펴보지 않아도 벌써 끔찍하게 느껴질 것이다.

게다가 매번 공통적으로 처리해야할 작업이 많아 중복 코드가 넘쳐 흘렀고 HttpServlet에 의존하기 때문에 의존성 문제까지 존재했다.

 

이 모든 것을 해결하기 위해 나타난 것이 바로 Dispatcher Servlet님이 되시겠다.

 

 

 

Dispatcher Servlet은 모든 요청을 가로채서 공통으로 관리하기 때문에 web.xml에 대한 의존을 극적으로 낮출 수 있게 해주며, 하나의 서블릿으로 모든 것을 관리하기 때문에 당연히 공통 코드도 깨끗하게 사라졌다. (자세한 원리는 front-controller pattern을 찾아보자.)

또한 HttpServlet 클래스에 대한 의존성 문제도 완벽하게 해결해서 @Controller같은 사랑스러운 어노테이션들을 활용할 수 있게된 것이다.

 

다만 Dispatcher Servlet을 사용하게 되면 정적 자원에 대한 처리가 상당히 특이해지는데, 수문장 역할을 하면서 정적 자원까지 모두 가로채버리는 것이다. 이런 경우 Dispatcher Servlet은 우선 웹 어플리케이션에서 우선 컨트롤러를 탐색한 다음, 2차적으로 설정된 경로(일반적으로 static)을 탐색하게 된다.

 

dispatcer Servlet의 상세한 작동 순서가 궁금하다면 아래 사이트를 참고해보자.

 

https://egovframe.go.kr/wiki/doku.php?id=egovframework:rte:ptl:dispatcherservlet 

egovframework:rte:ptl:dispatcherservlet [eGovFrame]