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

This article mainly explains "what is the basic concept of Nginx". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the basic concept of Nginx"?

What is Nginx?

Nginx was originally created as a Web server to solve the problem of C10k. As a Web server, it can serve your data at an amazing speed. But Nginx is not just a Web server, you can also use it as a reverse proxy to easily integrate with slower upstream servers such as Unicorn or Puma. You can allocate traffic (load balancer), streaming media, dynamically resize images, cache content, and so on. The basic nginx architecture consists of the master process and its worker process. Master reads the configuration file and maintains the worker process, while worker actually handles the request.

Basic command

To start nginx, simply type:

[sudo] nginx

When your nginx instance is running, you can manage it by sending the appropriate signal:

[sudo] nginx-s signal

Available signals:

Stop-quickly close quit-gracefully close (wait for worker thread to finish processing) reload-reload configuration file reopen-reopen log file

Command and context

The configuration file for nginx. The default locations include:

/ etc/nginx/nginx.conf,/usr/local/etc/nginx/nginx.conf, or / usr/local/nginx/conf/nginx.conf

The configuration file consists of the following parts:

Instructions-optional, including names and parameters, ending with a semicolon gzip on; context-chunks, you can declare instructions-similar to the scope worker_processes 2 in a programming language; # global context instructions http {# http context gzip on; # http context instructions server {# server context listen 80 # instructions in the context of server}}

Instruction type

Care must be taken when using the same instruction in multiple contexts because the inheritance model has different instructions at the same time. There are three types of instructions, each with its own inheritance model.

General instruction

There are only unique values in each context. Moreover, it can only be defined once in the current context. The child context can override the value in the parent, and this override value is only valid in the current child context.

Illegal gzip on;gzip off; # cannot specify the same common instruction twice in the same context server {location / downloads {gzip off;} location / assets {# gzip is on here}}

Array instruction

Adding multiple instructions in the same context adds multiple values rather than completely overriding them. Defining an instruction in a child context overrides the value in the parent context.

