웹 서버와 WAS의 차이를 살펴보자

목차

1. 웹 서버
2. 클라이언트 사이드 랜더링 (CSR)
3. 서버 사이드 랜더링 (SSR)
4. CSR
5. SSR
6. 웹 어플리케이션 서버 WAS

 

 

웹 서버

클라이언트가 웹 브라우저에서 어떠한 페이지 요청을 하면 웹 서버에서 그 요청을 받아 정적 콘텐츠를 제공하는 서버이다.

여기서 정적 콘텐츠란 단순HTML 문서, CSS, javascript, 이미지, 파일 등 즉시 응답가능한 컨텐츠이다.

 

우리가 만든 웹 페이지를 배포하면 해당 파일들은 웹 서버에 올라가고 주소창에 url을 입력하면 프론트 서버에 저장된 파일들을 전송받아서 웹페이지를 불러오게 된다.

 

웹서버는 더 상세히 살펴보자

클라이언트 사이드 랜더링 (CSR)

 

서버 사이드 랜더링 (SSR)

 

CSR

CSR(Client-side rendering)은 말 그대로 클라이언트측에서 렌더링을 하는 것을 의미한다.
클라이언트에서 서버로 요청을 보내면, 서버는 저장해 둔 HTML, CSS, JS를 전송해준다.
그러면 클라이언트측에서 그 파일들을 받아서 렌더링을 진행하는 것.

 

랜더링 특징

CSR 방식에서 웹서버(프론트서버)는 아주 단순히, 올려놓은 파일을 전달해주는 전달자 역할만 한다.
처음에 JS를 실행하면서 모든 페이지를 렌더링하는데, 이로 인한 딜레이때문에 첫 페이지 로딩 시간이 느리다.
반면, 이후의 나머지 페이지 전환이 빠른 편. (필요한 부분의 데이터만 서버에서 JSON으로 받아오면 된다)

 

SPA

페이지는 하나의 HTML 파일이라고 생각하면 편할 듯.

유저 입장에서는 단순히 화면의 내용이 확 바뀌고 URL이 달라지면

이전과 다른 페이지라고 인식한다는 점을 이용한 일종의 트릭으로 생각하면 편하다.

페이지는 하나인 채로, JS를 이용하여 컨텐츠를 바꾸고 URL을 강제로 변경함으로써 다른 페이지인 척 하는 것.

궁합이 잘 맞아 CSR의 구현 방식으로 사용

 

 

SSR

SSR(Server-side rendering)은 프론트서버에 HTML, CSS, JS 파일을 직접 올리지 않는다.
대신, 해당 파일들을 만들어낼 수 있는 로직을 올리고 서버에서 해당 로직을 실행한다.
그 결과로 생성된 '바로 렌더링할 수 있는 HTML 파일'을 클라이언트로 전송하게 되고,
클라이언트는 그 파일을 받아서 바로 렌더링하기 때문에 페이지가 즉시 보여지게 된다.
이후 JS 파일을 받아서 실행을 마치면 상호작용이 가능하게 된다

 

 

랜더링 특징

.SSR 방식에서 웹서버는 단순한 전달자 역할이 아닌, 렌더링 결과물을 생성하는 로직을 구동하는 역할을 한다.
브라우저가 이미 구성이 완료된 HTML 파일을 받기 때문에 첫 페이지 로딩 속도가 CSR보다 빠르다.
반면, 페이지를 이동할 때마다 서버에서 처리된 HTML 파일을 매번 받아와야 하기 때문에
매번 서버에서 로직을 실행하는 비용이 추가되고, 이로 인해 페이지 전환이 느리다.

 

 

MPA

Multi Page Application이고, 여러 개의 페이지로 구성된 웹 어플리케이션이다.

하이퍼링크를 클릭하면 실제로 페이지를 이동한다.

화면이 새로고침되고, URL에 맞는 HTML, JS, CSS를 전송받아 페이지가 로드된다.

궁합이 잘 맞아 SSR의 구현 방식으로 사용

 

 

 

웹 어플리케이션 서버 WAS

WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로서, 웹 서버 단독으로는 처리할 수 없는 데이터베이스의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다.

 

 

그렇다면 WAS가 Web Server의 기능도 모두 수행하면 되지 않을까?

 

기능을 분리하여 서버 부하 방지
WAS는 DB 조회나 다양한 로직을 처리하느라 바쁘기 때문에 단순한 정적 컨텐츠는 Web Server에서 빠르게 클라이언트에 제공하는 것이 좋다.

물리적으로 분리하여 보안 강화
SSL에 대한 암복호화 처리에 Web Server를 사용

 

여러 대의 WAS를 연결 가능

• Load Balancing을 위해서 Web Server를 사용
• fail over(장애 극복), fail back 처리에 유리
• 특히 대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
• 예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

여러 웹 어플리케이션 서비스 가능
예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우