[Spring Basic] 웹 서버와 웹 애플리케이션 서버의 구조

 

 

 

클라이언트는 서비스를 요청하고, 서버는 서비스를 제공한다.

 

쉽게 생각하면 클라이언트는 우리가 사용하는 컴퓨터, 클라이언트 애플리케이션은 브라우저라고 할 수 있고, 서버를 처리하는 컴퓨터를 서버 컴퓨터, Tomcat을 서버 애플리케이션이라고 할 수 있다.

 

하나의 서버 컴퓨터에 여러 가지 서버가 모여있으면, 클라이언트가 제공하는 IP주소만으로는 어떤 서버에 대한 요청인지 구분할 수 없다.

 

때문에 포트번호가 필요하다. 여기서 포트번호는 서버를 구분할 때 사용한다. 

간단하게 네트워크에 연결된 애플리케이션의 프로세스나 서비스를 구분하기 위한 식별자라고 생각하면 된다. 

 

따라서 클라이언트는 서버에게 요청할 때 포트번호를 포함해서 요청해야 한다.

 

ex. 123.45.1234:8082 (아이피 : 포트번호) / 웹 서버는 일반적으로 http(80) 이나 https(443) 포트를 사용한다. 

같은 아이피 주소를 가진다고 해도 포트번호에 따라 다른 서비스를 제공할 수 있다.

 

0~1023까지는 예약된 포트번호이니, 다른 포트번호를 사용하자. 

 

WAS는 Web Application Server를 말하고, 웹 애플리케이션을 서비스한다. 

즉, 서버에 프로그램을 설치해 두고 클라이언트가 설치된 프로그램을 사용할 수 있도록 하는 역할을 한다.

 

클라이언트 컴퓨터에 프로그램을 설치하면 업데이트 할 때 불편함이 있어 WAS를 사용해 여러 개의 클라이언트 컴퓨터에 대해 업데이트를 한 번에 수행하도록 한다.

 

WAS를 사용하기 전에는 각각의 컴퓨터마다 프로그램을 설치해야 했지만, WAS를 도입한 후에는 하나의 컴퓨터에 프로그램을 설치하고 다른 컴퓨터가 해당 프로그램을 사용할 수 있게 됐다.

 

웹 서버도 클라이언트로부터 요청을 받고 결과를 반환하는 역할을 수행한다.

정적 리소스에 대한 요청을 처리하고, 동적 리소스에 대한 요청은 WAS에게 넘기는 등 요청에 따른 라우팅과 로드밸런싱 기능도 수행한다.

 

WAS와 웹 서버는 함께 사용되는 경우가 많다. 

 

 

 

---

 

 

 

 

Tomcat은 서블릿 컨테이너이다.

 

웹 서버는 정적 리소스에 대한 요청만을 처리할 수 있다. 

동적 페이지를 제공하려면 WAS를 활용해야 하고 웹 서버는 WAS에게 요청을 넘겨준다고 했는데, WAS는 내부에서 서블릿을 사용해 요청을 처리한다.

 

클라이언트가 URL을 입력하면 HTTP 프로토콜으로 요청이 날라가고, 해당 요청은 서블릿 컨테이너에게 전송된다.

요청을 받은 서블릿 컨테이너는 ServletRequest, ServletResponse 객체를 생성해 HTTP 요청의 메서드에 따라 동적 리소스를 생성하고 ServletResponse를 사용해 응답을 전송한다.

 

Tomcat은 웹 서버와의 통신을 제공하고, 서블릿의 생명 주기를 관리하며 멀티쓰레딩을 지원한다.

 

클라이언트로부터 요청이 들어오면 컨테이너는 요청을 처리하는 서블릿을 init() 메서드로 생성한다.

(이후 내용은 위에서 언급한 서블릿의 동작 과정과 유사하게 흘러간다) 

 

서블릿이 자바 코드 내부에 HTML이 들어가는 방식이라면 JSP 같은 템플릿 엔진은 HTML 내부에 자바 소스코드가 들어가는 방식이다.

 

JSP는 WAS에 의해 서블릿으로 변환되고 실행된다.

 

서블릿 기술 이전에는 CGI (Common Gateway Interface)가 사용됐었다.

 

CGI 방식은 웹 서버가 클라이언트의 요청을 처리하기 위해 외부 프로그램을 사용하는 방식으로 요청마다 새로운 프로세스를 생성하기에 너무 비효율적이다.

 

요청이 10개 날라오면 스프링을 10번 실행시킨다고 생각하면 된다. -_-

 

따라서 쓰레드 기반으로 요청을 처리하는 서블릿 기술이 도입됐다.

 

 

Tomcat의 내부 구조에 대해 알아보자.

클라이언트가 URL을 통해 서버에게 요청하면, 서버는 쓰레드 풀에서 미리 만들어 둔 쓰레드를 사용해 요청을 처리한다.

 

 

 

 

Connector는 클라이언트가 어떤 프로토콜로 요청했는지에 따라 적절한 프로토콜을 사용해 요청을 받고, Engine에게 요청을 전달한다. (HTTP가 많이 사용되지만 다른 프로토콜도 지원한다)

 

Server는 Tomcat을 대표하는 최상위 요소이다.

Server 내부에는 Service가 있다. Service는 하나 이상의 Connector와 하나의 Engine으로 구성된다. (Engine도 Servlet Container 라고 불린다)

Connector가 클라이언트의 요청을 받고 Engine은 요청에 대한 로직을 처리한다.

 

Host는 웹 서버에서 호스트 이름으로 작동하는 가상 호스트이다. (하나의 서블릿 컨테이너에 여러 호스트가 있을 수 있다)

Context는 웹 애플리케이션이다. 하나의 Host 내부에 여러 개의 Context가 존재할 수 있고, 서블릿과 JSP를 실행한다.

Context 내부에는 여러 개의 Servlet이 위치하고, 클라이언트의 요청을 처리한다. 

 

 

 

 

 

Tomcat으로 로컬 환경에서 애플리케이션을 배포할 때, 두 개의 포트번호가 할당된다.

 

Tomcat admin port는 셧다운 명령을 위한 포트이다. 

애플리케이션을 로컬 환경에서 배포한 후 localhost:8005로 접근하게 되면 "유효하지 않은 셧다운 명령을 받았습니다" 라는 로그를 확인할 수 있다.

 

일반적으로 해당 포트는 Tomcat의 server.xml에 정의된 특정 명령 문자열을 입력해 Tomcat을 안전하게 종료할 때 사용한다. (HTTP 요청 말고 SSH 접속 등으로 셧다운을 수행한다)

 

하나는 셧다운 전용, 하나는 애플리케이션 서비스 전용 포트로 포트를 두 개 할당하는데... 애플리케이션 배포 시 셧다운 전용 포트를 따로 설정하는게 일반적이지는 않고, Tomcat 말고 다른 WAS를 사용하는 경우 보통 애플리케이션 서비스 전용 포트만 열어놓는 편이다.

 

Tomcat으로 실제 애플리케이션을 배포할 때도 (로컬 X) 셧다운 포트를 열어두는 경우가 많다. (외부에서 접근할 수 없어야 한다)

 

HTTP는 80번 포트번호를, HTTPS는 443번 포트번호를 가진다.

웹 브라우저는 해당 포트를 기본값으로 사용하기에 사용자가 URL에 포트번호를 함께 입력하지 않아도 된다.

 

실제로 www.naver.com:443  과 www.naver.com  은 같은 역할을 한다. 

 

따라서 애플리케이션을 실제로 배포할 때는 일반적으로 443 또는 80 포트를 사용하도록 설정한다.