How the CGI and FastCGI protocols work

Directory

• Introduced
• Deep CGI Protocol
  • How the CGI works
  • The flaw of CGI protocol
• Deep FASTCGI Protocol
  • FASTCGI protocol Operating principle
  • Why FastCGI, not CGI protocol?
  • CGI and FastCGI Architecture
  • Look at the FastCGI protocol again.
  • Web Server and FastCGI interaction process
  • Why do I need to send RequestID this logo in the message hair?
• php-fpm

Introduced

In the process of developing PHP, we often use nginx or Apache as our web server. But how does PHP communicate with these Web servers?

• Apache integrates PHP as a module into the Apache process (httpd) to run, and this mod_php operation mode has nothing to do with php-cgi.

• Nginx is through FastCGI to the implementation of communication with PHP.

To talk about fastcgi, we must first talk about CGI. So what is CGI?

CGI ( Common Gateway Interface:通用网关接口 ) is the specification of a Web server runtime external program, and programs written by CGI can extend server functionality. CGI applications can interact with the browser, and data can be obtained from the database server by communicating with external data sources such as database servers through the database API. --Baidu Encyclopedia

CGI协议Like the HTTP protocol, it is an "application-layer" protocol that is designed to address communication issues between Web servers and PHP applications (or other Web applications).

Since it is a "protocol", in other words, it is not language-related, that is, as long as the implementation of the class CGI protocol application can achieve mutual communication.

Deep CGI Protocol

We already know that the CGI protocol is designed to accomplish the problem of data communication between Web servers and applications. So, let's take a look at how they communicate with each other in this section.

Simply speaking the CGI protocol it describes the format of data transfer between WEB servers and applications, and you can use it to write a CGI program as long as our programming language supports processing of standard input (STDIN), standard output (STDOUT), and environment variables.

How the CGI works

• When a user accesses our Web app, an HTTP request is initiated. The final WEB server receives this request.

• The WEB server creates a new CGI process. In this process, the HTTP request data is parsed in a certain format and passed through standard input and environment variables to the CGI program specified by the URL (PHP application $_server).

• When the Web application finishes processing the returned data into standard output, the Web server process reads the response from the standard output stream and returns the response to the user using the HTTP protocol.

The bottom line is that the CGI process in the Web server reads the received HTTP request data into the environment variable, and forwards it to the PHP CGI program via standard input, and when the PHP program finishes processing, the CGI process in the Web server reads the returned data from the standard output and converts it back to the HTTP Responds to the message format and eventually presents the page to the user. The WEB server then shuts down the CGI process.

It can be said that the CGI protocol is particularly adept at handling communication problems with Web servers and Web applications. However, it has a serious flaw, and for each request it is necessary to fork out a CGI process and close immediately after processing is complete.

The flaw of CGI protocol

• Each time a user request is processed, the CGI subprocess needs to be re-forked and the CGI subprocess destroyed.

• A series of I/O overhead reduces the throughput of the network, resulting in a waste of resources that can cause serious performance problems in large concurrency.

Deep FASTCGI Protocol

Functionally, the CGI protocol has been fully able to solve the problem of data communication between Web servers and Web applications. But since each request needs to be re-fork out of the CGI sub-process resulting in poor performance, the protocol-based CGI improvement is a FastCGI protocol that is a resident CGI protocol.

Essentially, the FastCGI and CGI protocols are almost identical, and they all receive the same data from the WEB server, except that they take different forms of communication.

Just to recap. Each time the CGI protocol receives an HTTP request, it needs to go through a series of tasks such as fork out the CGI subprocess, perform processing, and destroy the CGI sub-process.

While the FastCGI protocol uses interprocess communication (IPC) to process user requests, let's look at how it works.

FASTCGI protocol Operating principle

• The FastCGI process Manager starts by creating a primary (master) process and multiple CGI interpreter processes (Worker processes), and then waits for the WEB server to connect.

• After the WEB server receives the HTTP request, it communicates the CGI message through the socket (UNIX or TCP socket), writes the environment variable and the request data to the standard input, and forwards it to the CGI interpreter process.

• The CGI interpreter process returns standard output and error information from the same connection to the WEB server after it finishes processing.

• The CGI interpreter process waits for the next HTTP request to arrive.

Why FastCGI, not CGI protocol?

It doesn't seem like a big deal if only because of the different working patterns. Did not have to choose FastCGI Agreement is not the point.

However, for this seemingly small difference, but the meaning is extraordinary, the end result is the implementation of the WEB application architecture differences.

CGI and FastCGI Architecture

In the CGI protocol, the life cycle of a WEB application depends entirely on the declaration period of the HTTP request.

For each HTTP request that is received, a CGI process needs to be restarted for processing, and the CGI process must be closed after processing to achieve the purpose of notifying the WEB server that the HTTP request processing is complete.

But it's completely different in FastCGI.

The FastCGI process is resident and can handle all HTTP requests once it is started without having to exit directly.

