Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the Nginx request processing flow". In the daily operation, I believe many people have doubts about the Nginx request processing flow. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how the Nginx request processing flow is". Next, please follow the editor to study!

The 11 processing stages of nginx nginx actually divides the http request processing process into 11 stages. The reason for this division is that the execution logic of the request is subdivided into modules, and each stage can contain any number of HTTP modules and process the request in a pipelined manner. The advantage of this is to make the processing process more flexible and reduce the degree of coupling. The 11 HTTP phases are as follows:

1) NGX_HTTP_POST_READ_PHASE:

The stage in which the full HTTP header post-processing is received, which is before uri rewriting, and few modules are actually registered at this stage, which is skipped by default.

2) NGX_HTTP_SERVER_REWRITE_PHASE:

Before URI matches location, modify the URI stage for redirection, that is, execute the rewrite instruction within the server block and outside the location block. In the process of reading the request header, nginx will find the corresponding virtual host configuration based on host and port.

3) NGX_HTTP_FIND_CONFIG_PHASE:

Find a matching location block configuration item phase based on URI, which uses the rewritten uri to find the corresponding location. It is worth noting that this phase may be executed multiple times, because there may also be location-level rewrite instructions.

4) NGX_HTTP_REWRITE_PHASE:

The previous stage finds the location block and then modifies the URI,location-level uri rewrite phase, which executes the basic location rewrite instructions and may be executed multiple times.

5) NGX_HTTP_POST_REWRITE_PHASE:

To prevent the endless loop caused by rewriting URL, the next stage of location level rewriting is used to check whether there is a uri rewrite in the previous stage and jump to the appropriate stage according to the result.

6) NGX_HTTP_PREACCESS_PHASE:

The preparation before the next stage, the previous stage of access control, which is generally used for access control before the access control phase, such as limiting access frequency, the number of links, and so on.

7) NGX_HTTP_ACCESS_PHASE:

Let the HTTP module determine whether to allow the request to enter the Nginx server, access control phase, such as access control based on ip blacklist and whitelist, user name and password and so on.

8) NGX_HTTP_POST_ACCESS_PHASE:

In the later stage of access control, the corresponding processing is carried out according to the execution results of the access control phase, and the error code of denial of service is sent to the user to respond to the rejection of the previous stage.

9) NGX_HTTP_TRY_FILES_PHASE:

Set to access static file resources, the processing phase of the try_files instruction is skipped if the try_files instruction is not configured.

10) NGX_HTTP_CONTENT_PHASE:

In the stage of processing HTTP request content, most HTTP modules are involved in this phase, the content generation phase, which generates a response and sends it to the client.

11) NGX_HTTP_LOG_PHASE:

The logging phase after processing the request, which records the access log.

Of the above 11 stages, there are 4 stages in which HTTP cannot intervene:

3) NGX_HTTP_FIND_CONFIG_PHASE

5) NGX_HTTP_POST_REWRITE_PHASE

8) NGX_HTTP_POST_ACCESS_PHASE

9) NGX_HTTP_TRY_FILES_PHASE

In the remaining seven stages, HTTP modules can be involved, and there is no limit to the number of modules that can be involved in each stage. Multiple HTTP modules can intervene in the same stage and act on the same request at the same time.

