흠....PHP도 CGI 인가요?

puaxx의 이미지

제가 CGI에 대한 정의들을 찾아보니

CGI란 클라이언트의 요청을 서버에서 받아 그 요청을 다른 응용 프로그램으로 넘겨서 필요에 따라서 그 결과를 다시 서버로 보내 서버에서 클라이언트로 그결과를 다시 보내는 이런 일련의 규칙이 CGI 다 라고 정의 되어 있는데 말이죠.

그렇다면 PHP나 ASP,JSP 이런것들도 모두 CGI에 속하는것 인가요? 개념으로 보면 CGI의 개념과 일치한다고 생각이 듭니다만...;; 제대로 확신이 서진 않네요.

소리의 이미지

CGI는 Common Gateway Interface의 약자로, 서버의 스크립트들이 HTTP 클라이언트(user-agents)의 요청에 대해 웹서버와 어떻게 통신하는지에 대한 인터페이스를 정의합니다.

따라서 의도하신 "PHP"가 HTTP를 통해 웹서버의 스크립트를 실행하는 것을 말씀하신 거라면, PHP 역시 CGI를 통해 작동하는 것이 맞습니다. 엄밀히 말하면 PHP는 좀 더 일반적인 스크립트식 프로그래밍 언어이고, 항상 웹서버의 스크립트로 실행해야 하는 것은 아닙니다.

CGI에 대해 더 자세하고 정확하게 알고 싶으시다면 CGI 1.1에 대한 다음 문서를 참고하세요.
http://www.ietf.org/rfc/rfc3875

puaxx의 이미지

기존의 통념이 틀린것이 되는것인가요?

일반적으로 "CGI는 실행될때마다 프로세스가 떴다가 사라지므로 오버헤드가 발생한다." 라는 통념은 틀린 것이 되는것인지?(PHP는 굉장히 빠르므로)

앞으론 그 뒤에 "그렇지 않은것도 있다" 라고 토를 달아줘야 되는것일까요?

소리의 이미지

저 명제는 틀리지 않습니다. 일반적으로 웹서버에서 돌리는 독립적인 스크립트를 CGI라고, 웹서버의 모듈로 연동해 돌리는 PHP스크립트 등과 구분하여 부르더군요.

음... 어느 관점에서 보느냐에 따라 다를 것 같습니다. 웹서버와 클라이언트의 통신을 본다면 PHP도 (독립적으로 돌리든 웹서버의 모듈로 돌리든) CGI를 통하는 것이 맞습니다. 하지만 웹서버와 스크립트간의 통신에 있어선 웹서버의 모듈을 통해 PHP 스크립트를 실행할 경우 일반적인 CGI와 다르군요. CGI가 후자의 실행 매커니즘까지 정의하고 있는지는 공부해보지 않아 잘 모르겠습니다. ^^;;

소타의 이미지

PHP도 프로세스 형태로 떴다가 사라지는 형태가 존재합니다.
perl, PHP등이 유행하기 전에는 대부분 C/C++ 등으로 하나의 프로그램을 만든 후 웹서버가 실행하는 방식이었습니다. 환경변수에 HTTP헤더 등을 세팅해 주는 방식이었는데요. 동일한 방식으로 PHP나 perl 등이 동작하게 할 수도 있습니다.
그 후에 나온 언어들 중 웹서버에 임베딩 되어 오버헤드가 발생하는 프로세스 fork를 없앤 형태들이 나오게 되었습니다.

CGI는 외부 프로그램이 실행될 때 세팅하는 환경변수의 종류나 네이밍 등 외부 프로그램이 사용할 변수들의 통일을 위한 하나의 규약 같은것 입니다. CGI 자체가 fork 된다는 건 말 자체가 틀리다고 봐야 하고요. 하지만 이전에 통념적으로는 위의 의미로도 많이 쓰였습니다.
통념도 맞고 새로운 형태도 나오긴 했습니다만 새로운 개념 역시 웹서버가 환경변수 등을 넘겨줄 때는 CGI에 맞춰서 넘겨줍니다.

wish의 이미지

PHP 도 CGI 로 돌아갈 수도 있습니다. 다만 그렇게 쓰는 경우는 거의 없습니다. 님께서 말씀하신대로 CGI 로 돌아가면 각각의 요청마다 프로세스를 생성하므로 성능이 현저하게 떨어지기 때문입니다.

먼저 CGI 란 것부터 간단하게 설명드리겠습니다. CGI 는 소리님께서 말씀하셨듯이 웹서버와 프로그램 간에 데이터를 어떻게 주고 받을 것인가에 대한 규약입니다. 웹서버가 웹브라우저 같은 클라이언트로부터 요청을 받았는데, 웹 서버가 그 요청이 특정 프로그램이 실행될 필요가 있다고 설정 되어 있으면, 프로그램을 실행시키고 그 규약에 따라서 데이터를 프로그램에 넘깁니다. 프로그램 실행이 끝나고 결과가 나오면 프로그램은 규약에 정한대로 결과를 웹서버에 넘겨 줍니다.따라서 보통의 경우 CGI 로 처리를 하면 각 요청마다, 프로세스를 뛰워야 하기 때문에 성능이 좋지 못한 것입니다.

만약 PHP를 CGI 형식으로 수행 한다면, 아마 님 컴퓨터에서도 /usr/bin/php 또는 /usr/local/bin/php 라는 실행파일이 있을텐데, 웹서버를 특정 URL로 요청이 들어오면 php 를 실행시켜서 html 로 변환한후 웹서버에 넘겨주어 처리하게 됩니다. 실제로 이런식으로 설정하는 것도 가능하구요.

그러나 가장 흔한 PHP 설정은 웹서버 내에 php 인터프리터를 내장하는 방법입니다. 즉 요청이 들어왔을 때, 따로 프로그램을 실행시키지 않고 바로 웹서버가 직접 결과를 생성해서 클라이언트로 보내줍니다. 이 방법은 어차피 웹서버는 데몬 형태로 항상 실행중이므로, 요청이 들어와도 다른 프로세스를 생성하지 않기 때문에 성능이 좋습니다. 보통의 경우는 아파치 웹서버에 mod_php4 혹은 mod_php5 라는 모듈을 올려서 사용합니다. 이 모듈은 아파치를 컴파일 하는 시점에서 아예 같이 하나의 프로그램으로 컴파일 할 수도 있지만, 보통은 동적 모듈로 만들어서 아파치가 실행 될때 아파치가 직접 모듈을 자신에게 불러들이게 됩니다.

그리고 웹서버에 직접 내장하는 방법 이외에도, 웹서버 밖에다 따로 데몬을 뛰워 놓고 아파치와 이 데몬 프로세스가 소켓 통신으로 데이터를 주고 받는 방법도 있습니다. SCGI, FCGI 등등이 이런 기술인데, 이 방법을 사용해도 각 요청마다 따로 프로세스를 뛰우지 않고 소켓으로 데이터만 보내고 받으면 되기 때문에 오버헤드를 크게 줄일 수 있게 됩니다.

puaxx의 이미지

웹서버와 같이 로드되어 붙어 돌아가는 php도 결국은 CGI가 아니냐는 것을 질문드린것입니다.

텀즈에서 발췌한 CGI의 정의에 따르면

CGI[씨지 아이]는 웹서버에 있어 사용자의 요구를 응용프로그램에 전달하고 그 결과를 사용자에게 되돌려주기 위한 표준적인 방법이다. 사용자가 하이퍼링크를 클릭 하거나 웹사이트의 주소를 입력함으로써 웹 페이지를 요청하면, 서버는 요청된 페이지를 보내준다. 그러나, 사용자가 웹페이지의 양식에 내용을 기재하여 보냈을 때, 그것은 보통 응용프로그램에 의해 처리될 필요가 있다. 웹 서버는 으레 그 양식 정보를 조그만 응용프로그램에 전달하는데, 이 프로그램은 데이터를 처리하고 필요에 따라 확인 메시지를 보내주기도 한다. 이렇게 서버와 응용 프로그램간에 데이터를 주고받기 위한 방법이나 규약들을 CGI라고 부른다. 이것은 웹의 HTTP 프로토콜의 일부이다.

