인터넷으로 주고 받는 데이터는 데이터 종류별로 특유의 방식으로 전달된다. 이걸 프로토콜(Prototal) 이라고 하는데 웹에서는 HTTP 라는 프로토콜을 사용해서 정보를 주고 받는다.
🖥️ (클라이언트) ➡️ 🌐(인터넷) ➡️ 🖥️ (서버)
클라이언트와 서버는 HTTP 메세지에 모든 것을 담아서 전송한다. 이미지, 영상, 텍스트 등 거의 모든 형태의 데이터를 전송할 수 있다.
⚠️ 서버는 역할에 따라 나뉘어진 여러 대의 컴퓨터들이다. 1종류의 서버가 여러 일을 하는게 아니다.
(웹 서버, 웹 애플리케이션 서버, DB 서버)
초창기 웹은 단순히 파일을 보여주는 용도였는데 웹이 발전하면서 단순히 파일만 보여주는게 아니라 로그인 처리, 회원마다 다른 화면을 보여주는 기능이 필요해졌다. 그래서 로직을 처리하는 서버가 따로 필요해지면서 만들어진 것이다.
프로그래밍을 통해서 사용자에 따라 다른 걸 보여줄 수 있게 됬다. 개발자가 코드를 코드를 입력해서 동작을 하게 하는 것들이 이 서버에서 사용된다.
크게 보면 웹 서버는 정적 리소스(파일) 이고 WAS 는 애플리케이션 로직 (비지니스로직, 흐름제어, 유효성 검사, 데이터 처리)
사실 웹 서버도 프로그램 실행하는 기능을 포함하기도 하고, WAS 도 웹 서버의 기능을 제공해서 경계가 모호함. 대신 WAS 는 애플리케이션 코드를 실행하는데 더 특화됐다고 볼 수 있음.
💡 이론상으로는 WAS, DB 만 있어도 시스템을 구성할 수 있다.
하지만 ‼️ 이렇게 되면 WAS 가 너무 많은 일을 담당해서 서버가 과부화 올 수 있다. 그래서 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려워 질 수 있다.
또 WAS 장애가 생기면 정적 리소스로 오류 화면을 송출할 서버도 없어진다. WAS 에는 개발자들이 개발하는 거라서 생각보다 자주 장애가 발생한다.
그래서 ‼️ 정적 리소스는 웹 서버가 처리하게 하고 애플리케이션 로직이 필요하면 WAS 에 넘기는 방식으로 진행하면 문제에 잘 대응할 수 있다. 또 따로 서버를 해두면 어떤 일을 더 많이 처리해야하는 경우 그 일을 하는 서버만 증설해서 효율적으로 리소스를 관리할 수 있다.
클라이언트가 서버에 HTTP 메세지를 요청하면 서버는 이 메세지를 처리할 수 있도록 여러 작업을 거쳐서 개조를 해야 요청을 처리할 수 있다. 이 과정은 웹 요청 마다 같은 작업이기 때문에 매번 개발자들이 코드를 만드는 건 비효율적이다.
예 ) 서버 TCP/IP 대기, 소켓 연결, 요청 메세지 파싱해서 읽기, 데이터 사용할 수 있게 파싱 등...
그래서 WAS 가 제공하는 서블릿 이라는 걸 통해서 자동 처리 ‼️ 이 서블릿을 사용하면서 중요한 비지니스 로직에 더 집중할 수 있게 된다.
HttpServletRequestHttpServletResponse요청 도착: 웹 브라우저가 HTTP 요청 메시지를 보냄.
객체 생성 (WAS의 역할): WAS가 요청을 받고 request, response 객체를 생성함.
서블릿 호출: WAS가 생성한 이 두 객체를 서블릿의 service() 메서드 파라미터로 넘겨주며 호출함.
로직 실행 (서블릿의 역할): 서블릿은 전달받은 request에서 데이터를 꺼내 쓰고, 결과를 response에 담음.
응답 전송: 서블릿 작업이 끝나면 WAS가 response 객체에 담긴 내용을 다시 HTTP 응답 메시지로 변환해서 브라우저로 보냄.
객체 소멸: 응답이 끝나면 WAS는 소임을 다한 request, response 객체를 삭제함.
서블릿을 지원하는 WAS 에는 '서블릿 컨테이너'가 존재한다.
서블릿 컨테이너는 서블릿 객체를 생성, 호출, 생명주기를 관리한다. 톰캣이 이 서블릿 컨테이너 중 하나다. 서블릿 객체는 싱글톤으로 관리하며 공유 변수 사용에 주의해야 한다. 또 동시 요청을 위한 멀티 쓰레드 처리를 지원해준다.
서블릿 객체는 기능별로 생성된다. 여러 클라이언트가 사용할 때 해당 기능마다 쉽게 요청을 처리할 수 있게 돕는 기능이라 같은 기능이면 하나의 객체로 재사용해서 한다.