일반적인 웹 서버
- 클라이언트로부터 요청이 오면 가장 앞단에서 해당 요청에 대한 처리를 수행하고 응답을 반환하는 역할
- HTTP 요청을 받아들이고
HTML
,이미지 파일
,CSS
같은 정적 컨텐츠를 반환한다. - 정적 컨텐츠(html, png, css 등)는 직접 제공이 가능하지만 DB등을 참조해야 하는 동적 컨텐츠는 WAS의 도움이 필요하다.
- 대표적인 웹 서버 :
Apache
,NGINX
정적 컨텐츠구나! 내가 제공해줄게 → html, png 등을 Response에 담아 반환
정적 컨텐츠가 아니네! 웹서버에서 간단히 처리하지 못하겠군. WAS에게 처리를 부탁해야겠다
→ WAS가 처리해준 데이터를 받아 와서 Response에 담아 반환
웹 어플리케이션 서버(WAS, Web Application Server)(앱서버)
- 동적 컨텐츠(DB조회, 비즈니스 로직 처리가 요구되는 컨텐츠)를 제공하기 위해 만들어진 서버
- 주로 데이터베이스 서버와 함께 가동된다.
- 웹서버와 WAS의 용어 경계가 명확한 것은 아니다 : WAS가 웹서버의 기능을 포함하는 경우가 많음
JSP
,Servlet
구동 환경을 제공한다.
컨테이너
,웹 컨테이너
,서블릿 컨테이너
라고도 불린다.
- 대표적인 WAS :
Tomcat
,Jeus
,JBoss
- SpringBoot 는 Tomcat을 내장하고 있다!
- 별다른 WAS 설정 없이도 서버를 구동할 수 있다.
- 웹서버와 앱 사이의 동적인 정보를 생성하는 역할을 담당하는 미들웨어
- 웹서버는 앱을 알지 못하고, 반대로 앱은 웹서버를 알지 못한다.
- WAS가 웹서버와 앱 사이에서 중간다리 역할을 해주는 것!
- 예)
Tomcat
은 웹을 통해 들어온HTTP request
를java
언어로 변환하여 앱에 전달하고, 앱에서 생성된java
응답을 다시HTTP request
로 변환하여 웹서버로 전달해주는 역할을 수행한다.
WAS만 있어도 서버 구동은 가능하잖아?
- 사실 WAS와 DB만 있으면 당장 서비스 제공이 가능하다.
- WAS는 정적 리소스, 어플리케이션 로직 모두 핸들링 가능하기 때문
- 실제로 API 만 제공한다면 WAS 만 구축하기도 한다.
- 하지만 이렇게 되면 WAS가 너무 많은 일을 담당하게 된다.
- 앱 로직도 실행해야 되고, 정적 컨텐츠도 제공해줘야 되고…
- 정작 중요한 어플리케이션 로직이 정적 리소스를 제공하느라 바빠서 속도가 느려진다면?
- 로직을 잘못 짰거나 디비에 오류가 생겨서 WAS가 죽는다면? 오류 화면 조차 확인이 불가능
- 그래서 일반적으로는
client → Web Server(정적 리소스 처리) → WAS(동적 리소스/로직 처리) → 디비
식으로 아키텍처를 구성한다. 시스템 리소스를 효율적으로 처리할 수 있음.
- 또한 웹서버를 사용하면, 웹서버가 제공해주는 다양한 기능을 활용할 수 있다.
- 예)
NGINX
= 동시 접속 처리에 특화된 웹서버 이 밖에 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등 유용한 여러 역할을 수행한다.
웹서버 + WAS의 동작 프로세스

- 클라이언트가 웹 페이지로 요청을 보내면, 웹서버가 해당 요청을 받아 필요한 부분을 WAS에 요청한다.
- WAS(컨테이너)는 web.xml 을 참조하여 해당 서블릿의 작업을 담당하는 쓰레드를 생성한다.
httpServletRequest
와httpServletResponse
객체를 생성한 다음- 서블릿을 호출하고, 생성한 객체를 전달한다.
- 호출된 서블릿의 작업을 담당하는 쓰레드는
- Request에 따라
doPost
또는doGet
메소드를 호출해 데이터를 생성하고, - 이것를
Response
객체에 담아 다시 WAS 컨테이너에 전달한다.
- WAS 컨테이너는 전달받은
Response
객체를HTTPResponse
형태로 바꿔 웹서버에 전달하고, 생성되었던 쓰레드를 종료한 다음httpServletRequest
,httpServletResponse
객체를 소멸시킨다.
- 프록시 서버 (캐싱)
- Client와 WebServer 사이에 프록시 서버가 존재할 수 있다.
- 자주 조회되는 정보는 프록시 서버에 캐싱하여 빠르게 접근할 수 있다.