이런게 CGI라고 정의하고 있습니다.
제가 질문드린게 PHP도 CGI방식으로 작동할수 있는것인가? 가 아니라.
텀즈에서 발췌한 위의 정의 처럼 그렇다면 PHP도 같은 맥락으로 작동하는것이고 웹서버에 붙여진 PHP모듈을 통해 실행되어지는 PHP 스크립트도 결국은 CGI가 아닌것인지를 묻는것입니다.

wish의 이미지

텀즈에서 발췌한 위의 정의 처럼 그렇다면 PHP도 같은 맥락으로 작동하는것이고 웹서버에 붙여진 PHP모듈을 통해 실행되어지는 PHP 스크립트도 결국은 CGI가 아닌것인지를 묻는것입니다.

이거 제가 이미 답한거나 마찬 가지인데요 ^^;;

답은 "아닙니다" 입니다.

CGI 는 표준입니다. 프로그램과 웹서버 사이에 데이터를 어떻게 주고 받을 것인가에 대한 표준입니다. 보통의 경우 GET 요청의 경우 환경변수로 전달을 하고 POST 의 경우 표준입력으로 받는 것으로 알고 있습니다. 그 밖의 전달 형테는 CGI 라고 보기 힘들죠. 정의 그대로는요. 텀즈의 정의를 조금만 깊게 생각해보면 아파치 모듈로 돌아가는 php 는 cgi 가 아닌 것을 금세 알수 있습니다.

"웹서버에 있어 사용자의 요구를 응용프로그램에 전달하고 그 결과를 사용자에게 되돌려주기 위한 표준적인 방법이다"

아파치 모듈로 올라가게 되면 아파치 프로세스 내에 이미 php 가 내장 되어 있으므로 "웹서버와 응용프로그램에 전달하고 그 결과를 사용자에게 되돌려주기 위한 표준적인 방법"이 필요 없습니다. 어차피 같은 프로세스 내에 엤으니 메모리 상에서 전달하면 됩니다. 그렇다고 fastcgi 도 cgi 는 아니죠. 말 그대로 "표준적인" 방법인데, fastcgi 가 데이터를 전달하는 방식은 "그 표준적인" 방법이 아닌 다른 방식을 사용하는 것 이니까요.

그리고 제가 php 를 cgi 방식으로도 동작시킬 수 있다고 한 것은, cgi 방식으로 동작시키지 않을 수도 있다고 한 것이고, 그 말에는 cgi 방식으로 동작시키지 않는다면 cgi 방식이 아니다라는 뜻도 됩니다.

정리해서 mod_php 로 돌아가는 php 는 cgi 가 아닙니다.

2006/11/22 정정: mod_php 로 돌아가는 php 구현도 cgi 를 준수 할 수도 있습니다. 아래쪽 댓글 참조.

^_^의 이미지


php로 fastcgi 방식으로 운영이 가능하기 때문에 ^^

그리고 저희 서비스는 php가 fastcgi방식으로 구동하고 있습니다.

성능 괜찮습니다. 아주 만족중입니다. ^^
----------------------------------------------------------------------
웃는 얼굴 헤죽 헤죽

----------------------------------------------------------------------
웃는 얼굴 헤죽 헤죽

ironiris의 이미지

CGI는 동물이고
php, asp, jsp 는 각각 닭, 개, 소로 보시면 되겠네요.

puaxx의 이미지

말씀하신대로 라면 php,asp,jsp 이런것들도 결국은 CGI의 부분집합이 된다는 말씀이시군요.
그럼 php,asp,jsp도 CGI라고 통칭할수 있는것이란 말씀?

ironiris의 이미지

일단 cgi로 사용하려고 만든 언어고
언어에 따라서는 단독으로 사용할수 있는 언어도 있고
웹서버의 모듈로 작동하는 경우가 있어서 집합을 벗어날수있지만
CGI는 광의의 뜻을 가지고 있는 것은 맞습니다.
요즘은 C로 컴파일한 바이너리나 펄로 작성된 것을 CGI로 부르는 경우가 있긴 합니다만..

소타의 이미지

지금까지 달린 답글을 다 보시면 답이 될 것 같은데;;
왠지 말장난처럼 되어가네요 ㅋㅋ

CGI는 그냥 규약입니다. 일단 통념이 시간이 지남에 따라 잘못된 의미라는 것부터 시작하시죠?
보통 C로 작성된 CGI이고 아파치 웹서버라면 프로세스 fork, 환경변수 세팅(HTTP헤더, POST데이터, 서버 정보 등), stdout을 클라이언트 소켓과 파이프로 이음 등의 작업등이 일어납니다. CGI는 이 모든 동작이 일어나는 프로그램을 칭하는게 아니라 데이터를 주고 받는 방법에 대한 것입니다.
PHP가 웹서버에 모듈로 포함되어도 _SERVER 라는 변수 안에 CGI에 규정된 대로 데이터가 세팅됩니다. 위의 프로세스 fork방식일 때도 마찬가지고요.

PHP자체가 CGI는 아닙니다. C로 작성된 프로그램도 CGI가 아닙니다. CGI를 따르게 만들어져서 웹서버에서 사용할 수 있는 프로그램들인 겁니다.
PHP같은게 CGI에 속하느냐 아니냐 보다는 그 동작 방식들의 차이와 CGI의 의미를 정확히 아시는게 더 도움이 되지 않을까요?

php, asp, jsp도 CGI라고 통칭할 수 있냐는 질문에는 NO입니다. 질문 자체가 잘못되었기 때문입니다. php, asp, jsp도 CGI를 따르고 있냐고 물으셔야 합니다.

puaxx의 이미지

이야기가 자꾸 겉만 맴도는군요.
그리고 제가 말하는건 PHP자체를 말하는게 아닙니다 ^^;;

말씀잘하셨습니다.
그렇다면 PHP,ASP,JSP는 CGI를 따르고 있는겁니까?

위의 질문에 대한 답변이 제일 궁금합니다. 누가 제 궁금증을 풀어주시려나..

소타의 이미지

일단 PHP는 따르고 있습니다.
JSP, ASP는 잘 모르겠습니다; 관심이 없어서 -.-

세이군의 이미지

원래 의도와는 다른 내용의 답글이 먼저 올라간 스레드네요.
소타님이 이야기한 대로 CGI는 규약입니다.
어떠한 프로그램의 일종으로 볼 수 있는 것이 아닙니다.

웹 서버는 정적 파일 - 이미지, HTML문서 - 를 보내기 위한 프로그램입니다.
그렇기에 동적으로 바뀌는 내용(예를 들어, 게시판 글 목록)이 전달이 되려면 웹서버 자체로는 해결이 안되겠지요. 이를 해결하기 위한 것이 외부 프로그램을 불러서 그 프로그램의 결과를 대신 전달해주는 방법을 만든 것입니다. 이 때 외부 프로그램을 부를때 규칙을 정해서 전달하게 하면 외부 프로그램을 작성/사용할 때 편할 것입니다.

그 규칙을 CGI(Common Gateway Interface)라고 한 것입니다.
이 규칙을 지키지 않고서는 절대로 웹 서버에서 호출을 받거나 웹서버로 결과를 전달할 때 기대했던 결과를 얻지 못합니다.

PHP, ASP, JSP 모두 CGI 규칙을 지키는 프로그래밍 언어입니다.(프로그램이 아닙니다.)
ASP는 항상 웹서버의 모듈 형태로 동작을 합니다.(ASP.DLL 파일)
PHP,JSP는 웹서버의 모듈 형태로 동작할 수도, 별도의 프로그램으로 동작할 수 있습니다.

CGI하고 CGI프로그램하고 분리해서 생각하는 것이 필요합니다.

한 걸음 더 가까이

puaxx의 이미지

답변 주신 모든 분들께 감사드립니다.^^

Necromancer의 이미지

php는 cgi형태로 돌아갈 수도 있고, 웹서버에 내장할 수도 있습니다.

cgi형태로 돌아가면 PHP코드를 분석 실행하는 인터프리터가 외부에 존재합니다.
웹서버는 php 파일에 대한 요청이 들어올때마다 php 인터프리터 실행시키고 통신합니다.
이때 통신하는 방식이 CGI 규약입니다. (환경변수 세팅하고 뭐 하고 등등...)

