앞서 웹 애플리케이션이 어떻게 발전했는지 공부했었다.

웹서버와 웹클라이언트 사이 정적 HTML을 주고 받기위해 HTTP를 고안했고

CGI방식을 통해 동적 HTML을 생성하는 프로그램을 웹서버가 구동시켜 동적 HTML을 만들어내어 뱉어냈다.

다만, 동적HTML 만드는 프로그램이 요청때마다 살아났다 죽었다를 반복해서 속도가 떨어졌다.

반면 애플리케이션서버 방식은 웹서버와 애플리케이션서버가 연동하는 방식인데 애플리케이션서버를 실행시키기 위한 JavaVM 프로세스가 항상 살아있어 속도가 상대적으로 빨랐고 그 위에 애플리케이션 서버가 올라가있고 그 위에 웹 애플리케이션을 통해 서블릿/JSP가 생성되어 재활용등의 장점이 있었다.(JAVA의 인기가 한 몫한것도 있다.)

디자인 영역을 떼어내면서 JSP까지 발전했고 다양한 프레임워크가 생겨났다.

그렇게 웹서버 사이드는 발전했다.

소규모 웹 서비스에서는 한 컴퓨터 안에서 웹서버, DB서버를 둘 수 있지만 조금만 규모가 커지면 다운되기 쉽상이다.

그래서 DB서버를 다른 컴퓨터에 두고 웹서버와 통신하는데 그때 DB 제품에 맞는 프로토콜을 구현한 라이브러리가 JDBC 같은 것이다.

웹서버와 웹애플리케이션서버는 다른 프로세스이므로 서로 연동하려면 통신을 해야했다.

근데 통신방법이 표준화 돼있지 않다. 그래서 웹서버측에 연동모듈을 탑재해 통신하게된다.

웹서버에 요청이 들어오면 웹애플리케이션서버에 연동모듈을 통해 요청을 전달하고 웹애플리케이션에서 요청을 처리하고 응답을 보낸다.(웹서버는 대게 아파치, 웹애플리케이션서버는 톰캣 , 둘 사이에 고속을 위해 톰캣 고유의 프로토콜도 존재..)

통상적으로 웹서버쪽에는 정적콘텐츠만 배치하고 웹애플리케이션서버에는 동적콘텐츠를 배치한다.

이처럼 서버 사이드에서는 프로세스 두 개가 연동하는데 HTTP요청 중 애플리케이션이 처리할 부분만 애플리케이션서버에 전달한다.

그렇다면 웹 서버는 어떻게 해서 애플리케이션 서버로 전송해야 할 URL인지 구분할까?

컴퓨터가 판단할 수 없고 우리가 가르쳐 줘야한다.

웹서버에 톰캣과 연동하는 모듈이 설정 파일을 읽는다.

HTTP요청을 전송할 톰캣에 관한 정보를 담는 파일에는 톰캣 워커라는 톰캣프로세스의 이름과 애플리케이션서버의 호스트명과 포트번호와 톰캣과 통신할 프로토콜이 담겨져있다.

아파치의 설정파일에는 위 파일의 위치와 아파치가 받은 HTTP요청 URL 중 톰캣에 보낼 URL이 지정 되어있다.

웹서버는 많은 클라이언트의 요청을 받는다. (정적 콘텐츠 하나하나 요청 다 보내기 때문에..)

웹애플리케이션서버는 대신 한번의 요청에 무거운 처리를 진행한다.

이처럼 서버당 성격에 맞게끔 컴퓨터를 분담하면 된다.

톰캣워커는 여러개 두어 이중화 할 수 있다.

근데 대부분의 애플리케이션서버는 웹서버 기능도 할 수 있다.

그래서 단순히 애플리케이션서버만 둘 수도 있는데 이렇게 되면 웹서버-웹애플리케이션서버간의 연동 작업도 필요 없어서 단순한 구조가 된다.

> 웹애플리케이션서버(WAS)가 제공하는 기능

• 세션관리

• 트랜잭션 관리

• DB접속관리

• 웹애플리케이션관리와 시스템 가용성/성능 향상