The definition of the HTTP phase, including the checker checking method and the handler processing method, is shown below. The checker checking method in a HTTP processing phase of typedef structngx_http_phase_handler_s ngx_http_phase_handler_t;/* can only be implemented by the HTTP framework to control the flow of HTTP request processing * / typedef ngx_int_t (* ngx_http_phase_handler_pt) (ngx_http_request_t * r, ngx_http_phase_handler_t*ph) / * handler processing method implemented by HTTP module * / typedef ngx_int_t (* ngx_http_handler_pt) (ngx_http_request_t * r) Struct ngx_http_phase_handler_s {/ * when dealing with a certain HTTP phase, the HTTP framework will first call the checker method to handle the request on the premise that the checker method has been implemented, instead of directly calling the hanlder method in any stage, and will only call the handler method in the checker method. Therefore, in fact, all checker methods are implemented by the ngx_http_core_module module in the framework. And ordinary modules cannot redefine the checker method * / ngx_http_phase_handler_pt checker / * for HTTP modules other than ngx_http_core_module modules, only by defining handler methods can you intervene in a HTTP processing stage to process requests * / ngx_http_handler_pt handler / * the sequence number next of the next HTTP processing phase to be processed is designed so that the processing phase does not have to be executed sequentially, either jumping back several stages to continue execution, or jumping to a previous stage to execute again. Usually, next represents the first ngx_http_phase_handler_t processing method in the next processing phase * / ngx_uint_t next;}

After a http {} block is parsed, an array of ngx_http_phase_handler_t is generated according to the configuration in nginx.conf. In general, these phases are executed sequentially backward when processing HTTP requests, but the next members in ngx_http_phase_handler_t allow them to also be executed out of order. The ngx_http_phase_engine_t structure is an array of all ngx_http_phase_handler_t, as shown below:

Typedef struct {/ * handlers is the first address of an array of ngx_http_phase_handler_t, which represents all the ngx_http_handler_pt processing methods that a request may experience * / ngx_http_phase_handler_t * handlers / * indicates the sequence number of the first ngx_http_phase_handler_t processing method in the NGX_HTTP_SERVER_REWRITE_PHASE phase in the handlers array, which is used to quickly jump to the HTTP_SERVER_REWRITE_PHASE phase to process the request in any stage of executing the HTTP request * / ngx_uint_t server_rewrite_index / * indicates the sequence number of the first ngx_http_phase_handler_t processing method in the NGX_HTTP_PREACCESS_PHASE phase in the handlers array, which is used to quickly jump to the NGX_HTTP_PREACCESS_PHASE phase to process the request in any stage of executing the HTTP request * / ngx_uint_t location_rewrite_index;} ngx_http_phase_engine_t

As you can see, all the ngx_http_handler_pt processing methods that a user request may experience under the current nginx.conf configuration are saved in ngx_http_phase_engine_t, which is the key that all HTTP modules can cooperate to process user requests. This ngx_http_phase_engine_t structure is stored in the global ngx_http_core_main_conf_t structure, as shown below:

Typedef struct {ngx_array_t servers; / * ngx_http_core_srv_conf_t * / / * the phase engine constructed by the phases array composed of the following phase processing methods is the actual data structure for pipelined processing of HTTP requests * / ngx_http_phase_engine_t phase_engine; ngx_hash_t headers_in_hash Ngx_hash_t variables_hash; ngx_array_t variables; / * ngx_http_variable_t * / ngx_uint_t ncaptures; ngx_uint_t server_names_hash_max_size; ngx_uint_t server_names_hash_bucket_size Ngx_uint_t variables_hash_max_size; ngx_uint_t variables_hash_bucket_size; ngx_hash_keys_arrays_t * variables_keys; ngx_array_t * ports; ngx_uint_t try_files / * unsigned try_files:1 * / * is used to help each HTTP module add HTTP processing methods at any stage when the HTTP framework is initialized. It is a ngx_http_phase_t array with 11 members, each ngx_http_phase_t structure corresponds to a HTTP phase, after the HTTP framework is initialized. The running phases array is useless * / ngx_http_phase_t HTTP_LOG_PHASE + 1] } ngx_http_core_main_conf_t

There are two members in ngx_http_phase_t about the HTTP phase: phase_engine and phases, where phase_engine controls the HTTP processing phase through which a HTTP request is running, which will be used in conjunction with phase_handler members in the ngx_http_request_t structure (phase_handler determines which HTTP phase the current request should execute) The phases array, on the other hand, is more like a temporary variable, which is actually only used during Nginx startup, and its only mission is to initialize the handlers array in phase_engine with a probability of 11 phases.

The typedef struct {/ * handlers dynamic array holds the processing method * / ngx_array_t handlers;} ngx_http_phase_t added to the current stage when each HTTP module is initialized.

During the initialization of the HTTP framework, any HTTP module can add a custom method to the handler dynamic array in the postconfiguration method of the ngx_http_module_t interface, so that this method will eventually be added to the phase_engine dynamic array.

2 nginx lua 8 stages

Init_by_lua http

Set_by_lua server, server if, location, location if

Rewrite_by_lua http, server, location, location if

Access_by_lua http, server, location, location if

Content_by_lua location, location if

Header_filter_by_lua http, server, location, location if

Body_filter_by_lua http, server, location, location if

Log_by_lua http, server, location, location if

1) init_by_lua:

When nginx reloads the configuration file, run the lua script inside, which is often used to apply for global variables. (for example, for lua_shared_dict shared memory applications, shared memory data is emptied only when nginx is restarted, which is often used for statistics. )

2) set_by_lua:

Process branch processing determines variable initialization (sets a variable, commonly uses and calculates a logic, and then returns the result. Output API, Control API, Subrequest API, Cosocket API cannot be run at this stage)

3) rewrite_by_lua:

Functions such as forwarding, redirection, caching, etc. (for example, specific requests are proxied to the public network and run before the access phase, mainly for rewrite)

4) access_by_lua:

Centralized handling of IP admittance, interface permissions, etc. (for example, with iptable to complete a simple firewall, which is mainly used for access control and can collect most variables, similar to status needs to be available in the log phase. This instruction runs at the end of the nginx access phase, so it always runs after instructions such as allow and deny, even though they are both in the access phase. )

5) content_by_lua:

Content generation, the phase is the most important of all request processing phases, and the configuration instructions running at this stage are generally responsible for generating the content (content) and outputting the HTTP response.

6) header_filter_by_lua:

Reply HTTP filtering process, generally only used to set Cookie and Headers, etc., at this stage can not run Output API, Control API, Subrequest API, Cosocket API (such as adding header information).

7) body_filter_by_lua:

Reply BODY filtering (for example, completing the reply in uppercase) (usually called multiple times in a single request, because this implements the so-called "streaming output" based on HTTP 1.1 chunked encoding, which cannot run Output API, Control API, Subrequest API, Cosocket API)

8) log_by_lua:

Local asynchronous logging is completed after the session is completed (the log can be recorded locally and synchronized to other machines) (this phase is always run at the end of the request and is used for subsequent operations of the request, such as statistics in shared memory. For highly accurate data statistics, body_filter_by_lua should be used, and Output API, Control API, Subrequest API, Cosocket API cannot be run at this stage)

3. The corresponding relationship between nginx and lua at run time

1) init_by_lua, running on initialization Phase

2) set_by_lua, running in the rewrite phase

The set instruction comes from the ngx_rewrite module and runs in the rewrite phase.

3) the rewrite_by_lua instruction comes from the ngx_lua module and runs at the end of the rewrite phase

4) the access_by_lua instruction also comes from the ngx_lua module and runs at the end of the access phase

The deny instruction comes from the ngx_access module and runs in the access phase.

5) the content_by_lua instruction comes from the ngx_lua module and runs in the content phase; do not use it in the same location as other content processing instructions such as proxy_pass

The echo instruction comes from the ngx_echo module and runs in the content phase.

6) header_filter_by_lua runs in the content phase, and output-header-filter is generally used to set cookie and headers

7) body_filter_by_lua, running in the content phase

8) log_by_lua, running in the Log Phase phase

As shown in the figure:

At this point, the study on "what the Nginx request processing process is like" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.