하지만 웹서버에 모듈로 내장된다면 웹서버가 PHP코드를 직접 인터프리팅하죠.
이때는 CGI규약하고는 전혀 상관이 없습니다.
웹서버에 내장된 모듈은 PHP에 대한 요청이 올때마다 웹서버와 통신하는데,
이것들은 파이프나 소켓 필요없이 웹서버 프로세스 내에서 다 처리됩니다.
아파치면 아파치 고유의 형식이 있을꺼고 M$ IIS라면 ISAPI를 이용합니다.
성능은 웹서버 내장이 훨씬좋죠.

결론은 PHP != CGI입니다.
내장이면 CGI랑 전혀 상관없고
CGI 형태로 돌아간다면 CGI프로그램에서 인터프리팅되는 스크립트 언어죠.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

puaxx의 이미지

이거 의견이 사람마다 분분하네요...저의 얕은 지식 때문에 감히 결정을 내리지 못하겠습니다.

소타의 이미지

네크로멘서님 말씀도 맞긴 맞습니다.
php가 서버에 모듈로 포함된 경우 요청이 들어올 때부터 php모듈이 넘겨받아서 처리하기 시작합니다.
하지만 이때도 php는 환경 변수 $_SERVER, $_ENV 등 을 CGI모드로 움직일때와 "거의" 동일하게 세팅하고 처리합니다.
큰 그림으로 보면 php가 서버에 모듈로 들어가더라도 CGI의 규약을 지키고 있게 됩니다. fork, pipe 등의 작업이 CGI의 필수 동작은 아니거든요.
그렇게 따지면 FastCGI도 CGI가 아니라는 말이 될 수 있습니다.
CGI는 규약이고 클라이언트의 요청에 따라 웹서버가 어떤 프로그램(데몬이든 프로그램이든 스크립트든)을 돌릴 때 그 프로그램과 통신하는 방법에 대한 것이기 때문에 클라이언트가 결과 화면을 볼 수만 있다면 "CGI를 따르고 있다"라고 봐야 합니다.

단, 아래에 제가 jsp와 asp는 잘 모르겠다고 해놓은 것은 네크로멘서님의 글에서 처럼 내부적으로 독자적인 방식을 취하고 있는지 알 수 없기 때문입니다.
php외에 python, perl같은 경우는 php와 같이 서버모듈, 외부 인터프리터 두가지 모두 가능하며 CGI를 따르고 있습니다.

purple의 이미지

비슷하긴 하지만 기원이나 처리 방식이 다르지 않은가요?

CGI라는 것은 동적 웹 페이지를 생성하기 위해 웹 서버와 외부 프로그램이 통신하는 규약입니다. 웹 서버가 CGI 인터페이스를 갖추고 있다면 어떤 프로그래밍 언어로든 규약(환경 변수, 표준 입력/출력)에 맞춰 작성하기만 하면 웹 프로그램이 되는 것이죠.

이에 반해 mod_php, mod_perl, mod_python 같은 것들은 웹 서버 API를 이용한 것입니다. 웹 서버 자체의 확장 개념에서 발전하여 전용 프로그래밍 인터페이스를 제공하여 모듈로서 웹 서버 자체에 붙일 수 있게 한 것이죠. mod_php 등등은 모두 아파치 모듈 api를 이용해 만든 것입니다. 넷스케이프 서버의 NSAPI, MS IIS의 ISAPI (이것의 일부가 asp), 자바 웹 서버의 Servlet/JSP 등이 모두 이 개념에 속하는 것입니다. 이것은 CGI와는 달리 웹 서버의 확장이기 때문의 웹 서버의 기능을 모두 이용할 수 있습니다. CGI가 http 트랜잭션 중 request를 읽고 response를 생성하는 단계만을 다룰 수 있는 반면에 웹 서버 API는 제공되는 모든 단계를 다룰 수 있는 것입니다.

php는 이와는 다른 개념입니다. 현재 상태는 CGI 든 웹 서버 API 든 상관없이 웹 프로그램을 실행할 수 있는 언어 또는 환경이라 보면 될 겁니다. 그 구현으로 CGI 를 이용할 수도 있고 웹 서버 API를 이용할 수도 있는 겁니다. 다만 초창기 php가 perl로 만들어진 CGI 였기 때문에 지금도 CGI의 유산을 가지고 있는 것일 뿐입니다. 또한 웹 서버 API 들로 만들어진 여러 모듈들도 CGI 이후에 나온 것들이 많기 때문에 CGI의 규약을 많이 따온 것입니다.

소타의 이미지

"큰 그림으로 보면" 이라는 전제를 단 이유가요. 아파치를 예로 들겠습니다.
아파치는 php나 perl만을 위한 특별한 확장을 지원하고 있지는 않습니다. 기존의 fork방식의 CGI지원 외에 내장 외부 모듈을 통해 처리하기 위한 확장을 제공하고 mod_* 종류들은 이 인터페이스를 이용하는 것이죠. CGI를 위해 아파치 자체가 fork되어야 한다면 그것은 아파치 자체의 프로세스 모델과 성능에 대한 운신의 폭이 좁아지는 것이고 mod_perl, mod_php등의 새로운 개념들이 나오면서 아파치는 그런 제약을 벗어날 수 있는 계기가 됩니다. 물론 호환성과 안정성을 위해 아직도 prefork를 사용할 수 있긴 하지만요.

CGI스펙을 보시면 아시겠지만 웹서버와 요청에 대한 정보를 "웹서버가 어떤 환경 변수 이름으로 넘겨준다"와 프로그램의 stdin와 stdout을 "웹서버가 POST데이터를 넘기고 output을 넘겨받아서 처리한다"는 규약입니다. 아파치는 모듈들에게 CGI규격에 맞는 환경변수를 세팅해 줍니다. mod_php고 perl이고 python이고 C로 만든 외부 모듈이건 간에요. 그리고 모듈들이 밷는 값들을 아파치가 받아서 클라이언트에게 전송해 줍니다.

동작방식이 다른것은 fork가 일어나지 않고 stdin과 stdout pair가 pipe로 되지 않고 웹서버가 redirect시킨 다는 것인데 fork를 하고 말고는 CGI의 필수 요소가 아니고 stdin, stdout은 웹서버가 더 효율적인 방식으로 대체해주는 식입니다.
동작 방식이 기존의 CGI라고 불리는 방식과는 다르긴 합니다. 그래서 다른 글들에 "통념"이라는 것에 대해 나와 있고요. 제가 얘기하고 있던 부분은 이 통념적인 CGI가 아니걸랑요~
PHP != CGI는 맞습니다. perl != CGI, python != CGI도 맞구요. 하지만 이것들이 웹서버(아파치 포함 다른 웹서버들 포함)와 엮여서 쓰이려면 CGI라는 표준을 준수해야 한다는 것이죠..

purple의 이미지

웹 서버와 엮여서 쓰이려면 CGI 표준을 준수해야 한다고 하셨지만 그런 거 같지 않습니다.

CGI는 환경 변수로 여러 정보를 제공하고 POST 데이터는 표준 입력으로 보내 줍니다. 그렇지만 웹 서버 API는 여러 정보를 알 수 있는 전용 함수 또는 객체를 제공합니다. 아파치 API라면 request_rec, server_rec 구조체일 꺼고 PHP 라면 $_SERVER. $_GET, $_POST 등등이며 자바라면 HttpRequest 객체입니다. 몇몇 CGI 라이브러리에 있는 것처럼 환경 변수와 표준 입력으로 들어온 것들을 라이브러리로 포장한 게 아닙니다. 소켓을 통해 웹 서버로 들어온 것을 직접 객체 또는 함수로 제공하는 것입니다.

출력도 마찬가지입니다. 아파치 API이면 ap_* 등등의 함수이고, php이면 echo 함수이고, 자바이면 HttpResponse 객체입니다. 마찬가지로 CGI 라이브러리처럼 표준 출력으로 바꿔서 보내는 것이 아닙니다. 모두 웹 서버로 직접 보내는 것입니다.

