웹은 다 HTTP 기반으로 통신을 한다.
웹 브라우저에서 URL을 치면
인터넷을 통해서 서버에 접근을 하고
서버에서는 HTML을 만들어서 클라이언트에게 내려주면
웹브라우저가 받은 HTML로 우리에게 보여준다.
그런데 클라이언트에서 서버로 데이터를 전송할때
서버에서 클라이언트로 데이터를 응답할때
이때 다 http 기반으로 동작하게 된다.
모든것이 Http를 기반으로 데이터를 주고 받는다.
HTML, Text, Image, 음성, 영상, 파일, JSON, XML, API ...
거의 모든 형태의 데이터를 전송 가능하다.
서버간에 데이터를 주고 받을때도 HTTP를 대부분 사용한다.
웹 서버란?
HTTP 기반으로 동작한다.
정적 리소스와 기타 부가기능을 제공한다.
정적 리소스라는것은 특정 폴더 디렉토리에 이미지 영상 등등을 두면
이 서버들이 그 파일들을 제공해주는것이다. (= 정적 데이터를 제공한다.)
ex) nginx, apache 엔지넥스랑 아파치
웹 애플리케이션 서버는? (WAS 와스 라고 함)
웹 서버와 마찬가지로 HTTP 기반으로 동작한다.
웹 서버의 기능을 포함한다. (= 정적 리소스 제공 가능하다.)
웹 서버와 큰 차이는 ★프로그램 코드를 실행해서 애플리케이션 로직을 수행★한다.
프로그램 코드를 실행해서 애플리케이션 로직을 수행한다는건?
로그인 HTTP 요청이 오면 로그인 후 사용자의 이름도 보여줄수도 있고~ 그런것
이게 가능한 이유는? 서버에서 프로그래밍을 할 수 있기 때문이다.
프로그램 코드를 사용해서 애플리케이션 로직을 수행할 수 있는게 웹 애플리케이션 서버 특징이다.
동적 HTML 생성가능하고 요즘 많이 사용하는 HTTP API (REST API 라고 하기도 한다.)
서블릿, JSP, 스프링 MVC 같은것들이 WAS 안에서 동작 된다.
ex) 톰캣, 제티, 언더토우
웹 서버와 웹 애플리케이션 서버(WAS)의 차이는?
간단하게
웹 서버는 정적 리소스 제공, WAS는 애플리케이션 로직까지 실행할 수 있는 것.
사실은 두 용어 경계도 모호하다.
웹이니까 웹 서버니까 아 HTTP 기반에 웹을 뭔가 데이터를 주고받을수있는 서버다 라고 넓게 볼수도있다.
웹 서버도 사실은 프로그램을 실행하는 기능을 포함하기도 한다.
웹 애플리케이션 서버도 웹 서버의 기능을 제공한다.
그럼 무엇으로 구분하느냐?
언어별로 조금씩 다른데
자바는 서블릿 컨테이너 기능을 제공하면 WAS라고 하고
(요것도 좀 애매한데 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있다.)
WAS는 애플리케이션 코드를 실행하는데 더 특화되어있다.
웹 시스템 구성
보통 WAS랑 데이터베이스만으로 시스템 구성할 수 있다.
WAS는 정적리소스, 애플리케이션 모두 제공 가능하기 때문이다.
그런데 이렇게 구성하면 WAS가 너무 많은 일을 담당할 수 있어 서버 과부하 우려가 있다.
이게 중요한데 HTML, CSS, JS는 시스템 적으로 값이 싸고 단순한데
애플리케이션 로직은 비싸다. (주문하는 로직이 비쌀까 폴더에 있는 이미지 하나 보여주는게 비쌀까?)
정적 리소스는 그냥 폴더에 있는걸 불러 보여주면되는데
애플리케이션 로직은 디비도 뒤져야하고 필요하면 다른 서버도 호출해야해서 복잡하다.
그래서 값비싼 애플리케이션로직이 정적 리소스처리 때문에 수행이 어려울 수 있다.
그리고 WAS가 생각보다 잘 죽는데,
개발자가 개발하는것이기때문에 버그도 있고 여러가지 이유로 죽을 수있다.
WAS가 장애가 나버리면 웹 브라우저에서 WAS에 접근하고 싶은데 접근이 안된다.
WAS에 문제가 생기면 오류화면 조차도 노출이 불가능해진다.
WAS만 가지고 작은 시스템은 구축해도 되는데 큰시스템은 부담이 있다.
그래서
이렇게 많이 구성한다.
클라이언트 - 웹 서버 - WAS - 데이터베이스
정적인건 웹서버에서 많이 하고
동적이 필요한 URL이네? 웹서버가 처리를 못하면 WAS로 넘겨서
WAS에서 데이터베이스도 셀렉해서 데이터 가져와
내려주고 내려주는것이다.
이렇게 구성하면 장점이 무엇이냐.
1. 업무를 분담할 수 있다.
WAS는 중요한 애플리케이션 로직 처리 전담에 집중할 수 있다.
2. 효율적으로 리소스를 관리할수 있다.
만약 정적 리소스가 많이 필요하면 웹 서버를 증설하면 되고
애플리케이션 리소스가 많이 사용되면 와스를 증설하면 된다.
물론 실제는 이것보다 더 복잡하다.
3. 장애시 오류 화면을 고객에게 보여줄 수 있다.
사실 단순한 파일을 읽거나 제공만 하면 되니까
폴더를 넣고 이 파일 제공할게요~ 설정만 하면 되니까
웹서버는 계산하고 이런게 잘 없어서 잘 안죽는다.
근데 WAS는 애플리케이션 로직이 들어있기 때문에 잘 죽는다.
데이터 베이스가 죽을수도 있고,
웹 서버에서는 장애가잘 나지않는데
WAS가 죽었다고 하더라도
고객이 요청을해서
WAS에 던져야 하는거네 하고 WAS에 던졌는데
커넥션이 안되거나 잘 안되면
웹서버에서 오류화면을 html을 고객에게 던질 수 있다.
더 나아가보면
요즘에는 CDN이라고 정적 리소스를 캐시할수있는 중간서버들도 사용하는데
이틀을 기반으로 점점 더 발전하고 있다.
번외로 API로 데이터만 제공하게 된다면
이때는 웹서버가 없어도 된다.
회사들끼리 데이터만 주고받는다고 하면
웹서버없이 WAS서버만 있어도 된다.