The request in the Nginx

In this section we say request, in Nginx we are referring to HTTP requests, specifically to nginx in the data structure is ngx_http_request_t. Ngx_http_request_t is the encapsulation of an HTTP request. We know that an HTTP request contains the request line, the request header, the request body, the response line, the response header, and the response body.

HTTP request is a typical network protocol for request-response type, and HTTP is a file protocol, so we are dealing with the request line and the request header, and the output response line and the response header, often on one line. If we write an HTTP server ourselves, usually after a connection is established, the client sends the request over. Then we read a row of data to analyze the method, URI, and http_version information contained in the request line. The request header is then processed on a line, and the request body is determined by the request method and the request header information, and then the request body is read. When the request is received, we process the request to produce the data that needs to be output, and then generate the response line, the response header, and the response body. After the response is sent to the client, a complete request is processed. Of course, this is the simplest way to deal with the webserver, in fact, Nginx is doing so, but there are some small differences, for example, when the request header read completed, it began to request processing. Nginx uses ngx_http_request_t to hold data related to the resolution request and the output response.

Next, let's briefly talk about how Nginx handles a complete request. For Nginx, a request starts with a ngx_http_init_request, in which the Read event is set to Ngx_http_process_request_line, which means that the next network event is made up of NGX_HTTP_ Process_request_line to execute. From the Ngx_http_process_request_line function name, we can see that this is the process of processing the request line, and just as previously said, the first thing to do with the request is to process the request line in the same way. The request data is read by Ngx_http_read_request_header. The Ngx_http_parse_request_line function is then invoked to resolve the request line. Nginx to improve efficiency, the state machine is used to parse the request line, and when the method is compared, the string comparison is not used directly, but the four characters are converted to an integral type, and then one comparison is made to reduce the number of instructions in the CPU, as mentioned earlier. Many people may be aware that a request line contains the requested method, Uri, and version, but does not know that it can contain a host in the request line. such as a request get http://www.taobao.com/uri http/1.0 such a request line is also legal, And host is www.taobao.com, this time, Nginx will ignore the host domain in the request header, and in the request line this is the same as to find the virtual host. In addition, for the http0.9 version, is not supported by the request headers, so this is also a special deal. Therefore, the protocol version is 1.0 or 1.1 after parsing the request header. The parameters that the entire request line resolves to are saved to the ngx_http_request_t structure.

After parsing the request line, Nginx sets the handler of the Read event to Ngx_http_process_request_headers, and then the subsequent request is Ngx_http_process_request_ Read and parse in headers. The Ngx_http_process_request_headers function is used to read the request header, like the request line, or to call Ngx_http_read_request_header to read the request header and invoke the Ngx_http_parse_ Header_line to parse a row of request headers, the resolved request headers are saved to the ngx_http_request_t domain headers_in, headers_in is a linked list structure that holds all the request headers. In HTTP, some requests are specially processed, and these request headers and request processing functions are stored in a mapping table, that is, ngx_http_headers_in, in the initialization, will generate a hash table, when each resolution to a request header, will first look in this hash table, If found, the corresponding handler function is invoked to handle the request header. For example: The handler function of the host header is ngx_http_process_host.

When nginx resolves to two carriage return newline characters, it represents the end of the request header, and the ngx_http_process_request is invoked to process the request. Ngx_http_process_request sets the current connection's read-write event handler function as Ngx_http_request_handler, and then calls Ngx_http_handler to actually start processing a complete HTTP request. Here may be strange, read-write event processing functions are ngx_http_request_handler, in fact, in this function, according to the current event is read or write events, respectively, call the ngx_http_request_t in the Read_event_ Handler or Write_event_handler. Because at this time, our request headers have been read, before have said, Nginx's practice is not to read the request body, so this inside we set Read_event_handler as ngx_http_block_reading, that is not read data. Just now, the real start of processing data is in the Ngx_http_handler function, which sets Write_event_handler to ngx_http_core_run_phases and executes ngx_http_core_ run_phases function. Ngx_http_core_run_phases This function will perform multistage request processing, nginx the processing of an HTTP request into multiple phases, then this function is to execute these stages to produce data. Because Ngx_http_core_run_phases will eventually produce data, it is easy to understand why the processing function that sets the Write event is ngx_http_core_run_phases. Here, I briefly explain the invocation logic of the function, and we need to understand that it is ultimately called ngx_http_core_run_phases to process the request, and the resulting response head is placed in the ngx_http_request_t headers_out, which I'll put it in the request processing process. Nginx of the various stages of the request processing, and finally will call filter filtering data, data processing, such as truncked transmission, gzip compression. The filter here includes header filter and body filter, that is, the response head or responder is processed. The filter is a linked list structure, which has header filter and body filter, and executes the first header filterAll filter, and then executes all the filter in the body filter. In header filter, the last filter, that is, Ngx_http_header_filter, this filter will traverse all the response headers, eventually requiring the output of the response head in a contiguous memory, and then call the Ngx_http_write_ Filter for output. Ngx_http_write_filter is the last in the body filter, so nginx first body information, after a series of body filter, finally will also call Ngx_http_write_filter to output ( There are diagrams to illustrate).

Note here, Nginx will put the entire request head in a buffer inside, the size of the buffer by the configuration item client_header_buffer_size to set, if the user's request too large, this buffer can not fit, The Nginx will redistribute a new, larger buffer to mount the request header, which can be set by large_client_header_buffers, this large_buffer a set of buffer, such as configuration 4 8k, means that there are four 8k sizes of buffer available. Note that in order to save the integrity of the request line or request header, a complete request line or request header needs to be placed in a contiguous memory, so a complete request line or request header will only be stored in a buffer. Thus, if the request line is greater than the size of a buffer, a 414 error is returned and 400 errors are returned if a request header is larger than a buffer size. After understanding the values of these parameters, and nginx the actual practice, in the application scenario, we need to adjust these parameters to the actual requirements to optimize our program.

Process Flowchart:

These are the lifecycle of an HTTP request in Nginx. Let's look at some of the concepts associated with the request.