▶ Servlet이 나온이유
- 초기 웹 서비스는 정적데이터만 전달 할 수 있었다.
- 사용자(요청)에 따라 다른 처리를 해줄 수 없었다.
- 동적인 처리를 해주는 웹 애플리케이션이 없었다.
▷ 그래서 나온것이 CGI(Common Gateway Interface)
- CGI는 동적데이터를 처리해준다.
- Web Server와 프로그램사이의 규약이다.
- 점점 CGI사용자가 증가하기 시작했다.
- 근데 CGI에는 몇가지 비효율적요인이 있었다.
▷CGI의 비효율성
1. Request를 받을 때 마다 Process를 만든다.
- 같은 요청에도 프로세스를 생성해서 처리하는 구조는 상당한 비효율성을 낳았다.
- 요청이 엄청나게 들어오면 프로세스가 순식간에 늘어나고 서버가 죽어버리게 된다.
- 코드와 공유 데이터 정적인 영역은 공유하고, 스택과 힙 공간과 같이 동적인 영역을 별도로 가지는 스레드 처리의 필요성을 느끼게 된다.
Process에서 Thread로!
2. Thread마다 CGI구현체가 생긴다.
해결! 여러 Instance에서 Singleton으로
▶ CGI의 문제점들을 보완하여 Servlet 탄생!
Servlet은 인터넷의 트래픽이 급격하게 상승하던 시기 CGI를 구현한 다른 프로그램의 비효율성을 개선하기 위해
자바 프로그래밍 언어로 구현된 CGI 프로그램이다.
한번 더 풀어서 설명하면
동적 웹 페이지를 만들 때 사용되는 자바 기반의 웹 애플리케이션 프로그래밍 기술이다.
서블릿은 웹 요청과 응답의 흐름을 간단한 메서드 호출만으로 체계적으로 다룰 수 있게 해준다.
▷ Web(Servlet) Container란?
- Request가 들어오면 Thread를 생성해준다.
- Servlet을 실행시킨다.
- Servlet Interface에 따라 Servlet을 관리한다.
- 한마디로 개발자대신 Servlet을 관리해주는 친구이다.
▷ Servlet Interface란?
- 서블릿 컨테이너가 서블릿에 대해 호출할 메서드를 정의한 것이 Servlet 인터페이스이다.
서블릿의 생명주기와 관련된 메서드: init(), service(), destroy()
- 서블릿의 생성과 실행, 소멸, 즉 생명주기와 관련된 메서드
구분설명
init() | 서블릿 컨테이너가 서블릿을 생성한 후 초기화 작업을 수행하기 위해 호출하는 메서드 |
service() | 실질적으로 서비스 작업을 수행하는 메서드 |
destroy() | 서블릿 컨테이너가 종료되거나 웹 애플리케이션이 멈출 때, 또는 해당 서블릿을 비활성화 시킬 때 호출하는 메서드 ex) 자원의 해제, 데이터 저장, 마무리 작업 |
▶Servlet을 사용할 때 이점
▷Servlet을 사용하지 않았을 때
기본적으로 웹 어플리케이션 요청을 보내기 위해서 우리는 HTTP규약에 따른 요청을 해야하고,
이를 기반으로 한 HTTP 메시지를 통신을 하게된다.
이런식의 HTTP 메시지를 통해서 요청을 하게 된다.
이렇게 보낸 메시지를 서버에서 응답받으면,
각 의미에 맞게 파싱을하여 응답을 처리하고
결과에 맞게 응답 HTTP메시지를 만들어서
클라이언트에게 전달하게 되는 방법으로 요청이 처리된다.
하지만 개발자가 일일히 요청값을 파싱해서 분석하고
응답메시지를 만들어주는 작업은 번거롭고 반복되는 작업이다.
▷Servlet을 사용하면?
Servlet은 개발자가 이러한 파싱 작업을 일일히 하지 않더라도
API를 통해서 제공받을 수 있도록
이렇게 많은 기능들을 제공하고 있다.
또한 HTTP Method에 대한 분기처리도 각 요청별로 대신 처리해준다.
요청을 처리하기 위해 호출되는 메서드인 service()를 보면
각 메서드가 분기처리 되어있는걸 확인할 수 있다.
즉, 개발자는 이러한 요청들을 처리해주는 메서드를 재정의 하고
API를 사용한 뒤 요청받을 URL만 매핑해주면
우리가 원하는 비지니스 로직을 작성하고 수행할 환경을 제공받을 수 있게된다.
▶Servlet 작동 방식
웹브라우저가 WAS에게 서블릿 요청
-> WAS는 HttpServletRequest 객체를 생성하여 저장
응답을 보낼 때 사용하기 위해 HttpServletResponse 객체 생성
-> Servlet에게 두 객체 전달
-> doGet, doPost, Service 등과 같은 메서드에 파라미터로 전달되어 사용됨
▷ HttpServletRequest
- http프로토콜의 request정보를 서블릿에게 전달하기 위해 사용
- 헤더정보, 파라미터, 쿠키, URI, URL 등의 정보를 읽어 들이는 메소드 포함
- Body의 Stream을 읽어 들이는 메소드 포함
▷HttpServletResponse
- 요청을 보낸 클라이언트에게 응답을 보내기 위해 WAS에서 생성되어 서블릿에게 전달됨
- 서블릿은 이 객체를 이용하여 content type, 응답코드, 응답 메시지등을 전송
▷web.xml파일
Web Container가 가지는 설정파일이다.
WAS한테 "Servlet객체 - URL" Mapping 정보를 알려준다.
- URL마다 Servlet이 생긴다.
- Servlet을 Web Container에게 알려주기 위해서 web.xml의 URL과 Servlet을 Mapping한다.
- /line 이라는 request가 오면 LineServlet의 각각 Http Method에 맞는 Method를 불러주게 된다.
- 위치는 WEB-INF 폴더 아래에 있다.
- web.xml파일의 설정들은 시작시 메모리에 로딩된다.
▶Servlet의 문제점?
그림에서처럼 Servlet은 각 요청마다 하나의 Servlet이 1:1로 매핑되는 구조를 가지고있어
만약 20개의 요청이 있으면 10개의 서블릿이 존재한다.
그렇게 되면 서블릿마다 공통되게 실행되는 로직이 매번 반복해서 생성되고 실행되게 된다.
이렇게 중복되는 부분이 많게되면 Servlet에 종속적인 구조를 가지게되고,
이후 각 컨트롤러에서 공통으로 처리해야하는 로직이 생기면 중복이 발생한다.
이러한 문제를 어떻게 해결할 수 있을까?
다음시간에...
'BackEnd > Spring Boot🍃' 카테고리의 다른 글
[Spring]Spring MVC 요청에서 응답까지의 흐름, @Controller와 @RequestMapping 원리 (0) | 2024.03.24 |
---|---|
[Spring] Servlet과 Spring Web MVC(2) (0) | 2024.03.23 |
[Spring Boot] 스프링부트 개념정리 (1) | 2024.02.24 |
[Spring Boot] 코드프레소님 Spring Boot 강의 정리(유데미){2} (1) | 2024.02.24 |
[Spring Boot] 코드프레소님 Spring Boot 강의 정리(유데미){1} (0) | 2024.02.24 |