Several operating modes of php CLI, CGI, FastCGI, mod_php, fastcgimod_php

1. CLI: It is the command line. For example, you can type commands in the console or shell:

php -f index.php

Copy after login

Then get the output

2. CGI: The following are different explanations and understandings

"Common Gateway Interface" (Common Gateway Interface), a tool for the HTTP server to "talk" with programs on your or other machines. The program must run on the network server. In the server environment, it is the "program" "Provides a standard interface. Through this interface, the "program" can do something with the information exchanged between the server and the client. There is no requirement for the language of the "program". The program operates the interface. To support CGI, the server must provide CGI environment variables required in

The protocol between HTTP Server and an independent process sets the header of the HTTP Request to the environment variable of the process, the body of the HTTP Request to the standard input of the process, and the standard output of the process is the HTTP Response including the header and body. .

This web server uses the UNIX shell environment variable to save the parameters passed from the web server, and then generates a independent process that runs CGI.

As long as programs written in different types of languages comply with CGI standards, they can interact with the web server as a CGI program

When running in CGI mode, the web server transfers user requests to the PHP independent process in the form of messages. There is no affiliation between PHP and the web service.

Personal understanding: CGI stipulates the rules for communication between php and web server, which is equivalent to executing response = exec("php -f index.php -url=xxx -cookie=xxx -xxx=xxx").

About the difference between CGI and CLI, you can check the official document which is pretty good: http://php.net/manual/zh/features.commandline.php

The article explains the significant differences between CGI and CLI:

The following are the significant differences between CLI SAPI and other CLI SAPI modules:

is different from CGI SAPI in that its output does not have any header information.

Although CGI SAPI provides a method to cancel HTTP header information, there is no similar method in CLI SAPI to enable the output of HTTP header information.
The
CLI starts in quiet mode by default, but to ensure compatibility, the -q and --no-header parameters are still retained for backward compatibility, allowing the use of old CGI scripts.

When running, the working directory will not be changed to the current directory of the script (you can use the -C and --no-chdir parameters to be compatible with CGI mode).

Output plain text error message (not HTML format) when an error occurs.

3. FastCGI: CGI has many shortcomings. Every time a request is received, a process must be forked for processing, and it can only receive one request and make one response. The process ends when the request ends. FastCGI will be started in advance and exist as a cgi management server. It will start a series of sub-processes in advance to wait for processing, and then wait for the request from the web server. Once the request is received, it will be handed over to the sub-process for processing, so there is no need to It will be much faster to start cgi after receiving the request. FastCGI uses a process/thread pool to handle a series of requests. These processes/threads are managed by the FastCGI server, not the web server. When a request comes in, the Web server passes the environment variables and the page request to the FastCGI process through a Socket long connection. FastCGI is like a resident CGI that can be executed all the time and does not take time to fork a process when a request arrives (this is the fork-and-execute mode that CGI critics criticize). Precisely because it is just a communication protocol, it also supports distributed computing, that is, FastCGI programs can be executed on hosts other than the website server and accept requests from other website servers

FastCGI entire process :

Load the FastCGI process manager when the Web server starts
FastCGI initializes itself, starts multiple CGI interpreter processes (visible multiple php-cgi) and waits for requests from the Web server
When requesting the Web server, the Web server requests the FastCGI process manager through the socket. The FastCGI process manager selects and connects to a CGI interpreter. The Web server sends the CGI environment variables and standard input to the FastCGI sub-process php-cgi
After the FastCGI sub-process processes the request, it returns the standard output and error to the Web server from the same connection. When the FastCGI sub-process ends, the request ends. The FastCGI child process then waits to handle the next connection from the FastCGI process manager, at which point php-cgi exits in CGI mode.

php-fpm: FastCGI process manager for PHP

4. mod_php: The php module of apache, which controls PHP as a sub-process of the web-server. There is a subordinate relationship between the two. The most obvious example is that in CGI mode, if the PHP.INI is modified The configuration file can take effect without restarting the web service, but in module mode, you need to restart the web service. Running PHP in mod_php mode means that php is started as a module of apache. Therefore, the php.ini configuration file will be read and the extension module will be loaded only when apache starts. It will not be read while apache is running. and

for loading extension modules

The working mode of Apache The working principle of prefork

A separate control process (parent process) is responsible for spawning child processes, which are used to listen for requests and respond. Apache always tries to keep some spare or idle child processes for upcoming requests. In this way, the client does not need to wait for the child process to be generated before getting the service. In Unix systems, the parent process usually runs as root to bind port 80, while the child process generated by Apache usually runs as a low-privileged user. The User and Group directives are used to configure a low-privileged user for the child process. The user running the child process must have read permissions on the content he is serving, but must have as few permissions as possible on other resources outside the service content.

How worker works

The number of threads each process can have is fixed. The server will increase or decrease the number of processes based on load. A separate control process (parent process) is responsible for the establishment of child processes. Each child process can establish a ThreadsPerChild number of service threads and a listening thread, which listens for access requests and passes them to the service thread for processing and response. Apache always tries to maintain a spare or idle pool of service threads. In this way, the client does not need to wait for a new thread or process to be established before it can be processed. In Unix, in order to be able to bind port 80, the parent process is usually started as root. Subsequently, Apache creates child processes and threads as a user with lower privileges. The User and Group directives are used to configure the permissions of the Apache child process. Although the child process must have read access to the content it provides, it should be given as few privileges as possible. In addition, unless suexec is used, the permissions configured by these instructions will be inherited by the CGI script

Personal understanding: This mode embeds php into apache, which is equivalent to adding the function of parsing php files to apache.