Error_log / var/log/nginx/error.log;error_log / var/log/nginx/error_notive.log notice;error_log / var/log/nginx/error_debug.log debug;server {location / downloads {# the configuration below overrides the directive error_log / var/log/nginx/error_downloads.log;} in the parent context

Action instruction

Action is an order to change things. Depending on the needs of the module, the behavior it inherits may be different. For example, the rewrite instruction will be executed as long as it matches:

Server {rewrite ^ / foobar; location / foobar {rewrite ^ / foo; rewrite ^ / bar;}}

If the user wants to try to get / sample:

Server's rewrite will be executed, from / sample rewrite to / foobarlocation / foobar will be matched with location's first rewrite execution, from / foobar rewrite to / foolocation's second rewrite execution, from / foo rewrite to / bar

The return directive provides a different behavior:

Server {location / {return 200; return 404;}}

In the above case, return 200 immediately.

Process the request

Within Nginx, you can specify multiple virtual servers, each described in a server {} context.

Server {listen *: 80 default_server; server_name netguru.co; return 200 "Hello from netguru.co";} server {listen *: 80; server_name foo.co; return 200 "Hello from foo.co";} server {listen *: 81; server_name bar.co; return 200 "Hello from bar.co";}

This will tell Nginx how to handle incoming requests. Nginx will first test which virtual host is listening on a given IP port combination by checking the listen instruction.

The value of the server_name instruction then detects the Host header (where the host domain name is stored).

Nginx will select the virtual hosts in the following order:

The IP- port host that matches the sever_name instruction has the IP- port host marked by default_server. If there is no match, the IP- port host first defined by the IP- port host rejects the connection.

For example, the following example:

Request to foo.co:80 = > "Hello from foo.co" Request to www.foo.co:80 = > "Hello from netguru.co" Request to bar.co:80 = > "Hello from netguru.co" Request to bar.co:81 = > "Hello from bar.co" Request to foo.co:81 = > "Hello from bar.co"

Server_name instruction

The server_name instruction accepts multiple values. It also handles wildcard matching and regular expressions.

Server_name netguru.co www.netguru.co; # exact matchserver_name * .netguru.co; # wildcard matchingserver_name netguru.*; # wildcard matchingserver_name ~ ^ [0-9] *\ .netguru\ .co $; # regexp matching

When there is ambiguity, nginx uses the following command:

The exact name the longest wildcard name begins with an asterisk, such as "* .example.org". The longest wildcard name ends with an asterisk, for example, "mail.**" matches the regular expression first (in the order in the configuration file)

Nginx stores three hash tables: the exact name, a wildcard that begins with an asterisk, and a wildcard that ends with an asterisk. If the result is not in any table, the regular expression test is performed sequentially.

It is worth remembering that

Server_name .netguru.co

Is an acronym from the following

Server_name netguru.co www.netguru.co * .netguru.co

With one difference, .netguru.co is stored in the second table, which means it is a little slower than explicitly declared.

Listen instruction

In many cases, you can find the listen instruction and accept the IP: Port value

Listen 127.0.0.1 is usedlisten 80: 127.0.0.1; # by default all ips are usedlisten: 80 is usedlisten *: 81; # by default all ips are usedlisten [:]: 80; # IPv6 addresseslisten [:: 1]; # IPv6 addresses

However, you can also specify UNIX-domain sockets.

Listen unix:/var/run/nginx.sock

You can even use the hostname

Listen localhost:80;listen netguru.co:80

However, please use it with caution, because the host may not be able to start nginx, so it cannot be bound to a specific TCP Socket.

Finally, if the instruction does not exist, use *: 80.

Minimize configuration

With this knowledge-we should be able to create and understand the minimum configuration required to run nginx.

# / etc/nginx/nginx.confevents {} # events context needs to be defined to consider config validhttp {server {listen 80; server_name netguru.co www.netguru.co * .netguru.co; return 200 "Hello";}}

Root, location, and try_files instructions

Root instruction

The root directive sets the root directory of the request, allowing nginx to map incoming requests to the file system.

Server {listen 80; server_name netguru.co; root / var/www/netguru.co;}

Specify what is allowed by the nginx server based on the given request

Netguru.co:80/index.html # returns / var/www/netguru.co/index.htmlnetguru.co:80/foo/index.html # returns / var/www/netguru.co/foo/index.html

Location instruction

The location instruction sets the configuration based on the requested URI. Location [modifier] path

Location / foo/ {#...}

If no modifier is specified, the path is treated as a prefix and can be followed by anything.

The above examples will match

/ foo/fooo/foo123/foo/bar/index.html...

In addition, multiple location instructions can be used in a given context.

Server {listen 80; server_name netguru.co; root / var/www/netguru.co; location / {return 200 "root";} location / foo/ {return 200 "foo";}} netguru.co:80 / # = > "root" netguru.co:80 / foo # = > "foo" netguru.co:80 / foo123 # = > "foo" netguru.co:80 / bar # = > "root"

Nginx also provides some modifiers that can be used to connect to location. These modifiers affect where the location module is used because each modifier is assigned a priority.

=-Exact match ^ ~-Preferential match~ & & ~ *-Regex matchno modifier-Prefix match

Nginx will check the exact match first. If we can't find it, we'll find the one with the highest priority. If the match still fails, the regular expression matching will be tested in the order in which it appears. At least, the last prefix match will be used.

Location / match {return 200' Prefix match: matches everything that starting with / match';} location ~ * / match [0-9] {return 200' Case insensitive regex match';} location ~ / MATCH [0-9] {return 200' Case sensitive regex match';} location ^ ~ / match0 {return 200' Preferential match';} location = / match {return 200' Exact match' } / match/ # = > 'Exact match'/match0 # = >' Preferential match'/match2 # = > 'Case insensitive regex match'/MATCH1 # = >' Case sensitive regex match'/match-abc # = > 'Prefix match: matches everything that starting with / match'

Try_files instruction

Try a different path, find a path and return.

Try_files $uri index.html = 404

So for the / foo.html request, it will try to return the files in the following order:

$uri (/ foo.html) index.html returns 404 if nothing is found

Interestingly, if we define the try_files in the server context and then define the location of all matching requests-- the try_files will not be executed.

This is because the try_files defined in the server context is its pseudo-location, which is the most unlikely location. Therefore, defining location/ will be more specific than pseudo-location.

Server {try_files $uri / index.html = 404; location / {}}

Therefore, you should avoid try_files in the context of server:

Server {location / {try_files $uri / index.html = 404;}} at this point, I believe you have a deeper understanding of "what is the basic concept of Nginx", you might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.