In-depth study and analysis of Nginx server

What is Nginx?

Nginx (Engine X) is a lightweight web server, reverse proxy server and email (IMAP/POP3) proxy server, high-performance HTTP server, with high stability, rich feature set, sample configuration files and Known for low system resource consumption .

What is a reverse proxy?

Reverse proxy (Reverse Proxy) mode refers to accepting the connection request on the Internet by a proxy server, then forwarding the request to the server on the internal network, and returning the result obtained from the server to the client requesting the connection on the Internet, At this time, the proxy server acts as a reverse proxy server to the outside world. When doing HTTP reverse proxy and load balancing, special attention should be paid to enabling HTTP long connection support.

web server

Apache should be well known to everyone, and Nginx is a web server that provides static web pages similar to Apache. Compared with Apache's multi-process and multi-thread concurrency model, Nginx is an event-based asynchronous IO concurrency model with better performance, and Nginx is a lightweight server .

For the introduction of Nginx, we will not go into too much detail, and now we will introduce the configuration of Nginx.

Introduction to the principle of Nginx

Nginx has a main process (Master) and several worker processes (Worker), and uses an event-based model and an operating system-dependent mechanism to efficiently distribute requests among worker processes.

  • The purpose of the master process (Master) is to read and evaluate the configuration, and maintain the worker process.

  • The worker process (Worker) processes the request, the number of worker processes can be defined in the configuration file, and can be modified for a given configuration, or automatically adjusted to the number of available CPU cores worker_processes.

Nginx modularization mechanism

Nginx is a modular system, the whole system is divided into modules, and each module is responsible for different functions. There are many parameters in the configure command above, which means that some modules can be added or removed before compiling here. We will compile the modules to be used into Nginx when compiling the source code, so how to use these modules? That has to be done through configuration files. Next, we will start to use the entry configuration practice guide stage to learn.

Getting Started Configuration Instructions Guide

Configuration files determine how Nginx and its modules work. By default, the configuration file is named nginx.conf, the default installation directory is /usr/local/nginx/conf, /etc/nginx or /usr/local/etc/nginx, the entire configuration file is controlled by instructions . nginx also has its own built-in instructions, such as events, http, server, and location, which will be mentioned below.

Nginx file configuration instructions

First of all, let's not consider the complicated configuration, just complete an http reverse proxy, the Nginx.conf configuration file is as follows:

Note: conf/nginx.conf is the default configuration file of nginx, you can also use nginx -c to specify your configuration file.

Nginx file writing rules

Nginx is composed of command control modules specified in configuration files. Instructions can be divided into simple instructions and block instructions.

simple command

A simple directive consists of a space-separated name and arguments and ends with a semicolon ;.

block instruction

Block directives have the same structure as simple directives, but instead of ending with a semicolon, they end with a set of additional directives surrounded by curly braces {}.

instruction context

A block directive is called a context if there can be other directives inside the curly braces of the block directive (for example: events, http, server and location).

main context

Directives placed outside any context in the configuration file are considered the main context main. The events and http directives are in the main main context, the server is in http, and the location is in server.

note

The content of the line after the pound sign # is considered a comment.

Getting Started Configuration Practical Cases

The general format structure of the configuration file

In this file, in this file, it mainly consists of three parts: events, http, mail.

highlighter- code-theme-dark

events {

}

http {

}

mail {

}

And blocks can also be nested. For example, server can be placed under http.

highlighter- code-theme-dark

http {

server {

}

}

Realize the mapping route of transferring images and html

Demand introduction

First on request, files from different local directories are served: /data/htmls (which may contain HTML files) and /data/images (which contains images).

configuration implementation

  1. Create the /data/htmls directory and put the index.html file in it. After that, create the /data/images directory and put some images in it.

  1. Open the nginx.conf configuration file, we first embed a block instruction server through the http block instruction.

highlighter- code-theme-dark

http {

server {

}

}

Contains several server block directives distinguished by the listen port and server names.

When Nginx decides which server to handle the request, it checks the URI specified in the request header against the parameters of the location directive defined in the server block.

Add the following location block directive to the server block directive:

highlighter- code-theme-dark

location / {

root /data/htmls;

}

location block directive
  • The specified / prefix is ​​compared to the URI in the request.

For matching requests, the URI will be added to the path specified in the root directive root, ie /data/htmls, to form the path to the requested file on the local filesystem.

If there are several matching location block directives, Nginx will choose the location block with the longest prefix. The location block above provides the shortest prefix, with a length of 1, so that block will only be used if all other location blocks cannot match.

Next, add a second location directive:

highlighter- code-theme-dark

location /images/ {

root /data;

}

Requests starting with /images/ will be matched (although location / can also match this request, but its prefix is ​​shorter)
The final server block directive

highlighter- code-theme-dark

server {

location / {

root /data/htmls;

}

location /images/ {

root /data;

}

}

Conclusion: A valid configuration that listens to the standard port 80 and can be accessed on the local machine through the http://localhost/ address. In response to a URI request starting with /images/, the server will send files from the /data/images directory. Since the standard port 80 is used, the listen command is not specified
Case conclusion introduction
For example, in response to a request for http://localhost/images/example.png , nginx will send the /data/images/example.png file. If this file does not exist, nginx will send a 404 error response. Requests for URIs that do not begin with /images/ will map to the /data/htmls directory. For example, in response to a http://localhost/some/example.html request, nginx will send the /data/www/some/example.html file .

