웹 서버, 웹 애플리케이션 서버
- 웹 서버는 정적 리소스, WAS는 애플리케이션 로직
웹 시스템 구성 - WEB, WAS, DB
- 정적 리소스는 웹 서버가 처리
- 웹 서버는 동적인 처리가 필요하면 WAS에 이를 위임
- WAS는 중요한 애플리케이션 로직 담당
서블릿
- HTTP 요청 시
- WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출
- 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용
- 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력
- WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성
- 서블릿 컨테이너
- 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함
- 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
- 서블릿 객체는 싱글톤으로 관리
- 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율
- 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용
- 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근
- 공유 변수 사용 주의
- 서블릿 컨테이너 종료시 함께 종료
- JSP도 서블릿으로 변환 되어서 사용
- 동시 요청을 위한 멀티 쓰레드 처리 지원
동시 요청 - 멀티 쓰레드
쓰레드
- 애플리케이션 코드를 하나하나 순차적으로 실행하는 것은 쓰레드
- 자바 메인 메서드를 처음 실행하면 main이라는 이름의 쓰레드가 실행
- 쓰레드가 없다면 자바 애플리케이션 실행이 불가능
- 쓰레드는 한번에 하나의 코드 라인만 수행
- 동시 처리가 필요하면 쓰레드를 추가로 생성
요청 마다 쓰레드 생성의 장단점
- 장점
- 동시 요청을 처리할 수 있다.
- 리소스가 허용할 때 까지 처리가능
- 하나의 쓰레드가 지연 되어도, 나머지 쓰레드는 정상 동작한다
- 단점
- 쓰레드는 생성 비용이 매우 비싸다
- 쓰레드는 컨텍스트 스위칭 비용이 발생한다.
- 쓰레드 생성에 제한이 없다. -> 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.
쓰레드 풀
- 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다.
- 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
- 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 풀에서 꺼내 사용
- 사용을 종료하면 풀에 해당 쓰레드를 반납
서블릿과 jsp의 한계
- 서블릿으로 개발할 때는 뷰 화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여 지저분함.
- JSP를 사용한 덕분에 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분에만 자바 코드를 적용했다. 하지만, 이렇게 해도 몇가지 문제가 있다. JAVA 코드, 데이터를 조회하는 리포지토리 등등 다양한 코드가 JSP에 노출되어 있다.
유지보수가 정말 힘들다.
MVC 패턴의 등장
비지니스 로직은 서블릿 처럼 다른곳에서 처리하고, JSP는 목적에 맞게 HTML로 화면을 그리는 일에만 집중하도록 만들었다.
MVC 패턴은 컨트롤러와 뷰 라는 영역으로 서로 역할을 나눈 것을 말한다.
컨트롤러 : HTTP 요청을 받아서 파라미터를 검증하고, 비지니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
모델 : 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링하는 일에만 집중할 수 있다.
뷰 : 모델에 담겨져 있는 데이터를 사용해서 화면을 그리는 데에 집중한다. HTML을 생성하는 일을 말한다.
MVC 패턴 1
MVC 패턴 2
redirect vs dispatch
리다이렉트는 실제 클라이언트(웹 브라우저)에 응답이 나갔다가, 클라이언트가 redirect 경로로 다시 요청한다.
따라서 클라이언트가 인지할 수 있고, URL 경로도 실제로 변경된다.
반면에 포워드는 서버 내부에서 일어나는 호출이기 때문에 클라이언트가 전혀 인지하지 못한다.
'스프링' 카테고리의 다른 글
| 스프링 핵심 원리 - 기본 (0) | 2021.07.24 |
|---|