서블릿 동작 방식
사용자 요청이 들어오면 어떤 요청에 어떤 서블릿이 필요한지 정의된 서블릿 설정파일로 서블릿 컨테이너(서블릿들의 생성과 실행, 소멸 담당함)는 해당 요청과 매핑된 서블릿을 찾는다.
서블릿 컨테이너는 사용자의 Request를 받아주고 Response할 수 있게, 웹 서버와 소켓을 만들어 통신한다.
대표적으로 무료 서비스인 Tomcat이 있다.
서블릿컨테이너가 1요청-1서블릿, 2요청-2서블릿를 알게 되면 서블릿 인스턴스가 컨테이너에 있는지 확인을 한다. 인스턴스가 컨테이너에 존재한다면 그 인스턴스를 그대로 사용하게 되는 거고 없다면 생성해서 가져가 사용하게 되는 것이다.
서블릿 컨테이너에 스레드를 생성하고 미리 만든 HttpServletResponse랑 HttpServletRequest 객체를 인자로 서비스를 호출한다. 이후에 Response랑 Request 객체를 소멸시키고 끝이난다.
Response랑 Request객체는 생성하고 소멸시켰는데
서블릿은 생성만하고 소멸시키지 않는 이유는 싱글톤으로 관리되어서 그렇다. 다음번에 같은 요청이 들어왔을 때, 서블릿컨테이너에 의해서 또 호출돼서 사용이 된다.
서블릿컨테이너는 서블릿의 생명주기를 관리하는 객체이다.
여러요청이 들어온다면 멀티스레드로 사용이 된다.
하지만 스레드는 생성하는 자체로 큰 비용이 들고 다른 스레드로 전환하는 Context Swtich가 많은 오버헤드를 일으키기 때문에 좋지 않다.
스레드 생성에 제한을 두지 않는다면 많은 요청을 처리하기 위해 그만큼 많은 스레드를 생성하다가 서버의 하드웨어 한계를 넘어버리면 서버가 터질 위험이 있어 비효율적이다.
프론트 컨트롤러 패턴
Dispatcher Servlet: 모든 요청을 받는 전면 컨트롤러 서블릿
서블릿은 하나만 두고 모든 요청을 다 받을 수 있도록 하는 것
서블릿 인터페이스
: 호출 규약
-
서블릿 생명주기와 관련된 메소드
init() : 서블릿 컨테이너가 서블릿 생성 후 초기화 작업을 수행하기 위해 호출하는 메소드
service() : 클라이언트 요청이 들어올 때 마다 서블릿 컨테이너가 호출하는 메소드
destroy() : 서블릿 컨테이너가 종료될 때 호출되는 메소드 -
서블릿 기타 메소드
getServletConfig() : 서블릿 초기 설정 정보를 담고있는 객체를 반환하는 메소드, 해당 객체를 통해 서블릿 이름, 서블릿 초기 매개변수 값 등을 얻을 수 있음
getServletInfo() : 서블릿을 작성한 사람, 서블릿 버전, 저작권 서블릿에 대한 정보를 반환하는 메소드
Dispatcher Servlet이 web 요청을 처리하는 과정
Dispatcher Servlet (모든 요청을 다 받음) -> Handler Mapping (내 요청을 처리할 때 컨트롤러를 찾아서 반환) -> Handler Adapter (그 컨트롤러의 메서드를 호출해서 처리 로직을 수행하는 역할을 하고, 그 처리결과를 Model And View 객체로 변환) -> Dispatcher Servlet에 넘겨줌
다시 Dispatcher Servlet -> View Resolver (뷰를 찾거나 생성, 그렇게 얻은 뷰에 아까 모델로 들어왔던 데이터를 넣어서 응답결과 생성을 요청함. 그래서 우리가 아는 JSP나 Thymeleat 같은 데이터를 담은 출력 파일로 응답을 하게 되는 것임) -> Dispatcher Servlet
Spring을 사용하는 이유
디스패처서블릿이 스프링 컨테이너로부터 관리되고 필요한 부분에서 주입을 받아서 사용하고 디스패처서블릿이 알아서 동작할 수 있게 해주는 것이다.
우리는 Handler Adapter 부분만 처리하면 된다.
스프링컨테이너: 프로그램이 동작하는 동안 사용되는 자바 객체들을 프레임워크가 대신 관리하고 보관하기 위해 사용 되는 바구니
정리
스프링 mvc에서 제공하는 디스패처서블릿과 웹 요청 처리 관련 구현체들을 사용할 수 있다는 이야기이고,
스프링 컨테이너(스프링 Ioc)를 사용해서 개발할 수 있는다는 이야기이다.
