Nginx Tutorial #1: Basic Concepts(转)
add by zhj: 文章写的很好,适合初学者
原文:https://www.netguru.com/codestories/nginx-tutorial-basics-concepts
Introduction
Hello! Sharing is caring, so we'd love to share another piece of knowledge with you. We prepared a three-part nginx tutorial. If you already know something about nginx, or if you'd just like to expand your experience and understanding - this is the perfect place for you!
We will tell you how nginx works, going through the concepts behind it, how you can optimise it to boost your app's performance, and how to get it up and running quickly.
This tutorial will have three parts:
- Basics concepts: get to know the difference between directive and context, the inheritance model, and the order in which nginx picks server blocks and locations.
- Performance: tips and tricks on improving speed. We will discuss gzip, caching, buffers, and timeouts.
- SSL setup: set up the configuration to serve content over HTTPS.
We aimed to create a series in which you can easily find the proper configuration for a particular topic (like gzip, SSL, etc.), or simply read it all through. For the best learning experience, we suggest you set nginx up on your own machine and fiddle with it yourself.
What is Nginx?
Nginx was originally created as a web server to solve the C10k problem. And, as a web server, it can serve your data with blazing speed. But nginx is so much more than just a web server. You can use it as a reverse proxy, making for easy integration with slower upstream servers (like Unicorn or Puma). You can distribute your traffic properly (load balancing), stream media, resize your images on the fly, cache content, and much more.
The basic nginx architecture consists of a master process and its workers. The master is supposed to read the configuration file and maintain worker processes, while workers do the actual processing of requests.
Base commands
To start nginx, simply type:
[sudo] nginx
While your nginx instance is running, you can manage it by sending signals:
[sudo] nginx -s signal
Available signals:
stop
: fast shutdownquit
: graceful shutdown (wait for workers to finish their processes)reload
: reload the configuration filereopen
: reopen the log files
Directive and Context
By default, the nginx configuration file can be found in:
/etc/nginx/nginx.conf
,/usr/local/etc/nginx/nginx.conf
, or/usr/local/nginx/conf/nginx.conf
This file consists of:
- directive: the option that consists of name and parameters; it should end with a semicolon
gzip on;
- context: the section where you can declare directives (similar to scope in programming languages)
worker_processes 2; # directive in global context
http { # http context
gzip on; # directive in http context
server { # server context
listen 80; # directive in server context
}
}
Directive types
You have to pay attention when using the same directive in multiple contexts, as the inheritance model differs for different directives. There are 3 types of directives, each with its own inheritance model.
Normal
Has one value per context. Also, it can be defined only once in the context. Subcontexts can override the parent directive, but this override will be valid only in a given subcontext.
gzip on;
gzip off; # illegal to have 2 normal directives in same context
server {
location /downloads {
gzip off;
}
location /assets {
# gzip is in here
}
}
Array
Adding multiple directives in the same context will add to the values instead of overwriting them altogether. Defining a directive in a subcontext will override ALL parent values in the given subcontext.
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 {
# this will override all the parent directives
error_log /var/log/nginx/error_downloads.log;
}
}
Action directive
Actions are directives that change things. Their inheritance behaviour will depend on the module.
For example, in the case of the rewrite
directive, every matching directive will be executed:
server {
rewrite ^ /foobar;
location /foobar {
rewrite ^ /foo;
rewrite ^ /bar;
}
}
If the user tries to fetch /sample
:
- a server rewrite is executed, rewriting from
/sample
, to/foobar
- the location
/foobar
is matched - the first location rewrite is executed, rewriting from
/foobar
, to/foo
- the second location rewrite is executed, rewriting from
/foo
, to/bar
This is a different behaviour than what the return
directive provides:
server {
location / {
return 200;
return 404;
}
}
In the case above, the 200
status is returned immediately.
Processing requests
Inside nginx, you can specify multiple virtual servers, each described by 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 give nginx some insight on how to handle incoming requests. Nginx will first check the listen
directive to test which virtual server is listening on the given IP:port combination. Then, the value from server_name
directive is tested against the Host
header, which stores the domain name of the server.
Nginx will choose the virtual server in the following order:
- Server listing on IP:port, with a matching
server_name
directive; - Server listing on IP:port, with the
default_server
flag; - Server listing on IP:port, first one defined;
- If there are no matches, refuse the connection.
In the example above, this will mean:
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"
The server_name
directive
The server_name
directive accepts multiple values. It also handles wildcard matching and regular expressions.
server_name netguru.co www.netguru.co; # exact match
server_name *.netguru.co; # wildcard matching
server_name netguru.*; # wildcard matching
server_name ~^[0-9]*\.netguru\.co$; # regexp matching
When there is ambiguity, nginx uses the following order:
- Exact name;
- Longest wildcard name starting with an asterisk, e.g. “*.example.org”;
- Longest wildcard name ending with an asterisk, e.g. “mail.*”;
- First matching regular expression (in the order of appearance in the configuration file).
Nginx will store 3 hash tables: exact names, wildcards starting with an asterisk, and wildcards ending with an asterisk. If the result is not in any of the tables, the regular expressions will be tested sequentially.
It is worth keeping in mind that
server_name .netguru.co;
is an abbreviation of:
server_name netguru.co www.netguru.co *.netguru.co;
With one difference: .netguru.co
is stored in the second table, which means that it is a bit slower than an explicit declaration.
listen
directive
In most cases, you’ll find that the listen
directive accepts IP:port values.
listen 127.0.0.1:80;
listen 127.0.0.1; # by default port :80 is used
listen *:81;
listen 81; # by default all ips are used
listen [::]:80; # IPv6 addresses
listen [::1]; # IPv6 addresses
However, it is also possible to specify UNIX-domain sockets:
listen unix:/var/run/nginx.sock;
You can even use hostnames:
listen localhost:80;
listen netguru.co:80;
This should be used with caution, as the hostname may not be resolved upon nginx's launch, causing nginx to be unable to bind on a given TCP socket.
Finally, if the directive is not present, *:80
, is used.
Minimal configuration
With all that knowledge, we should be able to create and understand the minimal configuration needed to run nginx.
# /etc/nginx/nginx.conf
events {} # event context needs to be defined to consider config valid
http {
server {
listen 80;
server_name netguru.co www.netguru.co *.netguru.co;
return 200 "Hello";
}
}
root
, location
, and try_files
directives
root
directive
The root directive sets the root directory for requests, allowing nginx to map the incoming request onto the file system.
server {
listen 80;
server_name netguru.co;
root /var/www/netguru.co;
}
Which allows nginx to return server content according to the request:
netguru.co:80/index.html # returns /var/www/netguru.com/index.html
netguru.co:80/foo/index.html # returns /var/www/netguru.com/foo/index.html
location
directive
The location
directive sets the configuration depending on the requested URI.
location [modifier] path
location /foo {
# ...
}
When no modifier is specified, the path is treated as prefix, after which anything can follow. The above example will match:
/foo
/fooo
/foo123
/foo/bar/index.html
...
Also, multiple location
directives 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 a few modifiers which can be used in conjunction with location
. These modifiers impact which location block will be used, as each modifier has assigned precedence.
= - Exact match
^~ - Preferential match
~ && ~* - Regex match
no modifier - Prefix match
Nginx will first check for any exact matches. If it doesn't find any, it'll look for preferential ones. If this match also fails, regex matches will be tested in the order of their appearance. If everything else fails, 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'
/match1 # => 'Case insensitive regex match'
/MATCH1 # => 'Case sensitive regex match'
/match-abc # => 'Prefix match: matches everything that starting with /match'
try_files
directive
This directive will try different paths, returning whichever is found.
try_files $uri index.html =404;
So for /foo.html
, it will try to return files in the following order:
- $uri ( /foo.html );
- index.html;
- If none is found: 404.
What’s interesting, if we define try_files
in a server
context, and then define a location that matches all requests, our try_files
will not be executed. This will happen because try_files
in a server
context defines its own pseudo-location, which is the least specific location possible. Therefore, defining location /
will be more specific than our pseudo-location.
server {
try_files $uri /index.html =404;
location / {
}
}
Thus, you should avoid try_files
in a server
context:
server {
location / {
try_files $uri /index.html =404;
}
}
Concluding remarks
Thank you for reading. This series would not have been possible without the great amount of resources found in the depths of the internet. Here are a few great websites we found especially useful when writing this series:
- nginx docs
- nginx blog
- nginx fundamentals on udemy
- Ilya Grigorik blog, and his amazing book: High Performance Browser Networking
- Martin Fjordvald blog
We'll be more than happy to see some feedback or discussion, so feel free to leave comments or get in touch in any other way! Did you like the tutorial? Do you have some suggestions on what subject we should take up next? Or maybe you spotted a bug? Let us know and see you next time!
Nginx Tutorial #1: Basic Concepts(转)的更多相关文章
- Basic Concepts of Block Media Recovery
Basic Concepts of Block Media Recovery Whenever block corruption has been automatically detected, yo ...
- (二)Basic Concepts 基本概念
Basic Concepts There are a few concepts that are core to Elasticsearch. Understanding these concepts ...
- CMUSphinx Learn - Basic concepts of speech
Basic concepts of speech Speech is a complex phenomenon. People rarely understand how is it produced ...
- [Web Service] Tutorial Basic Concepts
WSDL是网络服务描述语言,是一个包含关于web service信息(如方法名,方法参数)以及如何访问它. WSDL是UDDI的一部分. 作为web service 应用程序之间的接口,发音为wiz- ...
- [Network]Introduction and Basic concepts
[该系列是检讨计算机网络知识.因为现在你想申请出国.因此,在写这篇博客系列的大多数英语.虽然英语,但大多数就是我自己的感受和理解,供大家学习和讨论起来] 1 Network Edge The devi ...
- Lesson 1 Basic Concepts: Part 1
www.how-to-build-websites.com/basic-concepts/part1.php An introduction to domain names, web servers, ...
- Eric Linux - 1 Basic concepts of linux
Computer basic Computer 5 parts CPU Input Output Memory External storage device. CPU RISC: Reduced I ...
- Basic concepts of docker/kubernete/kata-container
Kubereters An open-source system for automating deployment, scaling, and management of containerized ...
- MVC LINQ to SQL: Basic Concepts and Features
http://www.codeproject.com/Articles/215712/LINQ-to-SQL-Basic-Concepts-and-Features
随机推荐
- linux echo命令颜色显示
echo命令颜色显示: echo: -n: 不换行. -e:让转移符生效. \t(tab) \n (换行) 实例: $ echo -e "\033[34mabcd\03 ...
- 高并发&高可用系统的常见应对策略
解耦神器:MQ MQ是分布式架构中的解耦神器,应用非常普遍.有些分布式事务也是利用MQ来做的.由于其高吞吐量,在一些业务比较复杂的情况,可以先做基本的数据验证,然后将数据放入MQ,由消费者异步去处理后 ...
- Nginx+Mysql调优
使用nginx实现反向代理作用,具备负载均衡的功能. 接受客户端的请求 | nginx(宿主机) | |-------------------| web1 web2 (客户机) 原理: 与 ...
- vue - 基础(1)
Vue基本用法 在学习Vue的基本用法之前,我们先简单的了解一些es6的语法 let: 特点:1.局部作用域 2.不会存在变量提升 3.变量不能重复声明 const: 特点:1.局部作用域 2.不会存 ...
- 201871020225-牟星源《面向对象程序设计(JAVA)》第二周学习总结
正文: 项目 内容 这个作业属于哪个课程 https://www.cnblogs.com/nwnu-daizh/ 这个作业的要求在哪里 https://www.cnblogs.com/nwnu-dai ...
- linux修改服务器时区并使用所选时区的时间
linux 修改服务器时区并使用所选时区的时间(以 ubuntu18.04 修改为美国芝加哥时区为例) 一.修改时区 /usr/bin/tzselect 1.选择地区, 美洲地区: ...
- Comet OJ 夏季欢乐赛 烤面包片
烤面包片 https://cometoj.com/contest/59/problem/C?problem_id=2698 题目描述 鸡尾酒最喜欢吃东北的烤面包片了.每次到东北地区的区域赛或者是秦皇岛 ...
- MongoDB executionStats 详细分步查询计划与分步时间(转载)
mongodb性能分析方法:explain() 为了演示的效果,我们先来创建一个有200万个文档的记录.(我自己的电脑耗了15分钟左右插入完成.如果你想插更多的文档也没问题,只要有耐心等就可以了.) ...
- linux command lynx
[Purpose] Learning linux command lynx [Eevironment] Ubuntu 16.04 terminal apt-get ...
- 待办事项App 评测
1. 敬业签 2. Microsoft To-Do(奇妙清单) 3. Evernote 4.one note 5.Google Keep 6.to-do-ist 7.365 日历 8.Any.Do 9 ...