Look at the FastCGI protocol again.

Through the previous explanation, we can say it very accurately compared to the FastCGI is a communication protocol such a conclusion. Now, let's move the focus to the protocol itself to see the definition of the agreement.

Like the HTTP protocol, the FastCGI protocol also has a message header and message body composition.

Message header information

The main message header information is as follows:

• Version : used to represent the FastCGI protocol revision number.

• Type : used to identify the types of FastCGI messages-used to specify the method for handling this message.

• RequestID: identifies the FastCGI request that currently belongs to.

• Content Length: The number of bytes that the packet body occupies.

Message type definition

• begin_request: sent from the Web server to the Web app, indicating that a new request has been processed.

• abort_request: sent from the Web server to the Web app, which represents aborting a request in a process. For example, this message is triggered when the user presses the Stop button on the browser after the browser initiates the request.

• end_request: sent from the Web app to the Web server, indicating that the request processing is complete. The return packet contains "returned code", which determines whether the request was processed successfully.

• PARAMS: "Stream Packet", sent from the Web server to the Web App. You can send multiple packets at this time. The send end identifies an empty package with a length of 0 from the Web server. And the data type in the PARAMS is consistent with the CGI protocol. That is, we use $_server to obtain the system environment and so on.

• STDIN: Stream packet, used by the Web app to read out the POST data submitted by the user from the standard input.

• STDOUT: Stream datagram, written from a WEB application to standard output, contains data that is returned to the user.

Web Server and FastCGI interaction process

• The Web server receives the user request, but the final processing request is done by the Web App. At this point, the Web server attempts to connect to the FastCGI process through sockets (UNIX or TCP sockets, whichever is determined by the WEB server configuration).

• The FastCGI process views the received connection. Select the receive or reject connection. If it is a receive connection, the packet is read from the standard input stream.

• If the FastCGI process does not receive a connection successfully within a specified time, the request fails. Otherwise, the WEB server sends a BEGIN_REQUEST type message that contains a unique RequestID to the FastCGI process. All subsequent packets are sent with this requestid. The WEB server then sends any number of PARAMS type messages to the FastCGI process. Once sent, the WEB server sends an empty params message packet and then closes the stream. Also, if a user sends a POST data Web server writes it to standard input (STDIN) to the FastCGI process. When all post data is sent, an empty standard input (STDIN) is sent to close the stream.

• At the same time, the FastCGI process receives the BeginRequest type packet. It can reject this request by responding to ENDREQUEST. or receive and process the request. If the request is received, the FastCGI process waits for all PARAMS and standard input packets to be received. Then, the request is processed and the returned result is written to the standard output (STDOUT) stream. After processing is complete, an empty packet is sent to the standard output to close the stream, and a end_request type message is sent to inform the WEB server whether it has an error exception.

Why do I need to send RequestID this logo in the message hair?

If each connection processes only one request, sending the RequestID is slightly redundant.

But the connection between our Web server and the FastCGI process can handle multiple requests, that is, one connection can handle multiple requests. That's why you need to adopt a packet protocol instead of using a single data stream directly: for "multiplexing."

Therefore, because each packet contains a unique RequestID, the WEB server can send any number of requests on one connection, and the FastCGI process can receive any number of request packets from one connection.

In addition, we need to make it clear that the communication between the WEB server and the FastCGI process is unordered. Even though we seem to be ordering a request in the process of interaction, it is possible for our WEB server to emit dozens of begin_request types of packets at the same time, and so on.

php-fpm

PHP-FPM is php-fastcgi Process Manager.

PHP-FPM is the implementation of FASTCGI and provides the function of process management.

The process contains both the master process and worker process processes.

The master process has only one, which is responsible for listening to the port, receiving requests from the Web Server, while the worker process is typically multiple (the exact number is configured according to actual needs), and each process embeds a PHP interpreter inside, which is where the PHP code really executes.

PHP-FPM is the FastCGI process Manager (PHP FastCGI processes manager) (http://php.net/manual/zh/install.fpm.php) for replacing the PHP kernel FastCGI Most of the additional functionality (or an alternative PHP FastCGI implementation) is very useful for high-payload sites.

How does the php-fpm work?

The PHP-FPM process Manager consists of two processes, a Master process and multiple Worker processes. The Master process is responsible for listening to the port, receiving requests from the WEB server, and then assigning a specific worker process to process the request, while the worker process typically has multiple (depending on the configuration determines the number of processes), and within each process a PHP interpreter is embedded to execute the PHP code.

How Nginx server works in collaboration with FastCGI

The Nginx server cannot communicate directly with the FastCGI server and needs to enable the Ngx_http_fastcgi_module module for proxy configuration in order to send the request to the FastCGI service.

Reproduced:

How does PHP and Apache communicate?

NGINX+PHP-FPM Operation Principle Detailed

Master the operation principle of CGI and FASTCGI protocol

How the CGI and FastCGI protocols work