First, the user to dynamic PHP web page access process

The user’s browser has launched the web access: http://192.168.1.103/index.php

A three-way handshake between the user and the Nginx server is used for TCP connection (nginx access control policies, nginx firewall access control policies are ignored).

** Step 1: ** The user sends the HTTP request to the nginx server

** Step 2: ** Nginx determines the request based on the URI and suffix accessed by the user

1. For example, if the user accesses index.php, nginx matches the location in the configuration file, for example:

root@json:/data/web# cat /etc/nginx/conf.d/blog.conf server { root /data/web/blog/; index index.html index.htm; server_name www.fwait.com; location / { try_files $uri $uri/ /index.html; } location /blog/ { #alias /usr/share/doc/; auth_basic "authorized users only"; auth_basic_user_file /etc/nginx/passwd.conf; #autoindex on; Allow 192.168.1.103; deny all; } location ~ \.php$ { include /etc/nginx/fastcgi_params; fastcgi_intercept_errors on; Fastcgi_pass 127.0.0.1:9000; }}Copy the code

If the user accesses index.php, location ~.php$will match the size of the resources accessed by the user through the URI, and the resources accessed end in.php.

Nginx will perform an action corresponding to a specific location based on the resource requested by the user.

include /etc/nginx/fastcgi_params; # indicates that nginx calls fastCGI

fastcgi_intercept_errors on; # indicates that fastCGI interrupts and error messages are enabled

Fastcgi_pass 127.0.0.1:9000; 127.0.0.1:9000 = 127.0.0.1:9000 = 127.0.0.1:9000 = 127.0.0.1:9000 = 127.0.0.1:9000 = 127.0.0.1:9000 = 127.0.0.1:9000

According to the configuration of the Nginx server, it can be seen that the user is accessing dynamic PHP resources. Nginx will call the relevant PHP script parser to parse the resources accessed by the user.

As you can see from the second step, nginx sends the request to the FastCGI client, which sends the user’s request to phP-FPM via fastCgi_pass

If the user is accessing a static resource, then it is simple. Nginx directly returns the static resource requested by the user to the user.

After passing the dynamic resources to php-Fpm, php-Fpm will transfer the resources to the WRAPPER of the PHP script parsing server

! [](https://pic1.zhimg.com/80/v2-1cfa87ea1ac06cbfd125eddfc15459ca_720w.jpg)
! [](https://pic1.zhimg.com/80/v2-82e6d00a7691cc1b2bd1400609ee42af_720w.jpg)

On receipt of a request forwarded from PHP-fpm, the Wrapper generates a new thread that calls the PHP dynamic parser server

If the user requests to read the database, for example, the MySQL database, the database read operation is triggered.

If the user requests something like an image/attachment, PHP triggers a query of a back-end storage server such as a storage cluster that is stored over NFS.

PHP returns the result of the query to nginx

** Step 7: ** Nginx constructs a response message to return the result to the user

This is just one of the nginx, the user request and return user request results are asynchronous, that is, the user request resources in nginx do a transfer, nginx can be synchronized, that is, the parsed resources, the server directly back to the user, do not have to do a transfer in nginx.

Ii. Relevant questions

1. Is a complete dynamic resource resolution process triggered every time a user requests a dynamic resource?

No, there are two ways to solve this problem:

First, enable the caching function of nginx itself to cache the results of dynamic resource parsing. Next time the user accesses the corresponding resources, Nginx will perform this cache query. If the query is successful, the static resources after dynamic resource parsing will be directly returned to the user.

Second, deploy the caching machine in the nginx backend, such as varnish cache cluster, cache resources, users can first request resources in the cache cluster search;

2. Is it possible to use nginx for caching? If nginx is not a bottleneck in the entire Web architecture, nginx can be used for caching, but it is not recommended because nginx is the only way for users to request and respond to user requests. If nginx is a bottleneck, it does not matter how good the performance of other backend, such as storage cluster, is. So in a real deployment, it is not recommended to enable nginx caching (in the case of nginx as an HTTP server). Nginx caching can degrade nginx performance and consume hardware resources on the server where nginx is deployed.

3. If you use a graph to show the relationship between nginx FastCGI wrapper PHP

4. What exactly is FastCGI

The full name of CGI is Commmon Gateway Interface

A tool for program service communication on HTTP services. CGI programs must be running on a web server.

The traditional CGI interface approach suffers from poor performance because every time the HTTP server encounters a dynamic program, it needs to restart the parser to perform the parsing, and then the results are returned to the HTTP server. This is almost impossible when dealing with high concurrency, hence FastCGI. In addition, the traditional CGI interface is also very insecure

A scalable ground. Interface for high-speed communication between HTTP servers and dynamic scripting languages

The interface is a socket under Linux (the socket can be a file socket or an IP socket).

The main advantage is the separation of dynamic languages from HTTP servers. Most popular HTTP servers support FsatCGI including Apache/Nginx/ Lighttpd etc

PHP is a popular support language. The INTERFACE mode uses C/S architecture, which can separate the HTTP server from the script parser and start one or more script parsing daemons on the script parsing server.

Each time the HTTP server encounters a dynamic program, it can deliver it directly to the FastCGI process for execution, and then return the results to the browser. This approach allows the HTTP server to exclusively handle static requests or return the results of the dynamic script server to the client, greatly improving the overall performance of the application system.

5. Specific nginx + PHP nginx configuration

root@json:/data/web# cat /etc/nginx/nginx.conf|egrep -v "#|^$"
user www-data;
worker_processes 4;
pid /var/run/nginx.pid;
events {
    worker_connections 768;
}
http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    gzip on;
    gzip_disable "msie6";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
root@json:/data/web#

root@json:/data/web# cat /etc/nginx/conf.d/blog.conf
server {
    root /data/web/blog/;
    index index.html index.htm;
    server_name www.fwait.com;
    location / {
        try_files $uri $uri/ /index.html;
    }
    location /blog/ {
        #alias /usr/share/doc/;
        auth_basic "authorized users only";
        auth_basic_user_file /etc/nginx/passwd.conf;
        #autoindex on;
        allow 192.168.1.103;
        deny all;
    }
    location ~ \.php$ {
        #include /usr/local/etc/nginx/fastcgi.conf;
        include /etc/nginx/fastcgi_params;
        fastcgi_intercept_errors on;
        fastcgi_pass 127.0.0.1:9000;
    }

}
root@json:/data/web#
Copy the code

I hope the above content can help you. Many PHPer will encounter some problems and bottlenecks when they are advanced, and they have no sense of direction when writing too many business codes. I have sorted out some information, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, Redis, Swoft, Kafka, Mysql optimization, shell scripting, Docker, microservices, Nginx, etc. Many knowledge points can be free to share with you