웹 프로그램의 기본 동작이 여러 서버의 정보와 request를 읽고 response로 출력하는 것입니다. 따라서 CGI 든 웹 서버 API든 동작 방식은 비슷할 것입니다. 그러나 그렇다고 해서 같은 것은 아닙니다.

웹 서버 API는 직접적인 웹 서버와 연결 수단입니다. 현재는 웹 서버 API로 CGI를 구현합니다. 아파치의 mod_cgi가 그런 것이죠. 자바 웹 서버도 API인 Servlet API를 이용해서 CGI를 지원할 수 있게 할 수 있습니다.

소타의 이미지

웹서버와 어떤 형태의 모듈이건 간에 넘겨주고 넘겨 받을 일이 있다고 치면요.
CGI라는 규격이 없다면 어떤 형태든 간에 서로 약속된 포맷이 있을 겁니다.
mod_php의 포맷이 있겠고 mod_python의 포맷이 있겠고, mod_perl도 마찬가지입니다. 이것들이 모두 다른 포맷을 요구한다면 어떨까요? php와 perl, python에서 출력하는 동작을 할 경우에 모두 다르게 동작한다면 어떨까요?

CGI는 이런 부분에 있어 데이터를 주고 받는 표준적인 규약입니다.

아파치는 php만을 위한, perl만을 위한, python만을 위한 API를 제공하지 않습니다. CGI 규격에 맞춘 환경 변수를 제공하는 API를 제공할 뿐입니다. 아파치+PHP라고 해서 아파치의 코드가 달라지거나 하지 않습니다. php에서 $_SERVER, $_ENV를 보면 CGI규격대로 환경 변수를 전달하고 있는걸 알 수 있습니다.

다른 웹서버라면 어떨까요? mod_php를 지원하는 웹서버는 많습니다. 각 웹서버가 제공하느 stdin, stdout에 대한 대체 API가 존재할 테죠. 환경 변수를 받는 방법도 각 웹서버마다 다를테구요.
CGI규격을 따르지 않고 $_SERVER나 $_ENV의 내용이 달라진다면 php로 작성된 프로그램의 코드가 달라져야 합니다. CGI같은 표준적인 규약을 언어들이 지키는 이유는 다른게 아닙니다.

CGI는 동작하는 방식에 대한 규격이 아니라 전달하고 전달 받는 형식에 대한 규격입니다..

CGI를 준수하지 않고 하는 방법이 없는건 아닙니다. 전용 CGI 규격이 없어도 상관없는 웹서버를 만들던지 특정 웹서버에만 동작하게 만들면 됩니다.
CGI는 mod_* 계열이 지키고, 웹서버들이 지원하는 규격일 뿐이지 동작 방식에 대한 제한이 아닙니다.

앞글에서도 썼듯이 PHP, perl, python != CGI 입니다
CGI는 꼭 fork, 환경변수 세팅, stdin/stdout pair pipe가 있어야 하고 이처럼 동작해야만 하는 "동작"에 대한 규약이 아닙니다.

적다보니 이전글과 같은 말만 되풀이 하고 있습니다.
CGI는 프로그램이 아니라 규약입니다. <- 이 한 줄로 많은 설명이 되면 좋겠네요. CGI라는 규약을 따르느냐 아니냐 로 이야기 해야 맞습니다.

wish의 이미지

보통 일반적으로 CGI 는 환경 변수, 표준 입출력을 거치는 경우를 가르킵니다.

그리고 http://cgi-spec.golux.com/ 등에서 볼 수 있는 CGI 스펙도 환경 변수(meta-variable로 나와 있네요), 커맨드 라인, 표준 입출력 을 이용해서 데이터를 전달하는 것이구요.

그런데 다른 프로세스를 뛰우지 않고 환경 변수나 커맨드 라인, 표준 입출력으로 데이터를 전달 할 수 있을까요? mod_php, mod_python, mod_perl 은 제가 알기로 처리 하는 방식이 모두 다 다릅니다. CGI 표준과는 전혀 상관 없이 구현되어 있을 거라고 생각합니다. 오히려 저 모듈들은 Apachi API 를 공통분모로 사용하죠. 아파치 모듈과 아파치 서버는 하나의 프로세스인데 굳이 표준 입출력이나, 환경 변수를 쓸 필요가 없을 뿐더러 쓰기도 어렵지 않을까요?

물론 CGI 사용자들 편하게 하기 위해서 CGI 에서 쓰는 변수를 유사하게 제공하는 것은 가능하지만, 엄밀하게 CGi 라고 하기는 힘듭니다.

아파치 코드가 달라지지 않는 이유는 아파치가 모듈을 위한 범용적인 API 를 제공해서 이지 CGI 표준이 있기 때문이 이닙니다. 결정적으로 사용자 입장에서 mod_php 와 mod_python 을 사용하는 방법은 완전 다릅니다.

님 말씀대로 CGI 는 프로그램이 아니라 전달하는 규격이 맞습니다. 다만 mod_php 나 mod_perl 등이 아파치 서버로 전달하는 방식은 CGI 가 아닙니다. 애시 당초 전달이라는 말이 더 이상합니다. 어차피 같은 주소공간에 있는데 굳이 전달할 이유도 없습니다. 바로 가져다 쓰면 그만입니다. 함수 호출을 하든 전역 변수를 쓰든 말이죠. 그리고 $_SERVER나 $_ENV 가 CGI 표준과 비슷한 변수라고 해도 CGI라고 부르기 어렵습니다. 다만 CGI 에 익숙한 사용자들이 쓰기 편하도록 그런 변수를 프로그래밍 상으로 제공할 뿐이죠. mod_python 을 보시면 cgi 와는 전혀 다르게 전달한다는 것을 아실 겁니다. 적어도 cgi 에는 파이썬의 사전 형식으로 데이터를 전달한다는 규약은 없지요.

사실 딴지를 걸고자 하기 보다는 일반적으로 컴퓨터 하는 사람들끼리 소통할 때 CGI 하면 환경변수와 표준 입출력을 세팅하고 프로그램을 실행하는 뜻으로 많이 씁니다. 굳이 엄밀하게 따져도 위에서 언급했듯이 평소 쓰는게 맞구요. 보통 fastcgi 나 scgi, 모듈 등의 방식은 CGI 가 아닌 CGI 의 대안이라고 하는 경우가 많습니다. 혹시나 소타님의 댓글 때문에 CGI 가 웹서버와 소통 하는 모든 방식으로 착각할까봐 굳이 씁니다. 사실 CGI 든 아니든 그게 중요한 게 아니지만, CGI 는 딱 정해진 규약이고 적어도 웹서버 모듈 들은 그 규약을 지키지도 않을 뿐더러 지킬 수도 없고 지킬 필요가 없다는 점을 말씀 드리고 싶습니다 ^^

소타의 이미지

제 글의 전제는 CGI != PHP이고 CGI 라는 단어가 통념적으로 말하는 그 CGI 프로그램이 아니라 전달하는 방법에 대한 스펙이라는 데서 시작합니다 -.-

php가 통념적인 CGI 처럼 움직일 때는 웹서버가 환경변수로 정보들을 세팅해 주고 파이프를 엽니다.
php에는 웹서버가 넘겨주는 정보를 토대로 _SERVER 등의 슈퍼글로벌 변수들을 세팅하는데 이것들 담당하는 함수가 mod_php로 될때는 다른 함수로 wrap되는 것입니다. echo 도 마찬가지고요.. stdout으로 내보내는 함수가 웹서버의 API를 사용하도록 wrap되는 것 입니다.. 웹서버가 stdin, stdout을 특정 함수를 통해 제공하는 셈입니다.

stdin, stdout, 환경변수를 사용하는 부분들이 레이어처럼 한단계 씌워져 있는데 이것들이 웹서버랑 엮이냐 엮이지 않느냐에 따라 다른 함수로 wrap되는 방식입니다. php, perl, python 은 이것들을 지키고 있어서 CGI 스펙에 맞다고 한거구요..

