다섯 가지 주요 PHP 작동 모드-PHP 튜토리얼-php.cn

PHP의 다섯 가지 일반적인 작동 모드는 CGI(공통 게이트웨이 인터페이스), FastCGI(상주 CGI/Long-Live CGI), CLI(명령줄) 인터페이스), 웹 모듈 모드(모드)입니다. Apache와 같은 웹 서버가 실행되는 곳), ISAPI(인터넷 서버 응용 프로그램 인터페이스)에 대해 이 기사가 모든 사람에게 도움이 되기를 바랍니다.

참고: PHP5.3 이후에는 PHP에 더 이상 ISAPI 모드가 없으며 설치 후 php5isapi.dll 파일이 없습니다. IIS6에서 더 높은 버전의 PHP를 사용하려면 FastCGI 확장을 설치한 다음 IIS6에서 FastCGI를 지원하도록 설정해야 합니다.

1.1, CGI 모드

CGI는 Common Gateway Interface(공통 게이트웨이 인터페이스)를 뜻하는 말로 웹에서 웹페이지와 실행 프로그램을 연결해주는 프로그램입니다. server. 에서는 HTML에서 받은 명령을 서버의 실행 프로그램에 전달한 다음 서버의 실행 프로그램의 결과를 HTML 페이지에 반환합니다. CGI는 뛰어난 크로스 플랫폼 성능을 제공하며 거의 모든 운영 체제에서 구현될 수 있습니다. CGI는 이미 오래된 모델이며 최근에는 거의 사용되지 않았습니다.

사용자 요청이 있을 때마다 먼저 CGI 하위 프로세스가 생성된 후 요청이 처리되고 하위 프로세스가 처리 후 종료됩니다. 사용자 요청 수가 매우 많으면 메모리, CPU 시간 등 시스템 리소스를 많이 차지하게 되어 성능이 저하됩니다. 따라서 CGI를 사용하는 서버는 연결 요청만큼 많은 CGI 하위 프로세스를 가지게 됩니다. 하위 프로세스의 반복적인 로드는 CGI 성능이 저하되는 주요 원인입니다.

PHP를 서버측 소프트웨어(예: Apache)에 내장하고 모듈로 설치하고 싶지 않은 경우 CGI 모드로 설치하도록 선택할 수 있습니다. 또는 다양한 CGI 래퍼와 함께 PHP를 사용하여 코드에 대한 보안 chroot 및 setuid 환경을 만듭니다. 이렇게 각 클라이언트가 PHP 파일을 요청하면 웹 서버는 php.exe(win에서는 php.exe, Linux에서는 php)를 호출하여 파일을 해석한 후, 해석 결과를 다음과 같은 형태로 클라이언트에게 반환합니다. 웹페이지. 이 설치 방법은 일반적으로 웹 서버의 cgi-bin 디렉터리에 PHP 실행 파일을 설치합니다. CERT 권장 사항 CA-96.11에서는 cgi-bin 디렉터리에 인터프리터를 배치하지 않을 것을 권장합니다. 이 방법의 장점은 명확한 구조와 강력한 제어성을 통해 웹 서버를 특정 프로그램 처리와 분리하는 동시에 단점은 액세스 수요가 높을 경우 CGI 프로세스 포크가 거대한 서버가 된다는 것입니다. 수백 개의 동시 요청으로 인해 서버가 수백 개의 프로세스를 분기한다고 상상해 보십시오. 이것이 바로 CGI가 항상 낮은 성능과 높은 리소스 소비로 악명이 높았던 이유입니다.

1.2, FastCGI 모드

FastCGI는 CGI의 업그레이드 버전입니다. 활성화된 한 항상 실행될 수 있습니다. 한 번 포크하는 데 시간이 걸립니다(이것은 CGI에서 가장 비판받는 포크 및 실행 모드입니다).

FastCGI는 HTTP 서버와 동적 스크립팅 언어 간의 통신을 위한 확장 가능한 고속 인터페이스입니다. 가장 널리 사용되는 HTTP 서버는 Apache, Nginx 및 lighttpd를 포함한 FastCGI를 지원하는 동시에 PHP를 포함한 많은 스크립팅 언어에서도 지원됩니다.

FastCGI 인터페이스 모드는 HTTP 서버와 스크립트 구문 분석 서버를 분리하고 스크립트 구문 분석 서버에서 하나 이상의 스크립트 구문 분석 데몬을 시작할 수 있는 C/S 구조를 채택합니다. HTTP 서버가 동적 프로그램을 만날 때마다 실행을 위해 FastCGI 프로세스로 직접 전달된 다음 결과가 브라우저로 반환됩니다. 이 방법을 사용하면 HTTP 서버가 정적 요청을 독점적으로 처리하거나 동적 스크립트 서버의 결과를 클라이언트에 반환할 수 있으므로 전체 응용 프로그램 시스템의 성능이 크게 향상됩니다.

[원리]

