nginx 有一个master进程和一些worker进程；
master进程用于读取且评估配置以及维护worker进程，worker进程执行实际的请求；
nginx使用基于事件的模型和依赖于操作系统的机制来有效的在worker进程分发请求；
worker进程的数目在配置文件中定义，可以针对给定配置进行修复，也可以自动调整为可用CPU内核数
nginx主要用于1）提供静态内容；2）代理服务；3）FastCGI 代理
通常，配置文件根据监听的端口和server 那么分成几个server块，
一旦决定好使用哪个server后，就会测试请求头中的uri，用server块中的location指令来处理；
nginx -s signal
signal有以下几种情况:
stop — 立刻停止
quit — 优雅的停止，这个命令必须是开启nginx的同一个用户执行
reload — 重新加载配置文件
reopen — 重新打开日志文件
master收到重启信息后，检查新配置文件应用新的配置。如果成功,master进程开始新的worker，并且给老的worker发送信息结束服务。
老的worker收到worker信息以后，停止接收新的链接，且继续服务当前请求直到请求结束，老的worker才会退出。
location / {
root /data/www;
}
这里对于匹配的请求，uri会加入root指令指定路径；即/data/www，形成请求本地文件系统的路径；
如果有多个location的匹配块，选择前缀最长的一个。
最短的‘/’这个匹配,会在所有匹配都不生效的时候，匹配。
server {
listen 8080;
root /data/up1;
location / {
proxy_pass http://localhost:8080;
}
location ~ \.(gif|jpg|png)$ {
root /data/images;
}
}
服务监听8080端口，把所有的请求映射到本地的/data/up1文件下。
注意，root目录在server上下文中；当location指令中不包含root指令时，会使用server下的root指令；
当nginx选择一个location来服务请求时，会首先检查匹配的前缀，记下最长的匹配，然后检查正则表达式，
会优先使用正则匹配的location(正则匹配后不再继续往下匹配，即正则一旦匹配，就返回)，否则会使用前面记下的最长路径匹配。
上面代码中会过滤.gif, .jpg, or .png结尾的请求，映射到本地的/data/images目录；
其余的请求代理到proxy_pass配置的服务中处理
作为FastCGI代理使用时，将proxy_pass指令替换为fastcgi_pass；fastcgi_param 用于传递参数；
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80 default_server;
server_name example.net www.example.net;
...
}
server {
listen 80;
server_name example.com www.example.com;
...
}
这个配置中，nginx只会测试请求头的host字段来觉得使用哪个server匹配的路由；
如果host值和server_name都不匹配，或者请求不包含host字段，nginx会使用请求的端口号对应的默认的路由；
如果没有指定default_server;默认是第一个；显示指定如上例，在listen指令后面；
如果请求没有host字段不允许请求,可以如下设置，
server {
listen 80;
server_name "";
return 444;
}
server name设为' '；返回非标准码444关闭连接；
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;
...
}
上面的配置，nginx会根据listen指令首先测试请求地址的ip和port；
然后测试host头信息；且这个host匹配servername以后还要匹配ip和port;
如果server name没有找到，匹配默认server;
默认server是监听端口的属性，端口和ip不同的server有对应默认的server;
server {
listen 80;
server_name example.org www.example.org;
...
}
server {
listen 80;
server_name *.example.org;
...
}
server {
listen 80;
server_name mail.*;
...
}
server {
listen 80;
server_name ~^(?<user>.+)\.example\.net$;
location / {
root /sites/$2;
}
}
当通过name查找虚拟server时，如果多个名字都能匹配，例如通配符和正则都匹配，会按照下面的顺序优先匹配；
1）严格对应的名字
2）以*开头的最长的通配符名称；e.g. “*.example.org”
3）以*结尾的最长的通配匹配；e.g. “mail.*”
4）按照配置文件顺序中最先匹配的正则表达式；
1）使用通配符注意，只能在名字的开头或结尾使用，且只能有挨着一个.。“www.*.example.org” and “w*.example.org”都是不合理的;
2) 使用正则表达式， server_name 必须以~ 开头，否则会被当做严格的名字；域名中的.要加\转义(~^(?<user>.+)\.example\.net$;)
3）正则捕获的子表达可以在包含内容中使用；（上面最后一个server）
严格匹配的名字，*开头的通配符匹配，*结尾的通配符匹配会存储在监听端口对应的3张哈希表里；
哈希表的大小会在配置阶段优化，以便使用最少的cpu缓存；
The exact names 会优先查找，如果查找不到，然后查找*开头的通配符匹配的哈希表，如果还没找到，会查找*结尾的通配符匹配的哈希表
查找通配符名字会比准确的名字慢，因为名字会按照域名区分，注意 “.example.org”是存储在通配符的哈希表里而不是准确名称表里；
rewrite功能就是集合正则表达式和标志位实现url重写和重定向。
rewrite只能放在server{}、location{}、if(){}块中，并且只能对域名后边的出去传递参数外的字符串起作用。
表明看rewrite和location功能有点像，都能实现跳转，主要区别在于rewrite是在同一域名内更改获取资源的路径，
而location是对一类路径做控制访问或反向代理，可以proxy_pass到其他机器。
很多情况下rewrite也会写在location里，它们的执行顺序是：
- 执行server块的rewrite指令
- 执行location匹配
- 执行选定的location中的rewrite指令
如果其中某步URI被重写，则重新循环执行1-3，直到找到真实存在的文件；
循环超过10次，则返回500 Internal Server Error错误。
rewrite规则后边，通常会带有flag标志位：
- last : 相当于Apache的[L]标记，表示完成rewrite
- break : 停止执行当前虚拟主机的后续rewrite指令集
- redirect : 返回 302临时重定向，地址栏会显示跳转后的地址
- permanent : 返回 301永久重定向，地址栏会显示跳转后的地址
last 和 break 区别：
last一般写在 server和 if中，而 break一般使用在 location中
last不终止重写后的url匹配，即新的url会再从 server走一遍匹配流程，而 break终止重写后的匹配
break和 last都能组织继续执行后面的rewrite指令
rewrite常用正则：
. ： 匹配除换行符以外的任意字符
? ： 重复0次或1次
+ ： 重复1次或更多次
* ： 重复0次或更多次
\d ：匹配数字
^ ： 匹配字符串的开始
$ ： 匹配字符串的介绍
{n} ： 重复n次
{n,} ： 重复n次或更多次
[c] ： 匹配单个字符c
[a-z] ： 匹配a-z小写字母的任意一个
可以使用 ()来进行分组，可以通过 $1的形式来引用。