서블릿 (Servlet) 간단 정리

WAS를 직접 구현하는 경우 프로세스

1. 서버 연결 대기, 소켓 연결
2. HTTP 요청 메시지 파싱
3. HTTP 메서드, URL 확인
4. Content-Type 확인
5. HTTP 메시지 바디 내용 파싱
6. 메서드 프로세스 실행
7. 개발자가 개발한 비즈니스 로직 실행
8. HTTP 응답 메시지 생성 (HTTP 시작 라인, Header, 메시지 바디 생성)
9. 서버 응답 전달
10. 소켓 연결 종료

 

서블릿을 지원하는 WAS 사용할 경우

• 상단에 언급된 프로세스 중 비즈니스 로직 실행하는 프로세스 제외 모두 실행 (7번 제외 모두 실행)
• 즉, 개발자에게 편리성 제공

 

서블릿 특징

• urlPatterns 필드의 URL 호출할 경우 서블릿 코드 실행
• HttpServletRequest 객체를 통해 HTTP 요청 정보 편리하게 사용 가능
• HttpServletResponse 객체를 통해 HTTP 응답 정보 편리하게 사용 가능
• 정리하자면, 개발자가 HTTP 스펙을 편리하게 사용하도록 지원
• 추가적으로, 서블릿은 서블릿 컨테이너 내 싱글톤 객체로 존재

 

* HttpServletRequest 객체는 attribute 임시 저장, 조회 기능과 함께 세션 관리 기능 제공

 

 

 

서블릿 HTTP 요청 시 프로세스

• WAS가 Request, Response 객체를 새로 만들어 서블릿 객체 호출
• 개발자는 Request 객체에서 HTTP 요청 정보를 기반으로 Response 객체에 응답 정보 입력
• WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보 생성

 

 

서블릿 컨테이너

• 서블릿을 지원하는 WAS ex) Tomcat Server
• 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리 (https://www.javatpoint.com/life-cycle-of-a-servlet 참고)
• 동시 요청을 위해 멀티 쓰레드 처리 지원 (개발자가 멀티 쓰레드 관련 코드 신경 쓰지 않아도 됨)
• 서블릿 객체는 싱글톤으로 관리
  • 요청이 올 때마다 객체 생성하는 것은 비효율적이기 때문에 최초 로딩 시점에서 서블릿 객체를 미리 생성 후 재활용
  • 싱글톤으로 관리되기 때문에 공유 변수 사용 주의
  • 서블릿 컨테이너 종료 시 함께 종료

 

멀티 쓰레드 처리에 따른 장점

• 앞서 언급한대로 서블릿은 서블릿 컨테이너 내에서 싱글톤 객체로 관리
• 단일 쓰레드일 경우 여러 요청이 들어올 때 최초 요청이 처리될 때까지 다른 요청들은 대기를 해야 함
• 따라서, 웹 서비스 같이 TPS (Traffic Per Second)가 높은 서비스의 경우 동시 요청을 처리하기 위해 멀티 쓰레드 처리가 필수
• 멀티 쓰레드 처리 방법 두 가지
  • 요청마다 쓰레드 생성
  • 쓰레드 풀을 통해 쓰레드들을 미리 생성 후 관리

 

* 프로세스: 프로그램 실행하는 것

* 쓰레드: 프로그램 내 코드를 하나하나 순차적으로 실행하는 것

 

요청마다 쓰레드 생성할 경우 문제점

• 쓰레드 생성 비용 비싸기 때문에 요청 처리속도 저하
• 쓰레드는 생성 비용 뿐만 아니라 Context Switching 비용도 발생
• 쓰레드 생성에 제한을 두지 않을 경우 요청 많이 발생 시 서버 다운될 위험도 UP

 

* 이러한 단점들을 보안하기 위해 쓰레드 풀 도입

 

쓰레드 풀을 통해 쓰레드들을 미리 생성하는 방식

• 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 미리 생성한 후 관리 (Tomcat의 경우 디폴트 개수 200개)
• 쓰레드가 필요할 경우 이미 생성되어 있는 쓰레드를 풀에서 꺼내 사용 (생성 비용에 따른 처리속도 저하 방지)
• 사용을 종료하면 쓰레드 풀에 해당 쓰레드 반납 (쓰레드 제거하는 비용 없음)
• 요청이 많이 들어오더라도 최대 쓰레드 개수가 제한되어있기 때문에 요청을 대기 혹은 거절시키는 방식으로 서버 과부하 방지 가능

 

참고

인프런 스프링 MVC 1편 (김영한 강사님)