모든 웹 브라우저는 HTTP 기반으로 이루어져있다.
그러므로 모든 데이터를 HTTP에서 주고받는다고 생각하면된다.
클라이언트는 HTTP로 서버에 데이터를 요청하고 서버에서는 HTTP로 응답한다.
서버간의 통신에서도 마찬가지로 HTTP를 사용한다.
웹 서버(Web Server)
- HTTP 기반으로 동작
- 정적 리소스 제공, 기타 부가기능
- 정적(파일), HTML, CSS, JS, 이미지, 영상
- 예) NGINX, APACHE
웹 애플리케이션 서버(WAS - Web Application Server)
- HTTP 기반으로 동작
- 웹 서버 기능 포함, 정적 리소스 제공 가능
- 프로그램 코드를 실행해서 애플리케이션 로직을 수행할 수 있도록 한다.
- 동적 HTML, HTTP API(JSON)
- 서블릿, JSP, 스프링 MVC
- 예) 톰캣(Tomcat), Jetty, Undertow
둘의 차이는 무엇일까?
- 웹 서버는 리소스, WAS는 애플리케이션 로직이다.
- 둘의 용어도 경계도 모호하다.
- 웹 서버도 프로그램을 실행하는 기능을 포함하기도 한다.
- 웹 애플리케이션 서버도 웹 서버의 기능을 모두 가지고 있다.
- 자바는 서블릿 컨테이너 기능을 제공하면 WAS
- 서블릿 없이 자바 코드를 실행하는 서버 프레임워크도 있음.
- WAS는 애플리케이션 코드를 실행한느데 더 특화
웹 시스템 구성 - WAS, DB
- 실무에서는 WAS, DB만으로도 시스템 구성이 가능하다.
- WAS는 정적 리소스, 애플리케이션 로직 모두 제공 가능하다.
- 그 결과 WAS가 너무 많은 역할을 담당하게 된다. 즉, 서버 과부하가 생길 수 있다!
- 애플리케이션 로직은 비싸다. 상당히 많은 네트워크를 요구하는데 그것이 정적 리소스 때문에 수행이 어려울 수 있다.
- WAS 장애시 오류 화면조차도 노출 불가능하다.(실제로 WAS가 잘 죽는다고 표현한다.)
일반적인 웹 시스템 구성 - WEB, WAS, DB
- 정적 리소스는 웹 서버가 처리
- WAS는 중요한 애플리케이션 로직 처리 전담
- 웹 서버는 WAS가 필요하면 요청을 위임
- 위의 단점을 모두 해소할 수 있는 방식이다. 실무에서 자주 사용한다.
- 또한 시스템 리소스를 굉장히 효율적으로 사용할 수 있다.
- 정적 리소스가 많이 필요하다면 WEB서버를 증축하고 애플리케이션 로직이 더 많이 사용되면 WAS를 증축한다.
- 웹 서버는 오류가 쉽게 발생하지 않는다.
- WAS에서 오류가 발생해도 웹 서버에서 오류 화면을 보여줄 수 있도록 설정할 수 있다.
- API서버만 제공하고 화면을 제공하지 않는 데이터만 주고 받는 상황에서는 WAS만 구축해도 괜찮다.
정처기 준비로 바쁘기도 하고 최근 취업에 성공해서 짧게 하려한다. 다음은 서블릿을 설명해보겠다!
출처 : 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술(인프런, 김영한 강사님)
비전공자 개발초보입니다!