The underlying working principle of PHP_PHP tutorial

Introduction
Let’s take a look at the process below:
We have never manually started the PHP related process, it runs when Apache starts;
PHP is connected to Apache through the mod_php5.so module (specifically SAPI, the server application programming interface);
PHP has a total of three modules: kernel, Zend engine, and extension layer;
The PHP kernel is used to handle requests, file streams, error handling and other related operations;
Zend Engine (ZE) is used to convert source files into machine language and then run it on a virtual machine;
The extension layer is a set of functions, libraries, and streams that PHP uses to perform specific operations. For example, we need the mysql extension to connect to the MySQL database;
When ZE executes a program, it may need to connect to several extensions. At this time, ZE hands over control to the extensions and returns it after completing the specific tasks;
Finally, ZE returns the program execution results to the PHP kernel, which then transmits the results to the SAPI layer and finally outputs them to the browser.
Explore in depth
Wait, it’s not that simple. The above process is just a simplified version, let’s dig a little deeper to see what else is going on behind the scenes.
After Apache starts, the PHP interpreter also starts;
The startup process of PHP has two steps;
The first step is to initialize some environment variables, which will affect the entire SAPI life cycle;
The second step is to generate some variable settings that are only specific to the current request.
The first step to start PHP
Not sure what the first and second steps are? Don’t worry, we’ll discuss this in detail next. Let's look at the first and most important step first. The thing to remember is that the first step of the operation happens before any requests arrive.
After starting Apache, the PHP interpreter will also start;
PHP calls the MINIT method of each extension to switch these extensions to an available state. Take a look at what extensions are opened in the php.ini file;
MINIT means "module initialization". Each module defines a set of functions, class libraries, etc. to handle other requests.
A typical MINIT method is as follows:
PHP_MINIT_FUNCTION(extension_name){
/* Initialize functions, classes etc */
}
The second step of PHP startup
When a page request occurs, the SAPI layer hands over control to the PHP layer. So PHP sets the environment variables needed to reply to this request. At the same time, it also creates a variable table to store variable names and values ​​generated during execution.
PHP calls the RINIT method of each module, which is "request initialization". A classic example is the RINIT of the Session module. If the Session module is enabled in php.ini, the $_SESSION variable will be initialized and the relevant content will be read in when the RINIT of the module is called;
The RINIT method can be viewed as a preparation process that is automatically started between program executions.
A typical RINIT method is as follows:
PHP_RINIT_FUNCTION(extension_name) {
/* Initialize session variables, pre-populate variables, redefine global variables etc */
}
The first step to close PHP
Just like PHP startup, PHP shutdown is also divided into two steps:
Once the page is executed (whether it reaches the end of the file or is terminated with the exit or die function), PHP will start the cleanup process. It will call the RSHUTDOWN method of each module in sequence.
RSHUTDOWN is used to clear the symbol table generated when the program is running, that is, to call the unset function on each variable.
A typical RSHUTDOWN method is as follows:
PHP_RSHUTDOWN_FUNCTION(extension_name) {
/* Do memory management, unset all variables used in the last PHP call etc */
}
PHP close step 2
Finally, all requests have been processed, SAPI is ready to be closed, and PHP begins to execute the second step:
PHP calls the MSHUTDOWN method of each extension, which is the last chance for each module to release memory.
A typical RSHUTDOWN method is as follows:
PHP_MSHUTDOWN_FUNCTION(extension_name) {
/* Free handlers and persistent memory etc */
}
In this way, the entire PHP life cycle is over. It should be noted that "starting the first step" and "closing the second step" will only be executed when there is no request from the server.
The following is illustrated with some diagrams!

The underlying working principle of PHP

Figure 1 PHP structure

As can be seen from the picture, PHP is a 4-layer system from bottom to top

①Zend Engine

Zend is implemented entirely in pure C and is the core part of PHP. It translates PHP code (lexical, syntax analysis and other compilation processes) into executable opcode processing and implements corresponding processing methods and basic data. Structure (such as hashtable, oo), memory allocation and management, and providing corresponding api methods for external calls are the core of everything. All peripheral functions are implemented around zend.

②Extensions

Revolving around the zend engine, extensions provide various basic services in a component-based manner. Our common various built-in functions (such as array series), standard libraries, etc. are all implemented through extensions. Users can also implement their own as needed. extension to achieve function expansion, performance optimization and other purposes (for example, the PHP middle layer and rich text parsing currently used by Tieba are typical applications of extension).

③Sapi

