FastCGI

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

FastCGI는 CGI(Common Gateway Interface)의 확장성 문제를 해결하기 위해 개발된 프로토콜이다. 웹 서버와 웹 애플리케이션 간의 통신을 개선하여, 각 요청마다 새로운 프로세스를 생성하는 대신 지속적인 프로세스를 사용한다. 웹 서버와 애플리케이션을 분리하여 서버 및 애플리케이션 프로세스를 독립적으로 재시작할 수 있으며, 다양한 웹 서버에서 구현되어 사용되고 있다. FastCGI는 프로토콜일 뿐 구현체가 아니므로, 다양한 프로그래밍 언어로 구현 가능하다.

FastCGI

일반 정보

이미지 준비중입니다.

FastCGI 프로토콜 다이어그램

유형	바이너리 프로토콜
계층	애플리케이션 계층
포트	9000 (표준)
상태	활성

기술 세부 사항

기반	HTTP 유사
설계 목표	CGI의 오버헤드 감소
사용 사례	웹 서버와 애플리케이션 서버 간의 인터페이스

개발 및 표준

개발자	Open Market
최신 버전	1.0

관련 프로토콜	SCGI
대체 기술	HTTP CGI SPDY WebSocket

2. 역사

공용 게이트웨이 인터페이스(CGI)는 외부 애플리케이션이 웹 서버와 상호 작용할 수 있도록 하는 인터페이스 규격이다. CGI 애플리케이션은 각 요청이 시작될 때 생성되고 요청이 끝나면 제거되는 별도의 프로세스에서 실행된다. 이러한 "요청당 하나의 새 프로세스" 방식은 CGI 프로그램 구현을 단순하게 만들지만, 효율성과 확장성을 제한하는 단점이 있다. 특히 높은 부하 상태에서는 프로세스를 생성하고 제거하는 데 따르는 운영 체제의 오버헤드가 상당하다. 또한, CGI 프로세스 모델은 데이터베이스 연결 재사용이나 인메모리 캐싱 같은 리소스 재사용 기법을 활용하기 어렵게 만든다.

CGI의 이러한 확장성 문제를 해결하기 위해 오픈 마켓(Open Market)은 FastCGI를 개발하여 1990년대 중반 자사의 웹 서버 제품에 처음 도입했다. 오픈 마켓은 본래 FastCGI를 웹 애플리케이션 개발을 위한 넷스케이프(Netscape)의 독점적인 인 프로세스 응용 프로그래밍 인터페이스(API)인 넷스케이프 서버 응용 프로그래밍 인터페이스(NSAPI)에 대한 경쟁 기술로 개발했다.

FastCGI는 처음에는 오픈 마켓에서 개발되었지만, 이후 여러 다른 웹 서버 제조사에서도 구현되었다. 그러나 FastCGI는 서버와 하위 프로그램 간의 통신을 가속화하고 단순화하는 다른 방법들과 경쟁해야 했다. 아파치 HTTP 서버의 모듈인 mod_perl과 mod_php 등이 비슷한 시기에 등장하여 빠르게 인기를 얻었다. 현재에도 CGI를 포함한 이러한 다양한 방식들이 널리 사용되고 있다.

3. 구현 세부 사항

FastCGI는 요청마다 새로운 프로세스를 생성하는 대신 영구적인 프로세스를 사용하여 일련의 요청을 처리한다. 이러한 프로세스는 웹 서버가 아닌 FastCGI 서버가 소유하고 있다.

수신된 요청을 처리하기 위해 웹 서버는 환경 변수 정보와 페이지 요청을 유닉스 도메인 소켓, 명명된 파이프, 또는 전송 제어 프로토콜(TCP) 연결 중 하나를 통해 FastCGI 프로세스에 전송한다. 응답은 동일한 연결을 통해 프로세스에서 웹 서버로 반환되며, 웹 서버는 해당 응답을 최종 사용자에게 전달한다. 응답 마지막에 연결이 닫힐 수 있지만, 웹 서버와 FastCGI 서비스 프로세스 모두 존속한다.

개별 FastCGI 프로세스는 존속 기간 동안 많은 요청을 처리할 수 있으므로, 요청마다 프로세스의 생성과 종료 오버헤드를 피할 수 있다. 여러 요청을 동시에 처리하는 방법에는 여러 가지가 있다. 하나의 연결을 내부 다중화(즉, 하나의 연결로 여러 요청)를 사용하여 처리하거나, 여러 연결을 사용하거나, 이러한 방법의 조합을 사용할 수 있다. 여러 FastCGI 서버를 구성할 수 있으므로, 안정성과 확장성이 향상된다.

