Under The Hood : How Web Servers Work.

Are you a software developer or a cloud engineer? Have you ever wondered what actually happens when you set up an Nginx or Apache web server for your PHP or Python web applications? Behind this simple process lies an even more fascinating process. We will be focusing our discussions around Nginx and PHP. Although the concept is the same for other web servers and languages.

What we will be discussing in this post:

• What a web server actually is

• How web servers deliver web content behind the scenes

• Why Nginx can’t execute PHP code directly

• The role of Common Gateway Interface(CGI)

• The Limitations of CGI

• The birth of FastCGI

• PHP-FPM

1. What is a web server?

A web server is a special piece of software designed to host and run web applications. It handles HTTP requests and responses, providing an environment for applications written in different programming languages like PHP, Java, C#, and their various web frameworks to execute and interact with clients over the Internet.
The most popular web servers are Nginx and Apache. Other widely used servers are Litespeed, Apache Tomcat, GlassFish, and Internet Information Services (IIS).

2. How does a web server deliver web content to clients?

When Nginx receives a request, it processes it in the following sequence:

1. Nginx receives HTTP requests on port 80 by default and port 443 for HTTPS.

2. It looks at the server_name and location blocks of the Nginx configuration file to determine how to handle the incoming request.

3. It checks for the type of content. If the file is static like HTML, CSS or an image file, Nginx reads it directly from the file system and sends it back to the client. If it is a dynamic file type like php, python, or Java, it forwards the request to the particular language’s processor.

NOTE: Nginx is primarily designed to serve static contents like html, css, and other file types like pictures, with .jpg or .png extensions.

3. Why can’t Nginx execute PHP Directly?

Nginx is not an application server but rather a web server. It doesn’t come with a built-in PHP interpreter. So when the client requests a dynamic file like index.php, Nginx passes the request to another service that can handle and execute PHP scripts. That service is called a CGI.

4. What is Common Gateway Interface (CGI)?

As mentioned above, Nginx doesn’t know how to run and interpret PHP scripts. This further applies to other languages like Ruby, Perl, Python …

To achieve this, we need something that connects the web server and the PHP scripts. This is where CGI comes into the picture.

The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. — CGI Specification

When a request comes in and Nginx notices that it is not requesting a static file, CGI launches a process for that request and then returns the output.

5. Limitations of CGI

While CGI was simple, it became very slow for busy servers because it had to run a process for every incoming request. That means, every request had to start the interpreter, which will load the libraries and initialize everything, then shut down after serving just one request. This works fine for a few requests but becomes disastrous when serving hundreds of requests in a short period of time. That simply means if a thousand requests are coming into the server, it creates a thousand processes get created. This is resource intensive and not scalable, as it causes CPU and memory usage to spike within a short period of time.

6. The birth of FastCGI

To fix the inefficiencies of CGI, FastCGI was created, and as its name suggests, it is faster. Instead of launching a process for every request that comes in, fastCGI creates a master process that contains a pool of worker processes that concurrently handle incoming requests. The workers stay alive for the next request without respawning each time. This reduces the CPU overhead of creating/destroying processes and also switching between them. FastCGI achieves this by using a technique called “Multiplexing”.

7. PHP-fpm

PHP-FPM, which stands for PHP FastCGI Process Manager, is a modern implementation of the FastCGI specifically built for PHP. PHP-fpm runs as a separate process on the server and Nginx can be instructed to pass every request to PHP-fpm, which will run it and return either HTML or JSON response back to Nginx.

Below is sample configuration file for Nginx that handles requests to static files and connects non-static files to PHP-fpm:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/html;
    index index.php index.html index.htm;

    # Static file handling
    location / {
        try_files $uri $uri/ =404;
    }

    # Non-static (PHP) file handling
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }
}

So, there you have it — from a simple request to how it’s processed by a web server. We’ve traced the journey a request takes through a web server. If you found this interesting, kindly like it, follow me, and share with your friends and colleagues. See you in the next one!