웹서버에 독립적은 모듈은 만들기는 쉽지 않습니다. 위와 같은 부분들 중 대부분을 추상화 해서 웹서버마다의 인터페이스와 엮어줘야 합니다.. 특정 웹서버에 의존적이고 그 웹서버의 low level API를 사용한다면 CGI표준을 지킬 필요가 없겠죠.. 웹서버의 확장 기능을 만드는 것 이니까요.. 아파치의 mod_rewrite 뭐 이런게 여기에 속하겠죠.. 저도 이런건 CGI라고 보지 않습니다.

제가 이 글 자체의 의도를 잘못 파악한건지 모르겠는데요;;
mod_php 자체는 CGI가 아니라고 생각하지만 mod_php로 인해 동작하는 php파일들은 CGI규격에 따라 전달된 데이터들을 이용하므로 CGI에 준한다고 생각하고 있습니다.

purple의 이미지

php의 경우는 CGI에 준한다기 보단 영향을 받았다 정도가 맞지 않을까 하는 생각이 듭니다.

CGI 홈페이지에서는 환경 변수, 표준 입력, 표준 출력을 이용하는 통상적인 CGI 개념인데 rfc 3875 문서는 소타님의 말씀대로 데이터 전달 방식이 아닌 규약 개념이더군요. 그런데 rfc 문서의 작성 연도가 2004년인 것을 보면 최근에 그 개념을 더 확장한 것이 아닌가하는 생각이 듭니다(CGI가 웹 초창기부터 사용되었던 기술이었다는 것을 감안한다면 2004년은 꽤 최근인 거죠)

그것을 감안하더라도 php의 방식은 CGI와는 사못 다른 면이 있지 않나는 생각을 합니다. $_SERVER 변수로 meta variable 들을 보내긴 하지만 message body와 response 부분은 꽤 다른 것 같습니다. 더욱이 php 홈페이지에서 찾아봐도 php에 대한 설명, 매뉴얼, 업데이트 뉴스 등 어디에서도 php를 CGI 규약에 맞췄다는 언급은 찾을 순 없습니다. 따라서 php의 경우는 CGI에 준한다기 보단 영향을 받았다 또는 유산(?)을 가지고 있다 정도가 맞지 않을까 생각합니다.

mod_php와는 달리 mod_perl, mod_python 등은 apache api에 접근할 수 있게 하는 데 더 중점을 둔 것 같습니다. 이 경우는 따라서 CGI와 더 멀어지게 되죠.

ㅡ,.ㅡ;;의 이미지

그게 아니고 웹으로 질의를 받고 그에대해 응답을하는것모두가 CGI 라 합니다..

따라서 대부분 php는 Cgi를 구현하는데 사용하죠


----------------------------------------------------------------------------

Necromancer의 이미지

맞죠.

PHP변수하고 CGI에서 전달하는 환경변수하고는 전혀 관계 없습니다.
다만 기존에 CGI를 했던 분들을 고려해서 CGI 환경변수에서 제공하는 내용과
유사한 내용을 제공하기 위해서 인터프리터가 실행전 특정 변수들을 미리
세팅해 놓을 뿐입니다.
(인터프리터는 서버내장일수도 있고, CGI 프로그램으로 돌릴 수도 있습니다. 앞에서도 얘기했습니다)

그렇게 하는데는 CGI로 전달되는 환경변수들 중에 유용한 것들이 많이
있기 때문이죠. 또한 스크립트 언어 초창기에 CGI가 널리 쓰였던
것도 한몫 했고요.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

Prentice의 이미지

사족이지만 “PHP도 CGI인가요?”라는 질문을 보니 “한국영화도 멜로인가요?”라는 질문이 떠올랐습니다.

notnull의 이미지

이야.. 이거 외국 웹 개발자 들이 보면 챙피해 죽을 만한 질문과 답이군요.-.-

꼭 웹마스터는 웹에 대한 총체적인 부분을 이해하고 관리하는 사람인가요 라는 질문에..
웹마스터랑 프로그래머, 서버관리자는 동일하지 않습니다. 라는 대답이 나오는 거랑 거의 비슷해 보입니다.

대답 하시는 분들 언제부터 개발을 시작하셨는지 모르지만 CGI 는 개념입니다.

[웹서버와 사용자간의 통신]

이 자체가 CGI 의 개념이지..

[웹서버와 사용자간의 통신방법] 혹은 [프로그래밍적 구현방법]
을 논하는 이름이 아닙니다.

예전에 웹용언어가 별도로 없을때 C 랑 perl 로 만든 웹프로그램들이 확장자를 cgi 로 하니까 그런가 보다 하시는 모양인데요..어이구..그거 아닙니다..

아무래도 학원이나 학교에서 준비를 제대로 안한 강사들이 그런식으로 가르친 모양인데요 웹이 사용자에 요청에 의하여 동적으로 구현될 수 있으면 그거 자체가 CGI 를 구현한거라는 겁니다. 언어의 도구가 무엇이든은 상관없습니다. 그건 인터프리터냐, 컴파일언어냐 등과는 상관 없다는 거지요..

물론 외국에서 들어오는 문장이니 해석이 불분명 해 질 수 있긴 하겠지만 그래도 이건 아니라고 봅니다.

웹마스터는 홈페이지 관리자가 아니라 웹 구현에 관련된 총체적인 기술을 가지고 있는 사람을 초기에 일컫는 말이었습니다.
그런데 그게 우리나라 들어오면서 개나소나 명함에 웹마스터라고 파 다니는 바람에 아주 한심한 직업이 되어버렸지요..
근데 웹마스터가 그게 아닌거는 최소한 기술자라면 알아야 하지 않습니까..

CGI 도 그렇게 이해해 주십시오.. 새로 배우는 사람들 혼돈 됩니다. 이제라도 이 개념좀 제대로 잡고 나가야 하지 않겠습니까..
문장 자체를 어떻게 해석하느냐가 문제가 아니라 초기에 CGI 라는 문장이 어떤 의미로 생겨났는지를 알아야 하는겁니다.

웹마스터 라는 문장이 주는 모호함 때문에 웹마스터는 홈페이지 관리자 라는 공식이 성립하진 않지 않습니까.
그렇듯이 CGI 도 문장이 주는 모호함때문에 CGI 라는 말이 생겨난 근원은 보지 않고 시대에 맞게 재 해석 하지 말자는 겁니다.

익명사용자의 이미지

원문을 보고 싶군요. notnull 님이 말한 CGI의 개념, 또는 정의를 어디서 찾을 수가 있나요?
제가 옛날에 보았을 때는 CGI는 동적 페이지를 만들 수 있는 규약의 하나였던 거 같은데요. 물론 규약만 지키면 구현은 C로 하든 OCaml로 하든 전혀 상관이 없구요.

익명사용자의 이미지

더 무슨 말인지 모르겠습니다.

CGI 라는 게 웹 서버와 외부 프로그램간의 인터페이싱을 위한 표준(standard for interfacing external applications with information servers) 또는 표준 프로토콜이라고 알고 있는데 그게 아닌가요? 아니라면 정확한 내용을 알려 주셨으면 합니다.

익명사용자의 이미지

님께서 뭔가 잘못 생각하고 계시군요. CGI규약을 준수해야 CGI인것입니다.

http://hoohoo.ncsa.uiuc.edu/cgi/interface.html

Quote:

[웹서버와 사용자간의 통신]

이 자체가 CGI 의 개념이지..


무슨 엉뚱한 말씀이신지.. CGI를 고안했던 사람이 그런 생각을 했을진 몰라도, 우리가 늘상 얘기하는 CGI는 CGI규약을 지키는 프로그램들을 통칭하는 말입니다.
Darkcircle의 이미지

질문의 요지는 PHP가 CGI냐?? 이런건데... 개념상 질문이죠

지금 위에분들이 계속... "개념을 잘못 이해했다."
"PHP는 인터프리팅 언어이고... CGI는 서버에서의 클라이언트에 대한
요청접수/응답처리에 관련된 동작들에 대해 표준을 정의한 규약일 뿐이다."

라고 계속 말씀하시는데 CGI규약을 지키는 프로그램들이라면
아파치도 되고 Perl도 되고 심지어는 C언어도 CGI라는 얘기가 되네요...
그렇게 말씀하시면 Python도 CGI고 심지어는 이세상에 존재하는 모든 언어가 CGI가 되겠죠?
언어뿐만 아니라 IIS도 CGI가 되고 심지어는... _-_;;
(물론 GWBASIC이나 QBASIC, 포트란 같이 네트워크 프로그래밍에 안쓰는 언어 빼고요.)