The full name of Sapi is Server Application Programming Interface, which is the server application programming interface. Sapi uses a series of hook functions to enable PHP to interact with peripheral data. This is a very elegant and successful design of PHP. Through sapi, it can successfully PHP itself is decoupled and isolated from the upper-layer application. PHP can no longer consider how to be compatible with different applications, and the application itself can also implement different processing methods according to its own characteristics. It will be introduced later in the sapi chapter

④Upper layer application

This is the PHP program we usually write. We can obtain various application modes through different sapi methods, such as implementing web applications through webserver, running them in script mode on the command line, etc.

Architectural ideas:

The engine (Zend) + component (ext) model reduces internal coupling

The middle layer (sapi) isolates the web server and php

**************************************************** ***************************

If php was a car, then

The framework of the car is PHP itself

Zend is the engine of the car

The various components below Ext are the wheels of the car

Sapi can be regarded as a road, and cars can run on different types of roads

The execution of a php program is like a car running on the road.

Therefore, we need: a high-performance engine + the right wheels + the right track

The relationship between Apache and php
Apache's parsing of php is completed through the php Module among many Modules.

To finally integrate php into the Apache system, you need to make some necessary settings for Apache. Here, we will take the mod_php5 SAPI operating mode of php as an example to explain. As for the concept of SAPI, we will explain it in detail later.

Assume that the versions we install are Apache2 and Php5, then you need to edit Apache’s main configuration file http.conf and add the following lines to it:

Unix/Linux environment:

LoadModule php5_module modules/mod_php5.so

AddType application/x-httpd-php .php

Note: modules/mod_php5.so is the installation location of the mod_php5.so file in the X system environment.

In Windows environment:

LoadModule php5_module d:/php/php5apache2.dll

AddType application/x-httpd-php .php

Note: d:/php/php5apache2.dll is the installation location of the php5apache2.dll file in Windows environment.

These two configurations tell Apache Server that any URL user requests received in the future with php as the suffix will need to call the php5_module module (mod_php5.so/php5apache2.dll) for processing.

Apache life cycle

Apach’s request processing process

Detailed explanation of Apache request processing loop
What are the 11 stages of the Apache request processing cycle?

1. Post-Read-Request stage

In the normal request processing flow, this is the first stage where the module can insert hooks. This stage can be exploited for modules that want to get into processing requests very early.

2. URI Translation stage
Apache’s main job at this stage is to map the requested URL to the local file system. Modules can insert hooks at this stage to execute their own mapping logic. mod_alias uses this phase to work.

3. Header Parsing stage
Apache’s main job at this stage is to check the header of the request. Since the module can perform the task of checking request headers at any point in the request processing flow, this hook is rarely used. mod_setenvif uses this phase to work.

4. Access Control stage
The main work of Apache at this stage is to check whether access to the requested resources is allowed according to the configuration file. Apache's standard logic implements allow and deny directives. mod_authz_host uses this phase to work.

5. Authentication stage
The main work of Apache at this stage is to authenticate users according to the policy set in the configuration file and set the user name area. Modules can insert hooks at this stage to implement an authentication method.

6. Authorization stage
The main work of Apache at this stage is to check whether the authenticated user is allowed to perform the requested operation according to the configuration file. The module can insert hooks at this stage to implement a user rights management method.

7. MIME Type Checking stage
The main work of Apache at this stage is to determine the content processing function to be used based on the relevant rules of the MIME type of the requested resource. The standard modules mod_negotiation and mod_mime implement this hook.

8. FixUp stage
This is a general stage that allows the module to run any necessary processing before the content generator. Similar to Post_Read_Request, this is a hook that can capture any information and is also the most commonly used hook.

9. Response stage
Apache’s main job at this stage is to generate content returned to the client and be responsible for sending an appropriate reply to the client. This stage is the core part of the entire process.

10. Logging stage
Apache’s main job at this stage: recording the transaction after the reply has been sent to the client. Modules may modify or replace Apache's standard logging.

11. CleanUp stage
The main work of Apache at this stage is to clean up the environment left after the completion of this request transaction, such as the processing of files and directories or the closing of Socket, etc. This is the last stage of Apache's request processing.

LAMP architecture:

Four floors from bottom to top:

①liunx belongs to the bottom layer of the operating system

②apache server, a secondary server, communicates with Linux and PHP

③php: It is a server-side programming language and is associated with apache through the php_module module

④mysql and other web services: belong to application services and are associated with mysql through PHP’s Extensions plug-in module
Author: ibmfahsion