How to handle requests using Nginx

#Nginx uses a multi-process model to provide external services, including a master process and multiple worker processes. The master process is responsible for managing Nginx itself and other worker processes.

All actual business processing logic is in the worker process. There is a function in the worker process that executes an infinite loop, continuously processing the requests received from the client, and processing them until the entire Nginx service is stopped. (Recommended learning: nginx use)

In the worker process, the ngx_worker_process_cycle() function is the processing function of this infinite loop.

In this function, the simple processing flow of a request is as follows:

The mechanism provided by the operating system (such as epoll, kqueue, etc.) generates related events.

Receive and process these events. If data is received, a higher-level request object is generated.

Process the header and body of the request.

Generate a response and send it back to the client.

Complete the request processing.

Reinitialize timers and other events.

Request processing process

In order to let everyone better understand the request processing process in Nginx, we take HTTP Request as an example to explain in detail.

From within Nginx, the processing of an HTTP Request involves the following stages.

Initialize HTTP Request (read data from the client and generate an HTTP Request object, which contains all the information of the request).

Process request headers.

Process the request body.

Call the handler associated with this request (URL or Location), if any.

Call each phase handler in sequence for processing.

Here, we need to understand the concept of phase handler. Phase literally means stage. So phase handlers are easy to understand, they are handlers that contain several processing stages.

In each stage, there are several handlers. When processing reaches a certain stage, the handlers of that stage are called in turn to process the HTTP Request.

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

A phase handler usually performs the following tasks:

Get location configuration.

Produce an appropriate response.

Send response header.

Send response body.

When Nginx reads the header of an HTTP Request, Nginx first searches for the configuration of the virtual host associated with the request. If the configuration of this virtual host is found, then usually, this HTTP Request will go through the following stages of processing (phase handlers):

NGX_HTTP_POST_READ_PHASE: Read request content phase

NGX_HTTP_SERVER_REWRITE_PHASE: Server request address rewrite phase

NGX_HTTP_FIND_CONFIG_PHASE: Configuration lookup phase:

NGX_HTTP_REWRITE_PHASE: Location request address rewrite phase

NGX_HTTP_POST_REWRITE_PHASE: Request address rewrite submission Phase

NGX_HTTP_PREACESS_PHASE: Access permission check preparation phase

NGX_HTTP_ACCESS_PHASE: Access permission check phase

NGX_HTTP_POST_ACCESS_PHASE: Access permission check submission phase

NGX_HTTP_TRY_FILES_PHASE: Configuration item try_files Processing phase

NGX_HTTP_CONTENT_PHASE: Content generation phase

NGX_HTTP_LOG_PHASE: Log module processing phase

In the content generation phase, in order to generate a correct response to a request, Nginx must Leave it to an appropriate content handler to handle.

If the location corresponding to this request is explicitly specified as a content handler in the configuration file, then Nginx can directly find the corresponding handler by matching the location and hand the request to the content handler. to deal with. Such configuration directives include perl, flv, proxy_pass, mp4, etc.

If the location corresponding to a request does not directly have a configured content handler, then Nginx will try in sequence:

If a location has random_index on configured, then randomly select A file sent to the client.

If an index directive is configured in a location, then the file specified by the index directive is sent to the client.

If autoindex on is configured in a location, then the file list under the server path corresponding to the request address is sent to the client.

If gzip_static on is set on the location corresponding to this request, then check whether a corresponding .gz file exists, and if so, send this to the client (if the client supports gzip).

If the requested URI corresponds to a static file, the static module will send the content of the static file to the client.

After the content generation phase is completed, the generated output will be passed to the filter module for processing.

The filter module is also related to location. All fitter modules are organized into a chain. The output will pass through all filters in sequence until a return value from the filter module indicates that the processing has been completed.

Here are some common filter modules, such as:

server-side includes.

XSLT filtering.

Image scaling and the like.

gzip compression.

Among all filters, there are several filter modules that need attention. The instructions are as follows in the order of calls:

write: Write output to the client, actually writing to the socket corresponding to the connection.

postpone: This filter is responsible for subrequest, that is, subrequest.

copy: Copy some bufs (files or memory) that need to be copied and then hand them over to the remaining body filter for processing.

The above is the detailed content of How to handle requests using Nginx. For more information, please follow other related articles on the PHP Chinese website!