프로그래밍 언어 + 서버 데몬 = CGI... 참으로 이상한 정의입니다. _-_;

--------------------------------------------------------------
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

Prentice의 이미지

그런데 그 이상한 정의가 옳은 정의일지도 모른다는 생각은 해보셨나요? (조금 오해하고 계신 것 같긴 합니다만..)

Perl로만 CGI 만드는 게 아니라 C로도 CGI 만들잖아요.

마잇의 이미지

웹서버를 통해서 네트웍 건너 사용자와 상호작용하는 프로그램을 만들고 싶다면?

원하는 어떤 언어로든지 프로그램 짜고 입력 받고 출력 내보내는 걸 CGI 규약에 맞추어 준다.
웹서버가 그 프로그램을 실행시키면서 CGI 규약에 맞게 입력 집어넣고 출력 받아서 사용자한테 뿌려줍니다.

이게 CGI의 전부 아닌가요?

find /usr/share | wc -l

find와 wc가 파이프로 입출력을 하고 있지만 어떤 언어로 쓰여졌는지는 상관없는것하고 똑같은 개념 아닌가요?
파이프로 입출력을 할 수 있게 구현한 것이지 파이프는 아닌
PHP로 CGI를 구현한 것이지 CGI는 아닌
--
마잇


--
마잇

Darkcircle의 이미지

"PHP로 CGI를 구현한 것이지 CGI는 아닌"... ← 제가 말하고 싶은 얘기가 요겁니다.

니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

익명사용자의 이미지

Quote:

사족이지만 “PHP도 CGI인가요?”라는 질문을 보니 “한국영화도 멜로인가요?”라는 질문이 떠올랐습니다.

ㅎㅎ 재밌는 비유입니다 :>

PHP로 만든 어플이 CGI를 준수한다면 cgi프로그램이 되겠죠, PHP는 CGI프로그램을 쉽게 만들게 해주는 툴/언어이고요.

PHP로 만들었는데도 CGI를 준수하지 않는 프로그램으로 만들어버릴 수도 있습니다. 엉뚱한 헤더 날리거나해서 Error가 나게 만든다거나.

그러므로 "PHP도 CGI인가요"라는 질문은 그럴듯하면서도 엉뚱한 질문인 것입니다. 뭐.. "필름이 영화인가요?"라는 질문과 같은

송효진의 이미지

Quote:

엉뚱한 헤더 날리거나해서 Error가 나게 만든다거나.

고의던 아니던 이건 말 그대로 '에러' 혹은 '편법' 이라고 봐야 하는것 아닐까요?
php 를 웹서버와 연동해서 사용하는 한,
php 는 cgi 규격을 준수하도록 동작하는게 맞는것 아닐까요?

--with-cli 로 컴파일하지 않는 한 cgi 규격을 준수한다고 보는게 맞을것 같습니다.

emerge money

emerge money
http://wiki.kldp.org/wiki.php/FuntooInstallLog - 명령어도 몇 개 안돼요~
http://xenosi.de/

kwon37xi의 이미지

CGI 는 인터페이스로 HTML 폼의 값을 받으려면 모두 CGI 인터페이스를 구현해야 합니다.
고로 Perl이나 C 기반 웹 어플리케이션,JSP, PHP, ASP 등도 무두 CGI 를 구현하고 있습니다.

헌데, CGI가 처음 등장할 시기에는 C나 Perl 로 CGI 프로그래밍을 했는데, 그 당시에는 모든 요청이 프로세스를 한개씩 띄워서 작동했습니다. 그래서 모든 요청마다 프로세스가 생성됐다가 죽었으며, 그로인해 웹 어플리케이션의 속도가 매우느렸지요.

그 이후 등장한 JSP, ASP, PHP 등은 프로세스를 띄우지 않고 일단 웹 어플리케이션 프로세스는 1개만 뜨고 그 이후 요청을 쓰레드로 처리하기 때문에 처리 속도가 향상되었습니다.

초기 CGI(프로세스 단위 수행)를 사람들이 그냥 CGI 로 불러서 일반적으로 CGI라고 하면 프로세스를 띄웠다 죽이는 초기 방식을 지칭하게 되었다는 거죠. 사실은 CGI의 의미는 "각 웹 요청을 프로세스 단위로 처리하는 것"이 아니라 "웹의 요청을 받아들여 동적으로 처리하는 인터페이스"이기 때문에 이것은 "프로세스 단위 처리"에 대해서 CGI라는 용어를 사용하는 것은 잘못된 것이 아닌가 싶습니다.
^--------------- 여기까지는 제 생각입니다.

CGI 라는 용어의 의미를 서로 다르게 사용하기 때문에, 지금 많은 사람들의 토론이 이리갔다 저리갔다 하는거구요.

결론 두가지로 내보면...

1. 프로세스 단위로 웹 요청을 처리하는 것을 CGI라고 지칭하는 것은 잘못된 것이다.
2. CGI는 HTTP 요청을 받아서 프로그래밍언어가 동적으로 처리하여 그 결과를 내보내는 인터페이스 이다.
3. 고로 C, Perl, JSP, PHP, ASP, Python, Ruby 뭐가 됐든간에, 그리고 요청 처리를 프로세스로 하던 쓰레드로 하던 간에 HTTP 프로토콜 요청을 받아서 프로그래밍 언어로 동적으로 웹 페이지를 생성하는 것은 모두 CGI이다.

그리고 또 다른 의견으로,
1. CGI는 웹으로 들어온 요청을 운영체제 환경변수로 설정하여 프로세스로 넘겨주는 인터페이스를 의미한다. 고로 (쓰레드 단위가 아닌)프로세스 단위로 웹 요청을 처리하는 것을 CGI라고 부르는 것이 맞다.
1. 결국, JSP, ASP, PHP 등과 같이 쓰레드 단위로 처리하는 것은 CGI가 아니다.

자.. 둘중에 어떤게 맞는겁니까?

http://kwon37xi.egloos.com

익명사용자의 이미지

CGI의 정의는 이걸로 충분한듯 하고 http://en.wikipedia.org/wiki/Common_Gateway_Interface
PHP는 프로그래밍 언어입니다. 거기에 무슨 의미를 더 갖다붙이시려는지 의도를 모르겠습니다.

그리고 ASP는 언어가 아닙니다. 물론 통상적으로 ASP 한다하면 vb스크립트를 애기하지만요.

puaxx의 이미지

제가 PHP가 프로그래밍 언어인지 몰라서 물었나요?
그리고 제가 무슨의미를 더 가져다 붙이려고 했다는지 모르겠군요.
솔직히 익명님이 글을 쓴 의도를 더 모르겠습니다.

Prentice의 이미지

그래서 한국영화는 멜로인가요?

puaxx의 이미지

아 진짜 너무하시네요.. 에효 제가 괜히 글올려서 비꼬임 당하는군요..
더이상 이 글에는 신경 쓰지 않겠습니다.그럼..

익명사용자의 이미지

점잖으신 검은해님께서 무엇때문에 꼬이신 건지..
질문자는 별 잘못이 없는듯한데.

lazycoder의 이미지

PHP도 CGI인가요?

별도의 애플리케이션 서버와 통신하지 않는 이상 CGI 프로그램 범주안에 넣을수는 있습니다.

그러나 애플리케이션 서버의 역할을 또 다른 어떤 놈이 맡고있거나
아키텍쳐가 3티어가 확실하다면 명확히 CGI라고 할 수 없는 경우도 있을겁니다.

JSP나 특히 ASP의 경우 일반적으로 별도의 프로세스로 동작되기에 웹서버는 이놈을 호출합니다. default.asp를 요청했다고 해서 웹서버가 default.asp와 대화하진 않습니다. http handler에의해 다른 프로세스가 처리하니까요. 따라서 CGI방식은 아닌것 같습니다.