To make the new configuration take effect immediately, start nginx if it is not already started, otherwise send the reload configuration signal to the nginx master process by executing:

highlighter- code-theme-dark

nginx -s reload

If the running effect is not as expected, you can try to find the reason from the access.log and error.log log files in /usr/local/nginx/logs or /var/log/nginx.


Case Practice Configuring a Simple Proxy Server

Demand case

A common use of Nginx is as a proxy server, which receives the request and forwards it to the proxy server, gets the response from it, and sends it back to the client. We will provide the file provided by the image request from the local directory and send all Other requests are sent to the proxied server.

First, define the proxy server by adding a server block to nginx's configuration file with the following content:

highlighter- code-theme-dark

server {

listen 8080;

root /data/up1;

location / {

}

}

  • listen : A simple server that listens on port 8080 and maps all requests to the /data/up1 directory on the local file system.

  • root : It represents the global default point. When root is not configured in the location, the path /data/up1 will be used.

Create this directory and place the index.html file in it.

Note that the root directive is in the server context. This root directive is used when the location block chosen to handle the request does not itself contain a root directive .

Modify the previous server configuration to make it a proxy server configuration. In the first location block, the protocol, domain name and port ( http://localhost:8080 ) of the proxy server specified with parameters are placed at the proxy_pass directive:

highlighter- code-theme-dark CSS

server {

location / {

proxy_pass http://localhost:8080;

}

location /images/ {

root /data;

}

}

  • proxy_pass: Set the URL root directory address of the corresponding downstream service request.

Modify the second location block that uses the /images/ prefix to map requests to files in the /data/images directory to match requests for image file extensions. The modified location block looks like this:

highlighter- code-theme-dark

location ~ \.(gif|jpg|png)$ {

root /data/images;

}

The parameter is a regular expression that matches all URIs ending in .gif, .jpg or .png. The regular expression should be preceded by ~. Corresponding requests will be mapped to the /data/images directory.

When Nginx chooses a location block to serve a request, it first checks for location directives that specify a prefix, remembers the location with the longest prefix, and then checks for regular expressions. If it matches the regular expression, nginx will choose this location, otherwise it will choose the one it remembered earlier .
The final configuration of the proxy server is as follows:

highlighter- code-theme-dark Go

server {

location / {

proxy_pass http://localhost:8080/;

}

location ~ \.(gif|jpg|png)$ {

root /data/images;

}

}

This server will filter requests ending in .gif, .jpg or .png and map them to the /data/images directory (by adding the URI to the root directive's argument) and pass all other requests to the proxy server configured above .

Case configuration - virtual server based on Host name

Nginx first has to decide which server should handle the request. Let's start with a simple configuration, three virtual servers all listening on port *:80:

highlighter- code-theme-dark

server {

listen 80;

server_name example.org www.example.org;

...

}

server {

listen 80;

server_name example.net www.example.net;

...

}

server {

listen 80;

server_name example.com www.example.com;

...

}

In this configuration, Nginx only examines the "Host" field in the request header to determine which server the request should be routed to.

If its value does not match any server, or the request does not contain this header field at all, then nginx will route the request to the default server for this port. In the configuration above, the default server is first - this is the standard default behavior of nginx. You can also explicitly set the default server through the default_server attribute of the listen command, such as the following configuration :

highlighter- code-theme-dark

server {

listen 80 default_server;

server_name example.net www.example.net;

...

}

The default_server parameter is available since version 0.8.21, use the default parameter in earlier versions .

Prevent requests from being processed with an undefined server name

Servers that discard requests that do not have a "Host" header field can be defined as:

highlighter- code-theme-dark Bash

server {

listen 80;

server_name "";

return 444;

}

The server name is set to an empty string, which will match requests without the "Host" header field, and return a special nginx non-standard code 404, and then close the connection.

Mixed name-based and IP-based virtual servers

Let's look at a more complex configuration, with some virtual servers listening on different addresses:

highlighter- code-theme-dark CSS

server {

listen 192.168.1.1:80;

server_name example.org www.example.org;

...

}

server {

listen 192.168.1.1:80;

server_name example.net www.example.net;

...

}

server {

listen 192.168.1.2:80;

server_name example.com www.example.com;

...

}

在这个配置中,nginx首先通过server块的listen指令检验请求的IP地址和端口。然后在通过server块的server_name入口检验请求的”Host”header域。如果服务器名称没有找到,请求将被默认服务器处理。

例如,在端口192.168.1.1:80接收到的去 www.example.com 的请求将被端口192.168.1.1:80的默认服务器处理。

默认服务器是监听端口的属性,并且不同的端口可以定义不同的默认服务器:

highlighter- code-theme-dark CSS

server {

listen 192.168.1.1:80;

server_name example.org www.example.org;

...

}

server {

listen 192.168.1.1:80 default_server;

server_name example.net www.example.net;

...

}

server {

listen 192.168.1.2:80 default_server;

server_name example.com www.example.com;

...

}

Guess you like

Origin blog.csdn.net/AuroraFaye/article/details/128963905