Shulou(Shulou.com)06/03 Report--

Nginx modularization

# Nginx is based on modular design, each module is a functional implementation, distributed development, teamwork

# Core module, standard HTTP module, optional HTTP module, mail module, third party module

# compiled source code directory objs/ngx_modules.c

# https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/module.md

Web request Mechanism of Nginx

# parallel processing: multi-process, multi-thread, asynchronous

# https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/IO.md

Nginx event-driven model

# https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/event.md

Overview of Design Architecture

# Nginx is based on modular design and event-driven model to handle requests, main processes and worker processes

# https://coding.net/u/aminglinux/p/nginx/git/blob/master/4z/jg.md

Nginx modular structure

The modules involved in Nginx are divided into five categories: core module, standard HTTP module, optional HTTP module, mail service module and third-party module.

Core module

Core modules refer to the essential modules when the Nginx server is running normally. They provide the most basic and core services of Nginx, such as process management, rights control, error logging and so on.

It mainly includes support for two types of functions, one is the main function, including process management, rights control, error logging, configuration parsing, etc.

The other is the functions necessary to respond to request events, including event-driven mechanisms, regular expression parsing, and so on.

Ngx_core_module

Ngx_errlog_module

Ngx_conf_module

Ngx_regex_module

Ngx_events_module

Ngx_event_core_module

Ngx_epoll_module

Standard HTTP module

The standard HTTP module is the module included after compiling Nginx, which supports the standard HTTP function of the Nginx server.

Module function

Ngx_http_core configuration port, URI analysis, server response error handling, alias control, and other HTTP core transactions

Ngx_http_access_module access control based on IP address (allow / deny)

Ngx_http_auth_basic_module identity Authentication based on HTTP

Ngx_http_autoindex_module processes requests that end with "/" and automatically generates a directory list

Ngx_http_browser_module parses the value of the "User-Agent" field in the HTTP request header

Ngx_http_charset_module specifies the encoding of web pages

Ngx_http_empty_gif_module creates a 1 x 1 transparent gif image from memory, which can be quickly called

Ngx_http_fastcgi_module support for FastCGI

Ngx_http_geo_module converts the IP of the client into key-value pair variables. This module is mainly used to define variables for the customer's IP.

Ngx_http_gzip_module compresses the request response to reduce data transmission

Ngx_http_headers_filter_module sets the HTTP response header

Ngx_http_index_module processes requests that end with "/". If no index page in that directory is found, the request is forwarded to the ngx_http_autoindex_module module for processing.

Ngx_http_limit_req_module limits the response and processing rate of requests from the client

Ngx_http_limit_conn_module limits the response and processing rate of connections from the client

Ngx_http_log_module Custom access Log

Ngx_http_map_module creates arbitrary key-value pairs of variables

Ngx_http_memcached_module support for Memcached

Ngx_http_proxy_module supports proxy transactions

Ngx_http_referer_module filters the "referer" in the HTTP header, for example, to achieve hotlink protection

Ngx_http_rewrite_module realizes the rewrite function of nginx

Ngx_http_scgi_module support for SCGI

Ngx_http_upstream_module defines a set of servers that can receive redirects from agents, Fastcgi, and Memcached, mainly for load balancing

Optional HTTP module

The optional HTTP module is mainly used to extend the standard HTTP functionality to handle some special HTTP requests. When compiling Nginx, if you do not specify these modules, they will not be installed by default.

Module function

Ngx_http_addition_module adds text information at the beginning or end of the page that responds to the request

Ngx_http_degradation_module allows Nginx servers to return 444 or 204errors in low memory

Ngx_http_perl_module can use Perl scripts in the configuration file of Nginx

Ngx_http_flv_module supports the transfer of Flash multimedia information according to streaming files, and can return Flash according to the start location specified by the client.

Ngx_http_geoip_module supports parsing client requests based on GeoIP database

Ngx_google_perflools_module supports Google Performance Tools's set of tools for C++Profile

Ngx_http_image_filter_module supports the transfer of H.264/AAC-encoded multimedia information (usually suffixed as mp4, M4V or M4a) to a streaming file, often used with ngx_http_flv_module modules

When ngx_http_random_index_module Nginx receives a request that ends with "/", it randomly selects a file under the corresponding directory as the index file.

Ngx_http_secure_link_module supports checking the validity of the request link

Ngx_http_ssl_module supports HTTPS/SSL

Ngx_http_stub_status_module supports returning statistics of Nginx servers, generally including the number of connections processed, the number of successful connections, the number of requests processed, and the number of Header messages read and returned

Ngx_http_sub_module replaces the information in the response information with the specified string

Ngx_http_dav_module supports PUT, DELETE, MKCOL, COPY and MOVE methods in HTTP and WebDAV protocols

Ngx_http_xslt_module transforms XML response information using XSLT (extended stylesheet Transformation language)

Mail service module

Mainly used for mail services that support Ningx.

Third-party module

Modules that are not officially provided by Nginx, but developed by third-party organizations or individuals, are used to implement certain special functions.

Echo-nginx-module supports the use of echo, sleep, time and exec-like shell commands in Nginx configuration files

Lua-nginx-module enables Nginx to support lua scripting language

Synchronization mechanism

Synchronization and asynchronism occur when the server processes the client's request after the client initiates the request.

