Nginx's request processing

Nginx's request processing

Nginx uses a multi-process model to provide services to the outside world, one master process, and multiple worker processes. The master process is responsible for managing the Nginx itself and other worker processes.

All the actual business processing logic is in the worker process. There is a function in the worker process that performs an infinite loop, constantly processing incoming requests from the client and processing them until the entire Nginx service is stopped.

In the worker process, ngx_worker_process_cycle () function is the handler of this infinite loop. In this function, the simple processing of a request is as follows:

• The mechanisms provided by the operating system (e.g. epoll, kqueue, etc.) produce related events.
• Receiving and processing these events, if accepted to the data, results in higher-level request objects.
• Handles the header and body of the request.
• produces a response and sends it back to the client.
• Complete the processing of the request.
• Reinitialize timers and other events.

The processing process for the request

To give you a better understanding of the request processing process in Nginx, let's take HTTP Request as an example to explain in detail.

From Nginx's internal perspective, the processing of an HTTP Request involves the following stages.

• Initialize HTTP Request (reads data from the client and generates an HTTP Request object that contains all the information for the request).
• Process the request header.
• The request body is processed.
• If so, call the handler associated with this request (URL or Location).
• Each phase handler is called in turn for processing.

Here, we need to understand the concept of phase handler. P hase literally means stage. So it's good to understand that there are some handlers that contain several processing phases.

At each stage, there are several handlers, and then when you process to a stage, the handler of that stage is called in turn to process HTTP Request.

Typically, a phase handler processes this request and produces some output. Typically, the phase handler is associated with a location defined in the configuration file.

A phase handler typically performs the following tasks:

• Get the location configuration.
• Produce an appropriate response.
• Send response header.
• Send response body.

When Nginx reads to the header of an HTTP Request, Nginx first looks for the configuration of the virtual host associated with the request. If the configuration of this virtual host is found, this HTTP Request will typically go through several stages of processing:

• NGX_HTTP_POST_READ_PHASE: Read the request content stage
• NGX_HTTP_SERVER_REWRITE_PHASE: Server requests address override phase
• NGX_HTTP_FIND_CONFIG_PHASE: Configure the lookup phase:
• NGX_HTTP_REWRITE_PHASE: Location requests address rewrite phase
• NGX_HTTP_POST_REWRITE_PHASE: Request an address to rewrite the commit phase
• NGX_HTTP_PREACCESS_PHASE: Access check preparation phase
• NGX_HTTP_ACCESS_PHASE: Access check phase
• NGX_HTTP_POST_ACCESS_PHASE: Access checks the submission phase
• NGX_HTTP_TRY_FILES_PHASE: Configure items try_files processing phase
• NGX_HTTP_CONTENT_PHASE: Content generation phase
• NGX_HTTP_LOG_PHASE: Log module processing phase

During the content generation phase, in order to produce the correct response to a request, Nginx must give the request to a suitable content handler to handle. I f the location for this request is explicitly specified as a content handler in the configuration file, then Nginx can find the corresponding handler directly by matching the location and leave this request to the content handler for processing. Such configuration instructions include things like perl, flv, proxy_pass, mp4, etc.

If a request corresponds to a location that does not have a directly configured content handler, Nginx tries in turn:

• If there is a configuration in a random_index on, a file is randomly selected and sent to the client.
• If there is a configuration index instruction in a location, send the file indicated by the index instruction to the client.
• If autoindex on is configured in one location, a list of files under the service-side path corresponding to the request address is sent to the client.
• If there is a setting of gzip_static on on for .gz look for the presence of a corresponding .gz file, and if so, send this to the client (in the case of gzip supported by the client).
• If the requested URI corresponds to a static file, the static module sends the contents of the static file to the client.

When the content generation phase is complete, the resulting output is passed to the filter module for processing. T he filter module is also location-related. A ll fiter modules are organized into a chain. The output crosses all the filters in turn until there is a return value for the filter module indicating that processing is complete.

Here are a few common filter modules, such as:

• server-side includes。
• XSLT filtering。
• Image scaling, etc.
• gzip compression.

Of all the filters, there are a few filter modules to look at. This is described in order of call:

• write: Write output to the client, which is actually written to the socket corresponding to the connection.
• Monitor: This filter is responsible for subrequest, which is the sub-request.
• copy: Re-copy some buf (file or memory) that needs to be copied and hand it over to the remaining body filter for processing.