웹사이트 관리자와 프로그래머는 FastCGI로 웹 서버에서 웹 애플리케이션을 분리하면, 내장 인터프리터(mod_perl나 mod_php 등)에 비해 많은 이점이 있다. 이 분리를 통해 서버 프로세스와 애플리케이션 프로세스를 개별적으로 재시작할 수 있다. 이는 트래픽이 많은 웹사이트에 중요한 고려 사항이다. 또한, ISP나 웹 호스팅 회사에 중요한 요구 사항인 애플리케이션별 호스팅 서비스 보안 정책의 구현도 가능하다. 다양한 유형의 수신 요청을 해당 유형의 요청을 효율적으로 처리하도록 구성된 특정 FastCGI 서버에 배포할 수 있다.

4. FastCGI를 구현하는 웹 서버

FastCGI는 여러 웹 서버에서 구현되어 사용되고 있다. 별도로 명시하지 않는 한, 각 웹 서버의 FastCGI 구현 완전성은 알려지지 않았다.

* 아파치 HTTP 서버 (부분적 구현)
* `mod_fcgid` 모듈을 통해 구현된다. 이 모듈은 원래 서드파티 모듈이었으나, 2009년 크리스 다로치(Chris Darroch)의 주도로 아파치 소프트웨어 재단(ASF)에 아파치 HTTP 서버 하위 프로젝트로 기증되었다. 이 모듈은 유닉스 도메인 소켓만 지원하며, TCP 소켓은 지원하지 않는다.
* 서드파티 모듈인 `mod_fastcgi`도 사용된다. 한때 아파치 2.4.x 버전에서 컴파일 문제가 있었으나, 이후 원본 프로젝트의 포크를 통해 문제가 해결되었다.
* 아파치 1.x 버전의 설계상 제약으로 인해 단일 연결을 통한 요청 다중화는 지원하지 않는다.
* 아파치 2.4 버전부터는 `mod_proxy_fcgi` 모듈이 추가되어 TCP FastCGI 서버를 지원한다.
* 캐디
* 체로키
* 히아와타
* FastCGI 부하 분산 기능을 지원한다.
* chroot 환경의 FastCGI 서버를 지원한다.
* 제티
* 케리오 웹스타
* 라이트티피디
* 라이트스피드 웹 서버
* 인터넷 정보 서비스
* Nginx
* 나비서버
* 오라클 iPlanet 웹 서버
* OpenBSD의 httpd(8)
* 오픈 마켓 웹 서버
* 레진 웹 및 애플리케이션 서버
* 록센 웹 서버
* 시머캣 웹 서버
* 제우스 웹 서버

5. FastCGI API 바인딩 언어

FastCGI는 네트워크 소켓을 지원하는 어떤 프로그래밍 언어로든 구현할 수 있다. 이는 FastCGI가 특정 구현 방식이 아닌 프로토콜이기 때문에 특정 언어에 종속되지 않기 때문이다. 다양한 언어를 위한 응용 프로그래밍 인터페이스(API) 바인딩이 존재한다.

다음은 FastCGI API 바인딩이 존재하는 언어 목록이다:
* 에이다
* 델파이, 라자루스, 프리 파스칼
* C, C++
* 치킨 Scheme
* 커먼 리스프
* D
* 에펠
* 얼랭
* GnuCOBOL
* Go
* Guile Scheme
* 하스켈
* HP BASIC for OpenVMS
* 자바
* 루아
* Node.js
* OCaml
* 펄
* PHP (PHP-FPM 또는 HipHop for PHP을 통해)
* 파이썬
* 루비
* 러스트
* SmartEiffel
* 스몰토크: FasTalk, Dolphin Smalltalk
* Tcl
* WebDNA
* 발라 (C 바인딩을 통해)
* Xojo (이전 Realbasic, REAL Studio)

루비 온 레일즈, 카탈리스트, 장고, 케플러, Plack와 같은 최신 웹 프레임워크들은 웹 서버에 내장된 인터프리터(mod_ruby, mod_perl, mod_python, mod_lua 등) 또는 FastCGI를 함께 사용할 수 있다.

반면, 셸 스크립트는 FastCGI를 적용하기 어려운 대표적인 경우이다. 일부 셸 구현체는 POSIX 표준 외 확장 기능으로 네트워크 소켓을 제한적으로 지원하기도 하지만, 언어 자체의 제약이 크고 구현이 복잡하여 공식적인 API 바인딩이 없다. 또한, FastCGI는 요청마다 새로운 프로세스를 생성하는 대신 기존 프로세스를 재활용하여 오버헤드를 줄이는 것을 목표로 한다. 하지만 셸 스크립트는 여러 외부 명령어를 호출하며 다수의 프로세스를 생성하는 방식으로 동작하는 경우가 많다. 따라서 설령 셸 스크립트에서 FastCGI를 사용한다 하더라도, 요청당 프로세스 생성을 단지 하나 줄이는 정도에 그쳐 FastCGI의 성능 향상 효과를 거의 기대하기 어렵다.