Spring Boot가 잘 되어 있어서 잘 이용만 한다면 깊게 알지 않아도 애플리케이션을 만들 수는 있지만 문제해결에 있어서 개념을 알고 있어야 더 빠른 해결점에 갈 수 있을 것이다.
웹 사이트에 접속을 마음 먹은 순간부터 요청과 응답의 연속이다. 웹 브라우저에서 URL을 입력하여 웹 페이지를 요청하고 웹서버는 요청메시지대로 처리 후 응답 메시지를 전송한다.
먼저 요청부터 응답하는 지점까지 전체적인 그림을 그려봤다.
Web Application의 요청부터 응답까지의 흐름
웹 서버(Web Server)는 무슨 역할을 하지?
여기서 웹 서버는 웹 브라우저와 통신할 수 있도록 소켓 연결 등의 네트워크 처리를 한다. 그리고 브라우저에서 보낸 요청 메시지를 해석하고 정적 리소스로 응답해줄 수 있으면 웹 애플리케이션 서버에 요청하지 않고 바로 브라우저에 응답해준다. 여기서 웹 애플리케이션 서버와 분리되는 이유가 설명된다. 정적인 리소스를 바로 응답해줌으로써 성능을 높일 수 있는 장점이 있다. 또한 브라우저와 웹 애플리케이션 서버 사이의 중계를 하기 때문에 보안상으로 안전해질 수 있다.
웹 애플리케이션 서버(Web Application Server 또는 WAS)는 무슨 역할을 하지?
웹 서버가 정적인 리소스를 처리해준다면 웹 애플케이션 서버는 동적인 데이터 처리와 비즈니스 로직을 수행한다.
이 위치에 바로 servlet container와 spring container가 있다.
여기서 바로 헷갈리던 점이 있었다. 위의 그림대로라면 웹 서버와 웹 애플리케이션 서버 사이에서 servlet container와 spring container가 있는데 어느 지점에 이것들이 있는 걸까?
Web Application Server 실행 흐름
웹 서버가 웹 브라우저의 요청에 응답을 하려면 실행 상태여야 한다.
처음 실행하면 웹 서버가 Servlet container를 생성한다.
Servlet Container의 역할
첫째, Servlet Container는 servlet을 관리해준다. servlet의 라이프 사이클은 init->serviet->destroy 순으로 요청이 들어오는 순간 생성이 되고 응답을 하는 순간 소멸되게 된다. 바로 이 라이프 사이클을 Servlet Container가 직접 관리하게 된다. 그리고 DispatcherServlet 역시 Servlet Container가 관리하게 된다.
둘째, Servlet Container는 웹서버와 통신을 하기 위해 요청을 받아 동적인 응답을 해야하는데 해당 통신을 하기 위해 소켓을 만드는 역할을 한다.
셋째, request를 받을 때마다 스레드를 생성해 요청을 처리한다. 해당 스레드는 서블릿 컨테이너에서 스레드풀을 별도로 관리하여 실행하게 된다.
이 서블릿 컨테이너가 서블릿의 생명주기를 관리한다면 여기에 스프링 컨테이너는 그 이후 controller부터 동적인 처리에 사용된다.
Spring Container의 역할
우선 실행되는 시점에 대해서 정리해보자면 Servlet Container가 web.xml을 실행하면 거기에 등록되어 있는 contextLoaderListener에 의해 servlet-context.xml, root-context.xml이 실행이 된다. spring container가 생성이 되면서 빈 등록이 되어 있는 것들을 생성하여 컨테이너에 세팅을 해놓는다.
빈 등록은 xml에서 할 수도 있고, 애노테이션으로 설정해놓을 수도 있다. 이렇게 빈을 컨테이너에 등록을 해놓으면 개발할 때 객체를 일일이 생성할 필요없이 스프링이 의존성 주입을 해주고 좀 더 객체지향적인 개발이 가능할 수 있게 도와주는 장점이 있다.
spring framework 프로젝트를 생성해봤다면 servlet-context.xml과 applicationContext.xml을 본 경험이 있을 것이다.
applicationContext.xml이 곧 root-context.xml이며, servlet-context는 controller, handlermapping, viewResolver 등의 설정을 한다면, applicationContext.xml은 controller 아래에 service와 repository, datasource 설정 등을 할 수 있다.
위의 이미지는 spring 공식 사이트에서 제공한다.
그럼 request가 들어왔을 때 web server는 응답까지 어떻게 처리하고 있을지 그림으로 그려봤다.
1. DispatcherServlet은 web.xml에 등록되어 있고 최초 요청이 들어오면 생성된다. request를 받으면 DispatcherServlet이 가로채서 HandlerMapping에 어느 servlet이 처리해줄 수 있는지를 넘긴다.
2. HandlerMapping은 URL을 검색하여 처리해줄 수 있는 servlet을 찾아 DispatcherServlet에 넘긴다. (여기서는 servlet이 controller가 된다.)
3. HandlerAdapter가 request를 controller에 넘긴다.
4. Controller는 presentation 로직을 담당한다. 여기서 비즈니스로직을 처리할 service 빈이 autowired로 작성되어 있으면 컨테이너가 주입을 해준다. 호출되는 빈들은 로직대로 착챡챡 수행해준다.
5. Controller에서 응답을 DispatcherServlet에 주면 어느 View가 처리해줄지 ViewResolver에게 요청해서 ViewResolver가 View를 찾아서 준다.
6. Dispatcher가 WebServer에 응답을 주면 WebServer는 웹 브라우저에 최종 응답을 해준다.
학습 출처
- 웹을 지탱하는 기술
- https://taes-k.github.io/2020/02/16/servlet-container-spring-container/
- https://docs.spring.io/spring-framework/docs/current/reference/html/web.html
'Network & Web' 카테고리의 다른 글
| RESTful API는 어떻게 만들 수 있을까? (0) | 2020.11.29 |
|---|---|
| HTTP 메시지의 구조 (0) | 2020.11.27 |
| [웹을 지탱하는 기술] JSON (0) | 2020.11.25 |
| 메타데이터와 MIME미디어 타입 / XML과 HTML의 차이 (0) | 2020.11.25 |
