Spring 으로 Servlet 을 다룬다는 것

✏️ Servlet

Web Application 을 만들 때 필요한 interface 이다.

• Web Application 의 요청 응답 처리 과정

📍 Web Server 간략한 의 발전 과정

🔗 Servlet VS. Spring

• 초기 Web Server는 클라이언트의 요청에 대해서 정적인 페이지로만 응답할 수 있었다.
• 이후 Web Server 에 프로그램을 붙여서 동적인 페이지를 생성했다.
  • Servlet 도 동적인 페이지를 생성하기 위해 Web Server 에 붙이는 프로그램중 하나이다.

📍 Servlet 의 필요성

🔗 HTTP Message

• 기본적으로 PC 간의 통신은 HTTP Message 를 통해서 주고 받는다.
• 만약 Servlet 이 없다면 HTTP Message 를 개발자가 하나 하나 해석해 요청 내용을 파악하고,
  정보들을 파싱해 Business logic 을 수행하고 다시 HTTP Message 로 변환해 응답해야 한다.

• Servlet 이 요구하는 구현 규칙만 지켜주면 아주 편리하게 문제를 해결할 수 있다.
  • HttpServletRequest.getMethod();
  • 이 하나의 method 호출로 business logic 수행 전의 모든 준비가 끝난다.

✏️ Sevlet 의 작동 과정

⚠️ Servlet Container - Servlet 을 보관하고, 생명 주기를 관리하는 컨테이너

📍 기본적인 작동 방식

1. 클라이언트의 요청이 들어오면 Servlet Request / Response 객체 생성
2. Servlet Container 는 설정 파일을 참고해 해당 요청과 매핑된 Servlet 을 찾아 사용한다.
   • 매핑된 Sevlet 인스턴스 가 없다면 새로 생성한다.
3. Servlet Container 에 Thread 를 생성하고, Res, Req 를 인자로 Service logic 을 실행시킨다.
4. 응답을 마치면 처음에 생성한 Res , Req 객체를 소멸시키고 작동을 완료한다.
   • Servlet 은 Singletone 으로 관리되고 있기 때문에 Servlet 객체는 컨테이너에 반납시킨다.
   • 이후 같은 요청이 오면 다시 또 호출되 사용되게 된다.

📍 동시에 여러 요청이 발생할 경우

• 이 경우 Multi Thread 로 요청을 처리하게 된다.
• 아래 그림처럼 여러 Thread 를 통해 다른 요청을 처리할 수 있고,
  여러 Thread 에서 같은 요청을 처리할 수도 있다.

📍 Thread 사용의 주의점

• Thread 를 생성한다는 것 자체가 큰 비용이 따름
• 다른 Thread 로 전환하는 Context Swtich 가 많은 Overhead 를 일으킨다.
• Thread 생성에 제한을 두지 않으면 서버의 하드웨어의 한계를 넘을경우 서버가 터질 수도 있음

✏️ 프론트 컨트롤러 패턴

🔗 프론트 컨트롤러 패턴

• 모든 HTTP 요청을 받는 Controller 를 생성하고 공통된 처리를 모두 수행할 수 있게 만든다.
• Handler Mapping 정보와, Handler Adapter 목록을 확인해 알맞는 Adapter 와 Handler 를 찾는다.
• Business logic 을 갖고있는 Controller (Handler) 에게 요청이 전달되면 로직을 실행시키고 다시Front Controller 에게 전달한다.
• Front Controller 는 View Resolver 를 통해 논리 경로를 완전한 경로로 완성해 다시 반환한다.
• View 를 통해 HTTP 응답을 한다.

📍 Spring MVC

• Dispatcher Servlet 부터 Handler , View 까지 모든 로직은 이미 Framework 로 구현되어있다.
• 실질적으로 개발자가 신경써야 할 부분은 Business logic 이 담겨있는 Handler (Controller) 뿐이다.!