Synchronization mechanism means that after the client sends the request, it needs to wait for the server (kernel) to return the information before sending the next request.

In the synchronization mechanism, all requests are synchronized on the server side, that is, the sender and receiver process the request at the same pace.

Asynchronous mechanism

Asynchronous mechanism means that after the client sends a request, it continues to send the next request without waiting for the server (kernel) to return the information.

In the asynchronous mechanism, all requests from the sender form a queue, and the receiver notifies the sender after processing.

For example, the receptionist of a hotel will receive a lot of calls to book banquets during the peak season.

In the case of synchronization mechanism, the front desk will not hang up after each phone call, but check whether there is any remaining banquet and tell the customer when the result is found.

In the case of asynchronous mechanism, the receptionist will reply directly to the customer every time he receives a scheduled call, and the receptionist will reply later. At this time, the receptionist will hand over the inquiry to another colleague.

After hanging up the phone, the receptionist will continue to deal with the affairs of other customers, and notify the receptionist when other colleagues find out the results, and the receptionist will notify the customer.

Blockage

Blocking and nonblocking occur in IO scheduling, such as kernel-to-disk IO.

In blocking mode, the process / thread is suspended by the system before getting the final result, which is called blocking, and the process can do nothing during the blocking process.

It does not return to running state until the final result is fed back to it.

Non-blocking

In non-blocking mode, in contrast to blocking, the process / thread does not enter a suspended state before getting the final result, but the process can continue to perform new tasks.

When the final result is fed back to the process, it delivers the result to the client.

For example: it is still a case of hotel receptionist receiving booking phone calls.

At this time, the role is no longer the receptionist, but her colleagues who inquire whether there are any remaining banquets. If it is a blocking mode, the colleague needs to be foolish in the process of checking whether there is any remaining banquet.

Wait for the hotel management system to return the results to him, and nothing else can be done during this period.

If it is non-blocking, the colleague can do other things while waiting for the hotel management system to return the results, such as notifying the front desk of the remaining banquets.

Request Mechanism of Nginx

Nginx can support high concurrency because Nginx uses an asynchronous non-blocking mechanism, while Nginx relies on an event-driven model to implement this mechanism.

Under Nginx's event-driven model, all requests made by the client are marked as an event on the server side, and Nginx collects these events into the event collector.

These events are then handed over to the kernel to handle.

Event-driven model

Event-driven model is a means to achieve asynchronous non-blocking. In the event-driven model, a process (thread) is fine.

For the web server, when a request from client A connects to the server, a process (Nginx worker process) on the server will process the request

When this process does not return the result to client A, it processes the request from client B.

The server sends the request from client An and client B to the event collector as an event.

On the other hand, the event collector sends the collected events to the event transmitter to the event handler for processing.

Finally, after the event handler handles the event, it notifies the server process, and the server process returns the result to client An and client B.

In this process, what the server process does is at the user level, while the part of the event handling is at the kernel level.

In other words, this event-driven model needs to be supported by the operating system kernel.

Event-driven Model of Nginx

Nginx's event-driven model, which supports select, poll, epoll, rtsig, kqueue, / dev/poll, eventport and so on.

The first three are the most commonly used, and the kqueue model is used to support the event-driven model of the BSD series platform. Kqueue is a variant of the poll model, essentially the same as epoll.

/ dev/poll is the event-driven model of the Unix platform, mainly in Solaris7 and above, HP/UX11.22 and above, IRIX6.5.15 and above,

Tru64 Unix version 5.1A and above.

Eventport is an event-driven model used to support Solaris10 and above.

Select model

Both Linux and Windows are supported, and the steps to use the select model are:

Create a collection of descriptors for events of interest, and for a descriptor, you can focus on the Read events, Write events, and Exception events above it.

In the select model, you create these three types of event descriptor collections.

Call the underlying select () function and wait for the event to occur.

Poll each event descriptor in all event descriptors collection to see if a corresponding event has occurred, and if so, process it.

Poll model

Poll model is an event-driven model on Linux platform, which is introduced in Linux2.1.23 and is not supported by Windows platform.

The poll model and the select model work in much the same way, except that the select model creates three sets of descriptors, while the poll model creates only one set of descriptors.

Epoll model

Epoll model is a variant of poll model, which is introduced in Linux2.5.44. Epoll is more efficient than poll because it does not need to poll the entire collection of descriptors

Instead, the Linux kernel focuses on the set of events, and the kernel notifies you when there is a change.

Nginx architecture

The Nginx server uses master/worker multiprocess mode.

After the main process (Master process) is started, external signals are received and processed.

After the main process starts, one or more child processes (work process) are generated through the fork () function, and each child process initializes the process.

Module calls and the reception and handling of events.

Main process

The main function is to communicate with the outside world and manage other internal processes, specifically the following:

Read the Nginx configuration file and verify its validity and correctness

Establish, bind, and close socket

Generate and manage work processes according to configuration

Receive external instructions, such as restart, shutdown, reload service, etc.

Log file management

Child process (worker process)

Is generated by the main process, and the number of builds can be defined in the configuration file. The main work of the process is as follows:

Receive client request

Send the request to each function module in turn for filtering

IO call to get response data

Communicate with the back-end server and receive the processing results of the back-end server

Data caching, accessing cached indexes, querying and calling cached data

Send the result of the request and respond to the client request

Receive master process instructions, such as restart, reload, exit, etc.

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.