1) FastCGI 프로세스 관리자(IIS ISAPI 또는 Apache 모듈)는 웹 서버가 시작될 때 로드됩니다.

2) FastCGI 프로세스 관리자는 자체적으로 초기화되고 여러 CGI 인터프리터 프로세스를 시작합니다(여러 PHP-볼 수 있음). ) cgi.exe 또는 php-cig) 웹 서버로부터의 연결을 기다립니다.

3) 클라이언트 요청이 웹 서버에 도달하면 FastCGI 프로세스 관리자가 CGI 인터프리터를 선택하고 연결합니다. 웹 서버는 CGI 환경 변수와 표준 입력을 FastCGI 하위 프로세스 php-cgi로 보냅니다.

4) FastCGI 하위 프로세스가 처리를 완료한 후 동일한 연결에서 표준 출력 및 오류 정보를 웹 서버로 반환합니다. . FastCGI 하위 프로세스가 연결을 닫으면 요청이 처리됩니다. 그런 다음 FastCGI 하위 프로세스는 FastCGI 프로세스 관리자(WebServer에서 실행)의 다음 연결을 기다리고 처리합니다. 일반 CGI 모드에서는 php-cgi.exe가 여기서 종료됩니다.

CGI 모드에서는 일반적으로 CGI가 얼마나 느린지 상상할 수 있습니다. PHP에 대한 모든 웹 요청은 php.ini를 다시 구문 분석하고, 모든 dll 확장을 다시 로드하고, 모든 데이터 구조를 다시 초기화해야 합니다. FastCGI를 사용하면 이 모든 작업이 프로세스가 시작될 때 한 번만 발생합니다. 추가 보너스는 지속적인 데이터베이스 연결이 작동한다는 것입니다.

참고: PHP의 FastCGI 프로세스 관리자는 PHP-FPM(PHP-FastCGI 프로세스 관리자)입니다.

[장점]

1) 안정성 측면에서 FastCGI는 프로세스가 종료되면 독립적인 프로세스 풀에서 CGI를 실행합니다. 시스템은 이를 쉽게 폐기하고 새로운 프로세스를 재할당하여 로직을 실행할 수 있습니다.

2) 보안 관점에서 FastCGI는 분산 컴퓨팅을 지원합니다. FastCGI는 호스트 서버와 완전히 독립적입니다. FastCGI가 어떻게 다운되더라도 서버는 다운되지 않습니다.

3) 성능 측면에서 FastCGI는 동적 로직 처리를 서버와 분리합니다. IO 처리는 여전히 호스트 서버에 남아 있으므로 호스트 서버는 IO에 집중할 수 있습니다. 일반적인 동적 웹 페이지의 경우 논리적 처리의 일부만 있을 수 있고 많은 수의 정적 이미지 등이 있을 수 있습니다. .

【단점】

장점을 이야기한 후 단점을 이야기해보겠습니다. 실제 사용해본 결과 FastCGI 모드는 프로덕션 환경의 서버에 더 적합합니다. 그러나 개발 기계에는 적합하지 않습니다. Zend Studio를 사용하여 프로그램을 디버깅할 때 FastCGI는 PHP 프로세스가 시간 초과되었다고 생각하고 페이지에 500 오류를 반환하기 때문입니다. 이것이 너무 짜증나서 개발 컴퓨터에서 ISAPI 모드로 다시 전환했습니다. 일부 서버의 새 버전에 대한 지원은 좋지 않으며 분산 로드 밸런싱이 필요하지 않은 모듈식 설치가 더 나은 선택입니다. FastCGI와 서버 간의 현재 통신은 충분히 스마트하지 않습니다. FastCGI 프로세스를 실행하는 데 시간이 너무 오래 걸리면 해당 프로세스가 종료되고 죽은 프로세스로 다시 시작됩니다. 이는 또한 장기 작업을 처리할 때 매우 문제가 됩니다. 온라인 디버깅을 허용합니다. 다중 프로세스이기 때문에 CGI 다중 스레딩보다 더 많은 서버 메모리를 사용합니다. PHP-CGI 인터프리터는 프로세스당 7~25MB의 메모리를 사용합니다. 이 숫자에 50 또는 100을 곱하면 많은 양의 메모리가 됩니다.

1.3 CLI 모드

PHP-CLI는 PHP Command Line Interface의 약자로 이름 그대로 PHP가 명령줄에서 실행되는 인터페이스로, PHP 환경에서 실행되는 것과는 다릅니다. 웹 서버(PHP-CGI, ISAPI 등). 즉, PHP는 프런트엔드 웹 페이지를 작성할 수 있을 뿐만 아니라 백엔드 프로그램을 작성하는 데에도 사용할 수 있습니다. PHP CLI 쉘 스크립팅은 모든 PHP 장점에 적용되어 서버 측 스크립트나 시스템 또는 GUI 애플리케이션 생성을 가능하게 하며 Windows 및 Linux에서 지원됩니다.

[장점]