아아.. 답이 지붕과 벽 그리고 사람이 있으니 가정이라고 볼수도 있습니다만 대문이 없거나 사람이 부족하면 가정이 아닙니다라고 하는것 같긴합니다.

죠커의 이미지

이 쓰래드가 필요없이 길어진다는 느낌이 듭니다만 간략히 글을 남겨봅니다. 먼저 puaxx님이 적으신 글을 인용해보겠습니다.

"클라이언트의 요청을 서버에서 받아 그 요청을 다른 응용 프로그램으로 넘겨서 필요에 따라서 그 결과를 다시 서버로 보내 서버에서 클라이언트로 그결과를 다시 보내는 이런 일련의 규칙"

이런 개념이 한 두개이겠습니까? 애초에 puaxx님이 올리신 설명은 잘못된 것입니다. CGI의 가장 차별화된 부분은 표준 입출력에 의존하고 있다는 점입니다. 단순히 표준 입출력이라고 규정하면 세부적인 부분에 문제가 생기기 때문에 구체적인 내용은 CGI 스펙에 규정되어 있습니다. 따라서 CGI는 CGI 스펙을 지키는 환경과 프로그램을 총체적으로 언급하는 단어라고 볼 수 있을 것입니다.

그럼 puaxx님이 질문하신 PHP가 CGI이냐는 질문에 대해서 살펴봅시다. PHP는 일단 "언어"를 의미합니다. ASP가 구현을 의미하는 것과는 달리 PHP는 언어 자체만을 의미합니다. 이 PHP의 구현이 어떻게 되어있을지는 전적으로 환경에 달려있습니다. 윈도 서버에서 php.exe로 돌아가고 있을 수도 있고 리눅스 서버에서 아파치에 mod_php로 돌고 있을 수도 있습니다. 이것을 크게 아파치나 윈도우즈와 같은 서버에 모듈로 도는 경우와 소켓을 통해서 서버와 교환하는 FAST-CGI 방식, 그리고 마지막으로 CGI 스펙에 맞추어 자료를 교환하는 CGI 방식이 있을 것입니다. 이 중에 CGI 방식인 것은 마지막의 CGI 스펙에 맞추어 자료를 교환하는 경우에 한정됩니다. 따라서 PHP가 CGI냐 아니냐는 질문에 대한 답변은 어떻게 구현(or 설정)했는냐 따라 다르다는 것입니다.

소타님이 아파치 모듈등의 이야기를 하셨는데 저는 여기에 동의하지 않습니다. 아파치의 모듈을 구성하는 방식이 CGI와 유사하다면 "유사한 인터페이스"를 가진 것입니다. 자연환경과 프로그래밍은 자기복제성을 띄는 경우가 허다하고 우수하다고 생각되는 인터페이스는 쉽게 모방됩니다. 게다가 이들이 PHP냐 파이썬이냐에 따라 다른 인터페이스를 가지지 않는다는 것은 당연한 일로 생각합니다. "공통적인 인터페이스"를 가지고 있지 않다면 어떻게 아파치에 "교체 가능한 모듈"이 장착이 가능하겠습니까?

- CN의 낙서장 / HanIRC:#CN

소타의 이미지

저는 PHP가 CGI라고 한적도 없고 아파치 모듈이 CGI라고 한적도 없는데요?;; 이것들이 CGI일 수는 없습니다. "CGI를 따르고 있다" 라고 해야 맞죠.. 이 글은 처음 질문 자체가 잘못되어 있었던 겁니다.
PHP가 CGI 규약을 따르고 있나요? 라는 질문이어야지 CGI의 범주에 PHP가 속하나요? 라는 질문은 대상 자체가 다른것이죠..

이 글이 계속 올라오는걸 보면서 적고 싶은게 있었습니다..
<?php var_dump($_SERVER["GATEWAY_INTERFACE"]);?>

PHP != CGI 입니다. CGI의 정의에 대해 다른 생각을 가진 사람들이 많은것 같습니다.

http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html
최신의 CGI/1.1 스펙문서입니다.

곁다리로 FastCGI는 왜 기존의 CGI와 동작방식이 다른데 CGI라는 단어를 사용했을까요? 이름 짓는거야 멋대로라지만요..
동작방식의 변화로 빨라졌을 뿐이기 때문입니다. CGI 스펙에 보시면 fork라는 단어는 찾을 수 없습니다. 인터페이스일 뿐인 CGI가 왜 동작방식이나 언어와 연관되어야 하는지 모르겠습니다.

통념의 CGI
1. fork 후 환경변수 제공
2. 파이프와 stdin, stdout 엮기
3. stdin으로 쿼리스트링 및 POST데이터 제공
4. stdout으로 헤더와 바디 내보내기

하지만 CGI 스펙에서는
1. 메타데이터를 "어떤 방식으로든 반드시 제공할 것"
2. 데이터를 전달할 방법을 "어떤 방식으로든 반드시 제공할 것"
3. 결과를 전달받을 방법을 "어떤 방식으로든 반드시 제공할 것"

라고만 되어 있습니다. 어떤 방법도 없을 때는 stdin, stdout 등에 대한 언급은 있습니다. 이런 애매모호한게 무슨 표준이냐고요
CGI에는 "어떤 방식으로 반드시 제공할 항목의 이름과 내용, 문법에 대한 규약"일 뿐입니다.
웹서버를 만들고 CGI 구현을 위해서는 꼭 넘어가야할 부분입니다.

wish의 이미지

스펙을 대충 다시 읽어 보고 나니 음... 위에 제가 쓴 글 중 일부는 완전히 틀렸습니다. 그리고 이제서야 소타님의 의도가 제대로 이해 되었습니다. 제가 말했던 CGI의 환경변수, 표준입출력을 통한 통신 방식은 CGI 의 스펙의 필요조건이 아니네요. 명확하게 소통할 인터페이스만 정의해 주면 되는군요. 구체적으로는 'server' 와 'script' 간의 통신에 필요한 인터페이스를 '나름대로' 정하고, 나름대로 정하지 않을 경우 표준입출력을 사용한다. 그리고 인터페이스를 통해 server 에서 script 로 가는 데이터는 주어진 'meta-variable'을 사용해야 하는데, 따로 정의하지 않을 것이면 '환경변수'를 써라. 이게 핵심이었군요. 스펙을 제 멋대로 곡해하고 글을 쓴 부분에 대해서는 사과드리겠습니다.

이 세 용어를 정의 하는 부분에서 한방 맞은 듯한 느낌입니다. 통념과 스펙이 따로 놀았던 거군요. 저는 설마 script 가 저런 정의를 가졌을 줄은 정말 몰랐습니다. 이전에 스펙을 훑을 때도 그냥 대충 보고 넘어간 듯 하네요.

Quote:

metavariable
A named parameter that carries information from the server to the script. It is not necessarily a variable in the operating-system's environment, although that is the most common implementation.

script
The software which is invoked by the server via this interface. It need not be a standalone program, but could be a dynamically-loaded or shared library, or even a subroutine in the server. It may be a set of statements interpreted at run-time, as the term 'script' is frequently understood, but that is not a requirement and within the context of this specification the term has the broader definition stated

아예 못 박아 났군요. 특히 스크립트 정의 마지막 문장 참 대단합니다. '스크립트'라는 일반적인 용어는 실시간에 인터프리트 되는 statements 의 집합이지만 여기서의 스크립트가 그럴 필요는 없고 이 문맥에서는 더욱 넓은 정의를 가지는 것으로 되어 있네요. 그런데 script 라는 단어 자체가 오해를 불러일으키기 딱 좋은 듯한 느낌은 지워지지가 않는군요. ;

게다가 7.2 절에는 유닉스에서는 메타변수들이 환경변수로 정의 된다고도 써 있네요. ;;; 굳이 운영체제의 변수일 필요는 없다고 되어 있으면서도 이런 부분도 들어가 있군요... 머 SHOULD 나 MUST 가 붙지는 않았지만요 ^^;

