Spring MVC : 서블릿 간략 정리

들어가면서

---

먼저 HTML Form 형태로 입력받은 데이터를 서버에 전송해야하는 상황을 가정해보자. 이 때, HTML Form 코드와 여기 들어온 입력이 HTTP 요청 메세지로 바뀐 것을 확인하자. 이 때 HTML FORM에서 HTTP 요청 메세지로 바꿔주는 것은 웹 브라우저가 해준다. 

직접 WAS를 개발자가 구현

HTTP 요청 메세지는 서버에 전달된다. 서버는 이 HTTP 요청 메세지를 받고 어떤 일을 해야할까? HTTP 요청 메세지를 서버에서 처리하기 위해서는 서버는 기본적으로 오른쪽에 있는 일들을 모두 해야한다. TCP/IP 연결시켜주고, 요청 메세지를 파싱해서 읽고, Content-Type도 확인해야한다. 그리고 비즈니스 로직을 실행하고 응답 메세지를 만들어서 클라이언트에 전달해줘야한다.

서블릿을 지원하는 WAS

현실적으로 서버가 해야하는 모든 과정들을 개발자가 하나하나 구현해주는 것은 너무나 힘든 일이다. 개발자는 핵심 비즈니스 로직을 구현하는 것에만 집중하면 좋지 않을까? 그래서 WAS는 서블릿을 제공해주고 있다. 

서블릿을 제공하는 WAS는 여러가지 사족처럼 달린 많은 일들을 고민하지 않아도 된다. 개발자는 오로지 비즈니스 로직만 심혈을 기울여서 만들면 된다. 그렇다면 서블릿은 무엇일까?

 

서블릿의 특징

---

서블릿은 개발자들이 편하게 개발할 수 있도록 구현된 클래스다. 특정 클래스를 서블릿으로 만들어서 사용한다. 서블릿의 특징은 아래와 같이 정리할 수 있다. 

• @WebServlet 어노테이션으로 해당 클래스를 서블릿으로 선언한다.
• 맵핑된 URL이 호출되면, 서블릿 코드가 실행된다(Service 코드)
• Serivce 코드는 동일하게 작성해야한다.
• 서블릿은 HttpServletRequest, HttpServletResponse 객체를 제공한다. 이를 통해 HTTP 스펙 편리하게 관리 가능하다.

 

WAS 서버(Tomcat 서버)는 서블릿 컨테이너를 가지고 있고, WAS가 올라갈 때 서블릿 컨테이너에 모든 서블릿을 하나씩 생성해서 싱글톤 형태로 가지고 있는다. 서블릿 컨테이너는 요청이 오면 다음과 같은 형태로 응답까지 처리가 된다.

1. HTTP 요청이 WAS로 전달된다.
2. WAS는 서블릿 객체를 호출하면서 Request, Response 객체를 만들고 매개변수로 전달한다.
3. 개발자는 서블릿 안에서 편리하게 비즈니스 로직을 실행한다.
4. WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성해서 응답해준다. 
5. 클라이언트는 HTTP 응답 정보를 파싱해서, HTML로 랜더링해서 사용자에게 보여준다. 

 

서블릿 컨테이너

---

Tomcat 같은 WAS는 서블릿 컨테이너를 가지고 있다. 이 서블릿 컨테이너는 서블릿을 생성 및 호출하고, 생명주기를 관리해준다. 서블릿 컨테이너에 대한 내용을 간략히 정리해보면 아래와 같다.

• 서블릿 컨테이너는 서블릿 객체를 생성, 호출, 생명주기 관리를 관리함.
• 서블릿 객체는 싱글톤으로 관리됨
  • 요청은 다른 정보를 가지고 오기 때문에 Response, Request 객체는 요청올 때 마다 생성됨. 서블릿 객체는 항상 싱글톤으로 사용되며, 비즈니스 로직만 제공하면 됨. 
  • 서블릿은 최초 로딩 시점에 만들어져서 서블릿 컨테이너에서 관리됨.
  • 서블릿 컨테이너가 종료될 때 함께 소멸됨.
  • 공유 변수 사용은 주의해야함. 
• JSP도 서블릿으로 변환되어서 사용됨.
• 동시 요청을 위한 멀티 쓰레드 처리를 지원함.

WAS(서블릿 컨테이너)는 동시 요청을 위한 멀티 쓰레드 처리를 지원한다. 멀티 쓰레드는 결국 WAS 안에 쓰레드풀 형태로 만들어져서, 동시에 처리 가능한 요청의 한계치를 가진다. 그렇지만 쓰레드풀 형태가 지원되기 때문에 동시에 많은 요청이 오더라도, 이것들을 처리할 수 있다.