1) 여러 프로세스를 사용하면 자식 프로세스가 종료된 후 커널이 리소스 재활용을 담당합니다.

2) 여러 프로세스를 사용하면 자식 프로세스가 비정상적으로 종료되어도 전체 프로세스 스레드가 발생하지 않습니다. 종료하면 상위 프로세스는 프로세스를 다시 빌드할 수 있는 기회를 갖게 됩니다. 상주 메인 프로세스는 작업 분배만 담당하며 논리는 더 명확합니다;

3) Linux에서는 예약된 작업을 구현할 수 있으며 PHP를 사용하여 쉘 스크립트를 작성할 수 있습니다.

우리는 PHP가 어떤 확장 프로그램을 설치했는지 알아보기 위해 Linux에서 "php -m"을 자주 사용합니다. 이는 PHP 명령줄 실행 모드입니다. 관심 있는 학생들은 "php -h"를 입력하여 실행 모드를 자세히 알아볼 수 있습니다.

1.4 모듈 모드

모듈 모드는 mod_php5 모듈 형태로 통합되어 있습니다. 이때 mod_php5 모듈의 기능은 Apache가 전달한 PHP 파일 요청을 받아 처리한 후 반환하는 것입니다. 결과를 Apache로 처리했습니다. Apache가 시작되기 전에 구성 파일에 PHP 모듈

(mod_php5)을 구성하면 PHP 모듈은 apache2의 ap_hook_post_config 후크를 등록하고 Apache가 PHP 파일에 대한 요청을 수락하기 시작할 때 이 모듈을 시작합니다.

시작 시 이러한 로딩 방법 외에도 Apache 모듈은 런타임 시 동적으로 로드될 수 있습니다. 이는 소스 코드를 다시 컴파일하거나 서버를 전혀 중지하지 않고도 서버가 기능적으로 확장될 수 있음을 의미합니다. 우리가 해야 할 일은 HUP 또는 AP_SIG_GRACEFUL 신호를 서버에 보내 서버에 모듈을 다시 로드하라고 알리는 것뿐입니다. 그러나 동적 로딩 전에 모듈을 동적 링크 라이브러리로 컴파일해야 합니다. 이때 동적 로딩은 동적링크 라이브러리를 로딩하는 것입니다. Apache에서 동적 링크 라이브러리의 처리는 mod_so 모듈을 통해 완료되므로 mod_so 모듈은 동적으로 로드될 수 없으며 Apache의 핵심으로 정적으로 컴파일될 수만 있습니다. 이는 Apache와 함께 시작된다는 의미입니다.

Apache는 모듈을 어떻게 로드하나요? 앞서 언급한 mod_php5 모듈을 예로 들어보겠습니다. 먼저 Apache의 구성 파일 httpd.conf에 다음 줄을 추가해야 합니다.

LoadModule php5_module module/mod_php5.so

여기서는 LoadModule 명령을 사용합니다. 명령의 첫 번째 매개변수는 모듈의 이름입니다. 소스 코드에 있는 모듈에서 구현됩니다. 두 번째 옵션은 모듈이 있는 경로입니다. 서버가 실행되는 동안 모듈을 로드해야 하는 경우 HUP 또는 AP_SIG_GRACEFUL 신호를 서버에 보낼 수 있습니다. 신호가 수신되면 Apache는 서버를 다시 시작하지 않고 모듈을 다시 로드합니다.

이 동작 모드는 우리가 Windows 환경에서 Apache 서버를 사용할 때 자주 사용하는 모드입니다. 모듈화(DLL)에서는 웹 서버와 함께 PHP가 시작되어 실행됩니다. (PHP의 운영 효율성을 높이기 위해 CGI 기반의 Apache를 확장한 것입니다.)

1.5 ISAPI 모드

ISAPI(Internet Server Application Program Interface)는 Microsoft에서 제공하는 인터넷 서비스용 API 인터페이스 집합입니다. ISAPI DLL은 사용자 요청에 의해 활성화된 후 메모리에 상주할 수 있습니다. user 다른 요청의 경우 하나의 DLL에 여러 사용자 요청 처리 기능을 설정할 수도 있습니다. 또한 ISAPI DLL 응용 프로그램과 WWW 서버는 동일한 프로세스에 있으며 효율성은 CGI보다 훨씬 높습니다. (Microsoft의 독점권으로 인해 Windows 환경에서만 실행될 수 있습니다.)

Apache 모듈로서 PHP는 시스템이 시작된 후 메모리에 상주할 여러 프로세스 복사본을 미리 생성합니다. 즉시 사용됩니다. 자식 프로세스가 처리에 사용되므로 자식 프로세스 생성으로 인한 지연이 없습니다. 이러한 서버 복사본은 HTTP 요청을 처리한 후 즉시 종료되지 않고 다음 요청을 기다리는 동안 컴퓨터에 남아 있습니다. 클라이언트 브라우저 요청에 대한 응답이 더 빠르고 성능도 더 높습니다.