그리고 수 많은 곳에서 쓰이고 있는 "CGI 방식" 이라는 표현은 이 스펙에 따르면 모두 틀린 표현이 되겠습니다. CGI 방식 이라고 했을 때, 저 스펙대로의 CGI 를 생각하는 사람은 아마 거의 없을 것입니다. 아니면 제가 지금까지 거의 없을 것이라고 믿어 왔던 것이거나요. "CGI 방식에 비해 모듈 방식은 훨씬 성능이 좋다" 라는 식의 표현을 대체 몇 번이나 봤는 지 기억도 못하겠습니다. 대부분 다른 프로세스 뛰우고 환경 변수, 표준 입력, 표준 출력을 통해 데이터 교환이라고 생각할 것도 같구요.

제 두뇌속에 CGI 를 다시 입력시켜야 겠습니다. 이 스펙대로라면 CGI 는 서버와 스크립트 간의 인터페이스이고 주어진 meta-variable 의 형식과 클라이언트가 자료를 요청하는 방식 등만 스펙을 지키면 되는 거군요. 단 쿼리를 받고 결과를 돌려 줄 방법만 잘 정의해 놓으면 되는 거구요. 이런 측면에서는 아파치 모듈 자체로 웹 애플리케이션을 만들어도 CGI 를 준수 할 수 있는 거 같습니다.

앞으로 CGI 방식을 언급할 때는 "과거에 CGI 를 구현했었던 방법" 이라고 해야 겠습니다. 그리고 아파치 웹 서버에 동적 혹은 정적으로 로드 혹은 로더 되어 있는 php 는 CGI를 구현 또는 준수하고 있다는 게 맞겠군요.

괜히 뒷북을 둥둥울렸지만 잘 알고 갑니다 ^^

... 라고 쓰고 쓰레드를 훑어 보니 제가 이미 논쟁을 했던 부분이네요 ;; 그리고 막상 제가 썼던 글을 다시 읽어보니, 아파치 서버 내에서 모듈로 웹 애플리케이션을 만들었을 때, 서버쪽에서 넘겨 받는 변수의 이름들이 CGI 스펙과 일치해야 CGI 를 준수 한다고 볼 수 있을 것 같은데 대부분의 경우 그렇게 넘겨 받을 리는 없으므로 CGI 를 준수 하지는 않겠고, mod_php 의 경우는 아파치가 mod_php 의 코드를 이용해서 로드된 php 스크립트에 CGI 형식의 변수 이름으로 데이터를 넘겨 준다면, CGI 를 준수하는 것이겠구요.

정의상 server 를 아파치+mod_php(server 는 서비스 요청을 받아 스크립트를 invoke 하는 프로그램이므로..) 로 보고 각 php 파일을 스크립트로 본다면 스크립트 내에서 cgi 규약의 meta-variable 을 볼 수 있으니, CGI 규약을 지키는 것이군요. fastcgi 의 경우도 웹서버(모듈 포함)의 요청을 cgi 규약 상의 meta-variable 형식으로 유닉스 도메인 소켓(scgi 경우)으로 넘겨주니 cgi 규약을 준수한다고 볼 수 있는 것이고, 머 그런 거군요.

스펙 상에서 스크립트는 서버상의 서브루틴 일 수도 있다고 했는데, 생각할 수록 스펙이 애매합니다. 서버상의 서브루틴이 스크립트라면 이 스크립트를 invoke 할 때 meta-variable 을 정해진 이름으로 넘겨야 되는데, 이 변수 이름은 아마도 소스코드 상에서의 변수이름이 되면 되는것인지도 궁금하네요. 아마도 그런 의미에서 썼을 거라 생각하지 만요. 그 전에 서버가 그 자신안에 있는 서브루틴을 invoke 한다는 표현이 과연 가능한 것인지도 궁금하구요.

결론적으로 CGI 규약을 준수하는 웹서버를 만들려면 현재의 방식으로 만들거나, 저 메타변수를 넘기는 방법과 결과를 받는 방법을 명확하게 정의 해놓으면 되겠네요.쓰레드 만들어진지 근 3개월 만에 조금 명확하게 인식한 것 같습니다. 아마 저 위에 글 쓸 때는 같은 주소 영역 내에서 데이터를 주고 받는데 무슨 놈의 인터페이스가 필요한 가라고 생각했을지도 모르겠네요. 사실 저만 몰라서 헤메었던 거 같기도 하고, 이렇게 구구절절 정의할 필요가 없어 보이지만서도 그냥 생각한 김에 올려 봅니다. ^^

그리고 애초의 질문에 대한 답은,
1. 프로그래밍 언어 PHP 는 당연히 CGI 와 같은 비교 범주가 아니다.
2. 웹서버가 실행시키는 실행파일 형식으로 된 php가 스크립트 파일을 읽어 들여서 사용하는 경우 CGI 를 준수한다. 웹서버인 아파치가 php 를 호출하고, php 프로그램이 'script'를 invoke 하고 이 때 스펙에서 주어진 조건을 충족하므로 cgi 규약을 지킨다. 이때 'server' 는 아파치 + php 라고 볼 수 있다.
3. 웹서버 모듈로 들어가 있는 경우 웹서버가 자신의 내부에 있는 실행코드를 이용해서 'script'를 invoke 하고 이 때 스크립트 파일 상에서 스펙에 주어진 것들을 볼 수 있으므로 CGI 규약을 지킨다. 'server' 는 apache with mod_php, 'script' 는 각 php 스크립트들, 'meta-variable'은 php 변수들(스펙대로라면 굳이 환경변수 일 이유가 없다.) 'sever' 와 'script' 가 데이터를 주고 받는 방식은 'server' 가 직접 'script'를 읽어들여서 직접 통신한다.
입니다.

...... 누가 보면 미친 줄 알겠습니다 ㅜㅜ

죠커의 이미지

저도 일부 내용은 잘못 기록하였군요. 소타님의 글이 맞습니다.

- CN의 낙서장 / HanIRC:#CN

manea의 이미지

질문을 위한 답이 아니라 답을 위한 답이네요 .. 위에 질문하신분 아마 벌써부터 이해하고 계실것 같네요 . 이런저런 말들때문에 더 쉽게 이해가는거 같습니다. ㅎㅎ

열정!! ^^

열정!! ^^

Darkcircle의 이미지

CGI 개념교육할때 참고할만한 "백과사전"급 컨텐츠네요... :)

----------------------------------------------------------------
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ

---------------------------------------------------------------
폐인이 되자 (/ㅂ/)

irondog의 이미지

결론은 이거 아닌가요?

"CGI는 프로토콜이고 PHP는 스크립트 언어이다."

사족을 달자면,
- CGI는 외부 프로그램을 띄워서 그 결과값을 반환하는 방식에 대한 규약이며, 이 때 쓰이는 외부 프로그램을 통상 CGI프로그램이라 한다.
- PHP는 CGI프로그램으로 쓰일 수 있다.

익명사용자의 이미지

tcpwrapper 를 쓰던 시절,
80 포트로 접속하는 클라이언트에

kiss my ass

라는 html 을 뿌려주는 bash 스크립트를 사용했던 적이 있습니다.
물론 헤더도 표준을 지켰습니다.
1. bash 가 웹서버인가요 ?

bash 스크립트를 이용한 CGI 도 가능합니다.
2. bash 가 CGI 인가요 ?

다른 방식으로 물어보지요.
3. bash 를 웹서버로 사용할 수 있나요 ?
4. bash 를 CGI 에 사용할 수 있나요 ?

"CGI" 는 interface 를 정의할 뿐입니다.
"CGI 프로그램" 또는 "CGI 어플리케이션" 이라고 지칭되는 것들은 CGI 에 맞춰 개발된 것들입니다.
C 로 만들어 컴파일 된 "실행파일"
PHP 에 의해 인터프리트 될 "스크립트".

아직도 "C 컴파일러"나 "PHP 인터프리터"가 CGI 라고 생각하시는 분이 계시면 gg

소타의 이미지

bash로 웹서버....
만들수 있을것 같다는 생각이 드네요 ㅋㅋㅋ
bash로도 소켓을 열고 입출력을 할 수 있으니까요 ㅋㅋ

koeikim의 이미지

예전에 dietlibc로 검색을 하다가
간단한 httpd 구현을 찾아보다보니 inetd위에서의 구현이겠지만
awk로 된 httpd,
bash로 된 httpd 등등 잼있는 것들이 꽤 되더군요 :)