시작하며

스프링에서 서버를 키다보면 로그창에 tomcat이라는 키워드들이 간혹 보이긴 했다. 지금까지는 그냥 그런 갑다~ 하고 넘어갔었는데, OAuth2를 구현하고 HttpSession을 사용하다보니 Tomcat이라는 키워드가 등장하기 시작해 이를 알아보려 한다.

개념에 대한 정리글이라기 보다는 궁금증을 해소해나가는 과정을 그리고 있다고 보면 좋을 것 같다. 가볍게 훑는 느낌으로 읽어나가봐라는 말이 도움이 될지도 모르겠다.

Tomcat이란

검색해보면 Tomcat은 대표적인 WAS 중 하나라고 한다. 이 WAS는 Web Application Server의 줄임말이라 하는데, Web Server와 헷갈리거나 같이 나오는 개념인듯 싶다. 따라서 하나하나 차근차근 알아보자.

정적 페이지와 동적 페이지

앞서서 알고 갈 개념은 정적 페이지와 동적 페이지이다. 딱히 어려울 것 없다.

정적 페이지의 경우 말 그대로 멈춰있는걸 그대~~~로 보여주는 것이다. 이미 가지고 있는 Html, css 정도로 웹 페이지를 그려주면 되는 것이다. 한마디로 말해 "이미 적혀진 텍스트 파일을 그대로 그려준다" 정도로 이해하면 된다.

동적 페이지의 경우 보여주는 데이터가 동적으로 바뀐다는 것을 의미한다. DB와 같은 저장공간에서 요청에 맞게 데이터를 받아와 그려주기 때문에 다양하고 다채로운 서비스를 제공할 수 있다. 하지만 이미 알고 있는 것을 그대로 보여주는 것이 아니고, 통신이 필요하기 때문에 정적 페이지에 비해 비교적 시간이 걸리고, Web Server 외의 추가적인 WAS가 필요하여 추가 비용이 든다.

마지막 문장이 이 개념을 알고가야하는 이유이다. 우리가 알아보고자 했던 Web Server와 WAS가 둘다 등장했다. 이제 그 이유를 깊게 살펴보자.

Web Server

먼저 Web Server는 하드웨어와 소프트웨어로 구분하여 설명할 수 있다.

• 소프트웨어 : 클라이언트로부터(웹 브라우저) HTTP 요청을 받아 이에 맞는 웹 페이지(HHTML)를 제공하는 컴퓨터 프로그램
• 하드웨어 : 그러한 프로그램을 실행하는 컴퓨터

이러한 웹 서버의 기능으로는 크게 두가지가 있다고 한다.

• 정직 컨텐츠(페이지)를 제공하기 위해 WAS를 거치지 않고 바로 자원 제공(핵심)
• 동적 컨텐츠(페이지)를 제공하기 위해, WAS에 요청을 보낸다. 클라이언트의 요청을 WAS로 전달하고, 그 결과를 돌려받아 클라이언트에 전달해준다. 즉 동적 컨텐츠를 얻기 위해 WAS와 클라를 연결하는 매개체가 되어준다.

이러한 Web Server의 예시로는 아파치 HTTP 서버, 마이크로소프트 IIS, Google Web Server, NGINX 등이 있다.

WAS(Web Application Server)

이제 우리가 도달하고자 했던 목적지인 WAS에 도달했다. 앞의 글을 따라오다 오면 어느정도 감이 생겼겠지만, WAS는 DB 조회나 여러 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 application Server 이다. 클라이언트로 부터 동적 컨텐츠에 대한 요청이 들어오면 이를 처리하여 돌려주는 역할을 한다.

WAS의 경우 정적 컨텐츠 또한 제공해줄 수 있기 때문에 Web server를 포함하는 관계라고 할 수 있으며, 따라서 WAS는 Web Server + Web Container 라고 말하기도 한다.

여기서 Web Container는 java 환경에서의 경우 Servlet Container라고도 불리는데, 이를 이해하기 위해 Servlet이 뭔지 알아보자.

