Nginx使用操作
nginx原理讲解
强烈推荐https://www.cnblogs.com/zhouxinfei/p/7862285.html
nginx配置文件
http://www.nginx.cn/76.html
切换到 /usr/local/nginx/conf 文件夹
输入以下命令
1. ../sbin/nginx -t 测试nginx是否能够正常启动
2. 如果能正常启动 ../sbin/nginx 启动nginx
3. netstat -tnlp 查看nginx监控的端口，也可以理解为查看nginx是否正常启动
4. ../sbin/nginx -s reload 重启nginx
5. ../sbin/nginx -s stop 停止nginx
6.
nginx配置命令详解
worker_processes auto;
工作使用的进程数量
daemon on | off 默认on
是否以守护进程的方式运行nginx，
守护进程是指脱离终端并且在后头运行的进程，关闭守护进程执行
的方式可以让我们方便调试nginx
master_process on|off 默认on
是否以msater/worker方式进行工作
在实际的环境中nginx是以一个master进程管理多个worker进程的方
式运行的，关闭后nginx就不会fork出worker子进程来处理请求，而
是用master进程自身来处理请求。
master 和 worker 方式详解 https://blog.csdn.net/xxcupid/article/details/52494887
worker_processes number; 默认1
在master/worker运行方式下 worker进程的数目，一般情况下用户要配置与CPU内核数相等
的worker进程
worker_rlimit_nofile 默认为操作系统的限制连接数量
该值为worker进程可以打开的最大文件描述符的数量
events模块
events模块包含了nginx有关连接处理的配置
worker_connections
设置一个worker能够同时打开的最大连接数，该值最大为worker_rlimit_nofile的值
在nginx作为http服务器的时候，最大连接数为worker_processes * worker_connections
在nginx作为反向代理服务器的时候，最大连接数为worker_processes*worker_connections / 2
use
示例 use epoll
设置用于客户端线程的轮询方式，默认nginx会选择一个最适合你操作系统的方式
http模块
http模块下配置有server location upstream等不同的内容
include mine.types
文件扩展名与文件类型映射表
default_type application/octet-stream
默认的文件类型， octet-stream 流模式
文件模式查看网址 https://blog.csdn.net/wangjun5159/article/details/49644507
content-type和http状态码详解网址http://tool.oschina.net/commons
charset utf-8
设置默认编码
server_names_hash_bucket_size 128;
服务器名字的hash表大小
client_header_buffer_size 32k;
上传文件大小的限制
sendfile on
开启高效文件传输模式， sendfile指令指定nginx是否调用sendfile函数来输出文件
对于普通应用设为on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off
以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常，把这个改为off
autoindex on
开启目录列表访问，合适下载服务器，默认关闭
tcp_nopush on
防止网络阻塞
tcp_nodelay on
防止网络阻塞
keepalive_timeout 120
长连接超时时间,单位是秒
FastCGI相关参数
这些相关参数是为了改善网站的性能：减少在资源占用，提高访问速度
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
gzip模块
gzip on
开启gzip压缩输出
gzip_min_length 1k
最小压缩文件大小
gzip_buffers 4 16k
压缩缓冲区
gzip_http_version 1.0
压缩版本 默认1.1
gzip_comp_level 2
压缩等级
gzip_types text/plain application/x-javascript text/css application/xml
压缩类型，默认就已经包含text/html，不用再写上去，但是会有一个警告
gzip_vary on
有的浏览器支持压缩，有的浏览器不支持，所以避免浪费不支持的
也压缩，所以根据客户端的HTTP请求头来判断，是否需要压缩
upstream配置
upstream的负载均衡，weight是权重，可以根据机器配置定义权重
weight参数表示权值，权值越高被分配到的几率越大
upstream blog.ha97.com{
server 192.168.80.121:80 weight = 3;
server 192.168.80.122:80 weight = 2;
server 192.168.80.123:80 weight = 3;
}
虚拟主机的配置
server{
listen 80; # 监听80端口
server_name www.ha97.com ha97.com # 域名可以有多个，用空格隔开
index index.html index.htm index.php;
root /data/www/ha97;
location [=|~|~*|^~|@] / uri / {...}
# = 表示把uri作为字符串，与参数中的uri 做完全匹配
# ~ 表示进行正则表达式匹配的时候，区分大小写
# ~* 进行正则表达式的时候，不区分大小写
# ^~ 匹配RUI的时候,如果该location是最佳匹配，那么对于匹配这个location的字符串不在进行正则表达式的匹配检测
# 前面什么都没有的时候 例如 location /test/my 相当于是普通字符串匹配，按照最大前置的原则匹配
# @ 表示仅用于nginx服务内部请求之间的重定向，带有@的location不直接处理用户请求
# 匹配的优先级
#普通字符串和正则字符串的区别， ~和~*前缀表示location是正则字符串
#其他前缀和无前缀表示location是普通字符串
# 1.=优先级最高
# 2.^~ 次之
# 3. ~ 和 ~* 正则字符串匹配次之
# 4. 普通字符串等级最低
nginx变量
nginx的变量是以$开头的，可以是 $a ${a}
例：
server {
listen 8080;
location /foo {
echo "foo = [$foo]"
}
location /bar {
set $foo 32;
echo "foo = [$foo]";
}
}
注：
nginx的变量创建是在配置文件启动的时候创建的，赋值操作是在处理逻辑的时候执行的。
nginx变量必须创建后才能使用，如果没有创建，会导致nginx无法启动，一旦创建过nginx变量，
那么可见范围就是整个nginx配置，甚至可以跨越不同虚拟主机的server配置块
比如：
这里我们在/bar中用set指令创建了变量$foo,于是在整个配置文件中这个变量都是
可见的。
因此我们在 /foo中直接引用这个变量而不用担心nginx报错。不过注意赋值是在处理逻辑的时候进行的，
所以每个location里面都是有一份变量的独立副本的。
使用curl工具访问这2个接口
$ curl 'http://localhost:8080/foo'
foo = []
$ curl 'http://localhost:8080/bar'
foo = [32]
$ curl 'http://localhost:8080/foo'
foo = []
从例子我们就可以看到nginx变量名的可见范围虽然是整个配置，但每个请求都有所有变量的独立副本。
或者说都有各变量用来存放值的容器的独立副本，彼此互不干扰。也就是说nginx变量的生命期是不可能跨越请求边界的。
nginx的内部跳转
server {
listen 8080;
location /foo {
set $a 'hello';
echo_exc /bar;
}
location /bar{
echo "a = [$a]";
}
}
这里使用ngx_echo提供的echo_exec配置指令，进行内部跳转。所谓内部跳转，就是在处理请求的过程中，
于服务器内部，从一个location跳转到另一个location的过程。这是不同于利用HTTP状态码301和302所进行的外部跳转。
因为外部跳转是由HTTP客户端配合进行跳转的，而且客户端的地址栏的URL地址会发生变化。
内部跳转当前正在处理的请求就还是原来那个，只是当前的location发生了变化，但还是之前location的变量容器。
所以上例，如果我们请求的是/foo这个接口，那么输出结果就是 a=[hello],如果我们直接访问/bar 得到 a = []
$ curl "http://localhost:8080/foo"
a = [hello]
$ curl "http://localhost:8080/bar"
a = []
从上面例子看出，nginx的变量生命期是与当前正在处理的请求绑定的，与location无关。
nginx会在匹配参数的时候自动把原始请求中的参数名调整为全部小写的形式。
nginx许多内置变量都是只读的，对内建变量赋值应当绝对避免
也有一些内建变量是支持改写的，比如$args
location /test {
set $orig_args $args;
set $args "a=3&b=4";
echo "original args: $orig_args";
echo "args: $args";
}
$ curl 'http://localhost:8080/test'
original args:
args: a=3&b=4
$ curl 'http://localhost:8080/test?a=0&b=1&c=2'
original args: a=0&b=1&c=2
args: a=3&b=4
nginx存取程序
map $args $foo {
default 0;
debug 1;
}
server {
listen 8080;
location /test {
set $orig_foo $foo;
set $args debug;
echo "original foo: $orig_foo";
echo "foo: $foo";
}
}
花括号中第一行的 `default` 是一个特殊的匹配条件，即当其他条件都不匹配的时候，这个条件才匹配。
当这个默认条件匹配时，就把“因变量” `$foo` 映射到值 `0`. 而花括号中第二行的意思是说，
如果“自变量” `$args` 精确匹配了 `debug` 这个字符串，则把“因变量” `$foo` 映射到值 `1`.
将这两行合起来，我们就得到如下完整的映射规则：当 [$args]的值等于 `debug` 的时候，`$foo` 变量的值就是 `1`，否则 `$foo` 的值就为 `0`.
注：Nginx 模块可以为其创建的变量选择使用值容器，作为其“取处理程序”计算结果的缓存。
显然， [ngx_map] 模块认为变量间的映射计算足够昂贵，需要自动将因变量的计算结果缓存下来，这样在当前请求的处理过程中
如果再次读取这个因变量，Nginx 就可以直接返回缓存住的结果，而不再调用该变量的“取处理程序”再行计算了。
所以访问结果如下：
$ curl 'http://localhost:8080/test'
original foo: 0
foo: 0
$ curl 'http://localhost:8080/test?debug'
original foo: 1
foo: 1
nginx的主请求和子请求
子请求方式的通信是在同一个虚拟主机内部进行的，所以 Nginx 核心在实现“子请求”的时候，就只调用了若干个 C 函数，
完全不涉及任何网络或者 UNIX 套接字（socket）通信。我们由此可以看出“子请求”的执行效率是极高的
一般大多数第三方模块之间的父子请求和python类的继承很像，也有一些是子请求自动共享父请求的变量值容器的，下面会举例子
location /main {
set $var main;
echo_location /foo;
echo_location /bar;
echo "main: $var";
}
location /foo {
set $var foo;
echo "foo: $var";
}
location /bar {
set $var bar;
echo "bar: $var";
}
$ curl 'http://localhost:8080/main'
foo: foo
bar: bar
main: main
比如ngx_auth_request就不满足上述例子
location /main {
set $var main;
auth_request /sub;
echo "main: $var";
}
location /sub {
set $var sub;
echo "sub: $var";
}
$ curl 'http://localhost:8080/main'
main: sub
“为什么‘子请求’ `/sub` 的输出没有出现在最终的输出里呢？”
答案很简单，那就是因为 `auth_request` 指令会自动忽略“子请求”的响应体，而只检查“子请求”的响应状态码。
当状态码是 `2XX` 的时候，`auth_request` 指令会忽略“子请求”而让 Nginx 继续处理当前的请求，
否则它就会立即中断当前（主）请求的执行，返回相应的出错页。在我们的例子中，`/sub` “子请求”只是使用 [echo] 指令作了一些输出，
所以隐式地返回了指示正常的 `200` 状态码。
nginx内建变量用在子请求的上下文中时
location /main {
echo "main args: $args";
echo_location /sub "a=1&b=2";
}
location /sub {
echo "sub args: $args";
}
$ curl 'http://localhost:8080/main?c=3'
main args: c=3
sub args: a=1&b=2
location /main {
echo "main uri: $uri";
echo_location /sub;
}
location /sub {
echo "sub uri: $uri";
}
$ curl 'http://localhost:8080/main'
main uri: /main
sub uri: /sub
但不幸的是，并非所有的内建变量都作用于当前请求。少数内建变量只作用于“主请求”，
比如由标准模块 [ngx_http_core] 提供的内建变量 [$request_method]
location /main {
echo "main method: $request_method";
echo_location /sub;
}
location /sub {
echo "sub method: $request_method";
}
$ curl -i -XPOST 'http://localhost:8080/main' -d 'hello'
main method: POST
sub method: POST
