웹서버, 앱서버 그리고 CGI (Web & Application Server and CGI)

Java 기반의 웹 애플리케이션을 개발 시, 로컬에서 src/java와 src/webapp의 파일들을 서버에 올리고 실행하여 http://localhost:8080으로 들어가 체크하게 됩니다. 반면, 배포 시 어떠한 경우에는 web과 같은 경우는 하나의 서버에 그리고 src/java의 파일들을 포함한 war 파일로 압축한 것은 다른 서버에 나누어 배포 하기도 합니다.

 

이 글에서는 아래와 같은 사항을 중점으로 웹 서버(전자)와 애플리케이션 서버(후자), 그리고 웹 서버와 앱 서버의 커뮤니케이션을 담당하는 CGI(Common Gateway Interface)에 대해 기술합니다:

 

• CGI 
• 웹 서버와 애플리케이션 서버

 

---

CGI

가장 처음의 그래픽 웹 브라우저인 Mosaic 브라우저가 탄생했던 웹 초창기에 static 페이지와 이미지를 HTTP 프로토콜을 통해 서빙하는 "웹 서버"라는 개념이 생겨났습니다. 이 시기에는 대부분의 컨텐츠는 static이였고 HTTP 1.0 프로토콜은 파일을 송수신하는 방법이었습니다 [1]. 

 

그러나, static한 컨텐츠를 넘어서 클라이언트의 요청 값에 따라 특정 실행 후 dynamic하게 생성한 컨텐츠에 대한 요구사항을 수용하기 위해서 CGI [3]를 더하여 웹은 "실행가능한 애플리케이션 (Executable Applications)"으로 진화하였습니다:

 

http://www.myserver.com/cgi-bin/MyExecutable?name1=value1&name2=value2

CGI를 위한 URI는 위와 같은 형태입니다. 

 

URI에서 프로토콜명과 서버명을 제외한 모든 것(/cgi-bin/*)이 context path에 해당됩니다. 

 

URL의 /cgi-bin/ 부분은 서버에 다음 부분의 URI에 해당되는 CGI 프로그램을 실행해야한다는 사실을 알립니다. 물음표(?) 이후의 부분은 query string으로 CGI 프로그램에 클라이언트가 정보를 보낼 수 있도록 합니다. 이러한 방법을 통해, 그 프로그램은 결과물에 영향을 주는 특정 클라이언트의 정보를 가지고 실행될 수 있습니다.

 

초창기 CGI는 몇 가지 결점을 지니고 있었습니다. 애플리케이션을 작성하는데 사용되는 언어는 procedural해야 했습니다. 또한, CGI 프로그램의 불안정성은 머신 전체를 다운시키기도 했습니다. 성능에 관해서는, CGI 애플리케이션은 매 요청마다 애플리케이션의 새로운 인스턴스를 생성하고, 새로운 쓰레드를 생성하였기에 확장성에 한계가 있었습니다. 그러나, 이후 FastCGI와 같은 개선을 통해 일부 그러한 성능 문제를 개선이 진행되기도 하였습니다.

 

그러나 CGI는 웹 서버와 프로그램 간에 한 가지 "계약"만을 다루었습니다. 어떠한 서비스도 사용자 중심의 시스템을 제공하지는 못하였습니다. 사용자 중심의 시스템은 예를 들어, 클라이언트를 식별하여 관리하는 것, 사용자 정보 관리방법을 제공하는 것, 애플리케이션 접근을 권한이 있는 사용자로 제한하는 것 등입니다. 

 

그러한 한계로 인해, 위와 같은 기능을 담당하는 새로운 프레임워크가 필요하게 되었습니다. 그러한 배경에 의해서 Spring 웹의 근간을 이루고 있는 Servlet이 탄생하게 되었습니다.

 

위 사실을 살펴보면, 하나의 웹 서버의 기능이 웹 서버와 (이후의) 애플리케이션 서버로 나누어 지는 시점이 CGI의 탄생 시점이라는 사실을 알 수 있습니다. 

 

 

 

웹 서버와 애플리케이션 서버

Historically they were different, but these two previously distinct categories slowly merged, and now should be seen as one entity in most of the cases and uses. [1]

 

RFC에 기록된 CGI의 목적을 살펴보면 웹 서버, 그리고 CGI 스크립트의 기능을 담당하며 하나의 독립 서버로 분리한 애플리케이션 서버에 대해 어떤 기능을 요구하는지 알 수 있습니다:

 

The server(HTTP Server) is responsible for managing connection, data transfer, transport and network issues related to the client request, whereas the CGI script handles the application issues, such as data access and document processing. [3]

 

• 웹 서버: 클라이언트 요청과 관련된 connection, (정적) 데이터 transfer와 transport 그리고 네트워크 이슈를 담당합니다. 캐싱, security, session 관리 등의 추가적인 기능도 제공하며 Kiva 그리고 NetDynamics의 자바 기반의 서버 기술들이 현재에도 사용하는 JSP(Java Server Pages)와 같은 기술로 이어졌습니다.
• 애플리케이션 서버: 데이터 접근과 동적 컨텐츠 생성과 같은 애플리케이션 이슈를 담당합니다. 애플리케이션 서버는 오랜 시간 동안 진화해오고 존재해왔습니다. Tuxedo, Topend, Encina와 같은 90년대 이전의 소프트웨어들은 "closed" 특정 상품용 커뮤니케이션 프로토콜로 "fat" client를 서버에 연결하였습니다. 90년대에 들어서 이러한 전통적인 앱 서버 제품들이 기본적인 HTTP 프로토콜을 추가하면서 현재 앱 서버와의 구분이 점차 사라져 왔습니다.

 

현재 시점에서 웹 서버는 더 높은 부하를 다루고 많은 기능이 추가되었고, 앱 서버는 점점 더 HTTP 기반의 기능들을 더해왔습니다. 이러한 결과로 웹 서버와 앱 서버의 구분은 희미해졌습니다. 많은 인기있는 애플리케이션들은 웹 서버 그리고 앱 서버의 기능을 동시에 가지고 있습니다 (Apache HTTP, Express, Hapi, and Koa [4]).

A typical web-app server structure - Image from Author

 

 

 

 

Reference

[1] How web servers work?

[2] Professional Apache Tomcat 5

[3] The Common Gateway Interface (CGI) Version 1.1

[4] Application Server vs Web Server

[5] Separating the deployment of the static contents and the Web application

[6] 5 Common Server Setups For Your Web Application

[7] Apache as the Frontend of Tomcat