Servlet

Apache 서버의 경우 CGI(Common Gateway Interface)라는게 존재해 특정 요청에 알맞은 프로그램을 적절히 연결해주는 그러한 인터페이스(프로그램)이 존재한다. Java에서는 비슷하게 Servlet이라는 것이 존재한다.
따라서 Servlet은 클라이언트 요청을 처리하고, 그 결과를 반환해주는 웹 프로그래밍 기술이다. 즉 실제로 정보를 요청하고 받아오는 기능을 수행한다.

Web Container(= Servlet Container ??)

위 Servlet은 스스로 동작하지는 못한다. 따라서 이 Servlet들을 관리해주는 것이 필요한데 해당 기능을 이 Container가 해주게 된다. 우리가 그렇게 기다리던 Tomcat이 이러한 Servlet Container의 한 종류라고 할 수 있다.

특징 및 역할

• web server와의 통신 지원
  servlet이 web server와 통신할 수 있게 해주고 그 과정을 모르게 해주기에 비즈니스 로직에만 집중할 수 있게 해준다.
• servlet 생명주기 관리
  생성과 소멸을 관리, servlet을 불러와 초기화 메서드를 호출하며 요청에 따라 적잘한 메서드를 호출하게 함. servlet의 역할이 끝나면 이를 소멸시킨다.
• 멀티쓰레드 지원 및 관리
  servlet container는 요청이 올 때 마다 새로운 자바 쓰레드를 생성하고, HTTP 서비스 메서드를 실행한 후 이는 자동으로 죽는다. 이러한 관리를 container가 알아서 해준다.

그래서 Tomcat은..

파고파고 들어가본 결과 Tomcat은 servlet container의 한 종류다~ 라고 정의할 수 있겠다. 여러 자료들을 보면 Tomcat 자체로 WAS라고 하는 곳도 있는데, 자세히 들여다보면 J2EE 스펙? 을 구현하고 있지 않아 servlet container에 좀 더 가깝다라는 말이 많다. 물론 이게 아직 뭔 얘기인지는 모른다. 다만 결국 여러 servlet들을 관리해주는 역할을 하는 친구라는 것을 알게 되었다.

그래서 Session은..?

사실 Tomcat에 대한 조사를 시작하게된 계기가 여기서 볼 수 있듯 JSession ID를 발견하면서 였다.

찾아본봐는 다음과 같다.

세션관리란 사용자의 상태를 유지하는 방법을 말한다. 이를 통해 사용자의 상태를 관리해 페이지 이동시마다 로그인을 요구하지 않고도 이미 로그인한 사용자임을 입증할 수 있게된다.
그러나, HTTP 프로토콜의 경우 그 자체는 무상태성을 유지해야 하기에, 그 바깥 단에서 이러한 세션과 같은 상태를 관리해야 한다.

여기서 이러한 세션을 관리하는 역할을 담당하는 것이 바로 Tomcat과 같은 서블릿 컨테이너가 된다!!!

이렇게 궁금해했던 지점까지 도달했다. 생각해보면 꽤나 말이 된다.
서버에 요청을 보낼 때 권한을 확인하거나 할 때 사용자가 로그인 되어 있는지를 확인하고는 하는데, 실제로 요청을 보내고 값을 받아오는 것은 servlet이고, 이 servlet은 혼자서 동작을 하지 못하는 이 servlet을 관리하는 servlet container가 이러한 session을 관리한다는 것이니 말이다.

마치며

이렇게 Tomcat을 향한 여정이 정적/동적 페이지, Web Server, WAS, servlet/container를 거쳐 끝끝내 도달했고, 여기서 Session에 대한 조금의 이해도 얻었다. 꽤나 유익한 시간이었고 추후에도 이런식으로 스토리텔링(?) 곁들인 궁금증 해소 방식을 사용해볼 것 같다.
또 Servlet의 경우 Spring과 엮어 좀 더 공부해볼 내용들이 많은 것 같다 이를 추후에 진행해보는 것으로 이 글을 마친다.