[대중적인 웹 시스템]
클라이언트 -> 웹 서버(정적 콘텐츠) -> 웹 어플리케이션 서버(앱 로직) -> DB
- 멀티 쓰레드에 대한 부분은 WAS 가 처리
[서블릿]
HTTP 통신을 사용하는 웹 생태계에서 HTTP 요청과 응답 사이의 비즈니스 로직을 수행하는 것을 제외하고
연결 확인 및 파싱 등의 번거로운 작업을 대신해주는 존재
- 동시 요청을 위한 멀티 쓰레드 처리 지원
- 서블릿 생성시 HTTP 요청 객체, HTTP 응답 객체를 생성
- HttpServletRequest 객체에는 HTTP 요청이 시작부터 끝날 때까지 유지되는 임시 저장소 기능을 제공
[서블릿 컨테이너]
- 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리
- 서블릿은 싱글톤으로 관리
[멀티 쓰레드]
장점
- 동시 요청 처리 가능
- 리소스가 허용할 떄 까지 처리가능
- 하나의 쓰레드가 지연되어도, 나머지 쓰레드는 정상 동작
단점
- 쓰레드 생성 비용이 매우 비싸다
- 쓰레드는 컨텍스트 스위칭 비용이 발생
- 쓰레드 생성에 제한이 없다. -> 고객 요청이 너무 많이 오면, CPU, 메모리 임계점을 넘어서 서버가 죽을 수 있다.
이러한 단점을 해결하기 위해, 쓰레드 풀을 활용 -> 미리 생성되어 있는 쓰레드를 꺼내서 사용
[쓰레드 풀]
특징
- 필요한 쓰레드를 쓰레드 풀에 보관하고 관리
- 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리, 톰캣은 최대 200개 기본 설정(변경 가능)
사용
- 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드르 쓰레드 풀에서 꺼내서 사용
- 사용을 종료하면 쓰레드 풀에 해당 쓰레들 반납
- 최대 쓰레드가 모두 사용중이면, 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정 가능
장점
- 쓰레드가 미리 생성되어 있으므로, 쓰레드르 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
- 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.
[HTTP 요청 방법]
1. GET - URL 에 쿼리 파라미터 사용
2. POST - html form 에서 HTTP 바디에 쿼리 파라미터 사용
3. HTTP BODY - JSON 등의 형식을 사용
HTML Form 은 GET 처럼 쿼리 파라미터를 파싱해서 처리해주면 되지만,
GET 과 달리 메세지 바디를 사용하기 때문에 해당 데이터가 어떤 형식인지 알려주기 위해
'application/x-www-form-urlencoded' content-type 을 헤더에 붙여줘야 한다.
[HttpServletResponse]
- HTTP 응답 메세지 생성
1. HTTP 응답코드 지정
2. 헤더 생성
3. 바디 생성 - 편의 기능 제공
- content-type
- cookie
- redirect
[MVC]
Controller : HTTP 요청 받고, 비즈니스 로직 처리
Model : 비즈니스 로직 처리 후 뷰에 보여질 데이터만 담긴 것
View : 뷰 로직 담당
Servlet 의 HttpServletRequest 객체가 가진 임시 저장소를 Model 로 활용할 수 있다.
dispatcher 의 forward 와 http redirect 의 차이
리다이렉트는 실제 클라리언트/웹 브라우저 에 응답이 나갔다가, 클라이언트가 redirect 경로로 요청,
따라서 클라이언트가 인지할 수 있고, URL 경로로 실제로 변경된다.
반면에 forward 는 서버 내부에서 일어나느 호출이기 때문에 클라이언트가 전혀 인지하지 못한다.
[MVC 패턴의 한계]
각 요청마다의 비즈니스 로직을 처리해주는 서블릿을 컨트롤러로 만들면,
요청의 종류가 많아질수록 코드의 중복 또한 많아지게 된다.
그러면 자연스럽게 공통적으로 처리해야 되는 부분들을 관리하기 어려워지는 것도 따라온다
이러한 한계를 극복하기 위해서는, 비즈니스 로직 처리 이전에 공통 처리 부분을 담당해줄 FrontController(공통 모듈) 패턴을 활용
- FrontController 는 공통 처리 기능 제공
- HTTP 요청의 입구를 하나로 통일
- 요청에 맞는 컨트롤러를 찾아서 호출
- FrontController 를 제외한 컨트롤러들은 서블릿을 사용하지 않아도 됨
그리고 이 FrontController 가 Spring MVC 의 DispatcherServlet 임
- url 매핑 정보에서 컨트롤러 조회
- 일반 컨트롤러로부터의 view 반환을 담당(공통 처리)
[Spring MVC]
동작 순서
1. 핸들러 조회 : 핸들러 매핑을 통해 요청 URL 에 매핑된 핸들러(컨트롤러)를 조회한다.
2. 핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터 실행 : 핸들러 어댑터를 실행한다.
4. 핸들러 실행 : 핸들러 어댑터가 실제 핸들러를 실행한다.
5. ModelAndView 반환 : 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView 로 "변환"해서 반환한다.
6. viewResolver 호출 : 뷰 리졸버를 찾고 실행한다.
JSP 의 경우 : InternalResourceViewResolver 가 자동 등록되고, 사용된다.
7. View 반환: 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 뷰 객체를 반환한다.
JSP 의 경우 : InternalResourveView(JstlView) 를 반환하는데, 내부에 forward() 로직이 있다.
8. 뷰 렌더링 : 뷰를 통해서 뷰를 렌더링 한다.
주요 인터페이스 목록
핸들러 매핑 : HandlerMapping
핸들러 어댑터 : HandlerAdapter
뷰 리졸버 : ViewResolver
뷰 : View
