nginx学习笔记

1、操作

./nginx -s 消息

quit		退出、关闭
stop		快速的退出关闭
reload		重新加载配置文件 
reopen		重写打开日志文件
start		启动

如果在重启过程中提示打不开进程文件，可以执行以下命令
./nginx -c /usr/local/nginx/conf/nginx.conf

2、工作原理

nginx是由内核和模块组成，nginx内核是工作的比较，绝大部分的工作都是由模块来完成。
客户端向服务器发送请求时，首先是由内核模块进行处理，内核模块处理是会直接映射到配置文件中的location部分，location是由一个handler模块和多个filter模块组成。
handler模块主要是去处理请求头和请求内容，将处理的结果返回到filter模块中，filter模块会对信息进行合适的筛选，然后再返回到客户端。
nginx从结构层面来说主要包括：核心模块、基础模块、第三方模块。

核心模块：http模块、mail模块（邮件）、event模块。
基础模块：http access模块、http rewrite模块、http proxy模块、http fastcgi模块
第三方模块：Http Upstream Request Hash模块、 Notice模块和HTTP Access Key模块

nginx从功能的角度来划分可以分为：handler处理模块、filter过滤器模块、proxy模块。

handler处理器模块：处理发送过来的请求，并对内容和handler信息做适当的修改，再将内容输出到filter过滤器模块
filter过滤器模块：主要是对handler处理模块输出的信息进行修改并输出到客户端，即http response
proxy模块：主要是http upstream类的模块，与服务和操作系统进行打交道

3、进程运行的模型

当启动nginx服务器时，系统会生成一个master进程和多个worker进程，所有的worker子进程都是由master进程来生成。master进程不仅仅是会生成worker子进程，还会对worker子进程进行监控和管理。
worker子进程会监控所有的用户提交上来的请求，通过socket来监控，当有请求进来时，所有的worker子进程都会抢着来处理这个http请求。这里只可能有一个进程可以处理这个HTTP请求（同时），其他进程会失败，这就是所谓的“惊群”现象，会浪费很多资源。
为了解决“惊群”现象，nginx会引入互斥锁accept_mutex，只有获得accept_mutex的子进程才可以去处理客户端提交的请求。

主进程master		worker_process		参数决定主进程的个数		管理监控工作进程
工作进程worker		worker_connections	参数决定工作进程的个数
互斥锁accept_mutex	ngx_accept_disable

服务器最多可以同时处理多少请求：
（worker_process  *  worker_connections） /  2

4、http请求运行过程

5、nginx上下文（配置文件）

配置文件
配置项的内容称为上下文
# 全局变量
# 生成工作进程的名称
user  nobody; # a directive in the 'main' context 

# 设置连接的工作进程  事件的上下文
events {
    # configuration of connection processing 
}

# http请求的相关内容
http {
	 # configuration specific to HTTP and affecting all virtual servers
	 #虚拟机或虚拟服务器
	 server{
	 	# configuration of HTTP  virtual servers 1
	 	# 位置的上下文，访问服务器的URI
	 	location one {
	 		# configuration for processing URIs starting with 'one'
	 	}
	 	location two {
	 		# configuration for processing URIs starting with 'two'
	 	}
     } 
     server {
     	# configuration of HTTP  virtual servers 1
     }
}

stream {
	# configuration specific to TCP/UDP and affecting all virtual servers
	server {
		# configuration of TCP virtual servers 1
	}
}

nginx配置文件包括：

全局变量
events上下文
http上下文
server上下文，必须是声明在http上下文中
location上下文，必须声明在server上下文中

常见配置项含义：

user: 表示子进程用户，master process是主进程，其他的子进程都是由master process来决定
worker_processes: 表示当服务器启动时，生成的子进程数，这个子进程数由CPU的核数来决定。推荐是CPU内核数或者内核数的倍数
error_log: 表示错误日志文件位置
work_connections: 表示每个子进程最多允许的连接数。查看当前linux系统中resource limit指令的值：cat /proc/sys/fs/file-max
user eproll: 表示IO复用模型
include mime.type: 表示传输文件的格式
sendfile: 表示发送文件是否开启。指定nginx是否调用sendfile函数来输出文件。对于普通应用，必须设为on。如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络IO处理速度，降低系统uptime
log_format: 表示日志文件的格式
access_log: 表示日志文件所在的位置
keepalive_time: 表示长连接时，请求与请求之间的时间间隔
listen: 表示监听的端口
server_name: 表示服务器的IP地址
http: 代表关于http协议的配置

location块配置详解：

语法规则：
location [=|~|~*|^~] /uri/{
	......
}
=：开头表示精确匹配
^~：开头表示uri以某个常规字符串开头，理解为匹配url路径即可
~：开头表示区分大小写的正则匹配
~*：开头表示不区分大小写的正则匹配
/：通用匹配，任何请求都会匹配到

精确匹配：httP://192.168.110.1/1.html  表示直接到 html1 的目录下访问 2.html 文件
location = /2.html {
	root html1;
}

url路径匹配，匹配通过/static访问的路径。本例访问根目录下 http://192.168.110.1/static/2.html，由于/static符合当前的location。所以当前location被匹配，访问的是html2/static/2.html
ls
static
location ^~ /static/ {
	root html2;
}
location / {
	root html;
}

~正则匹配区分大小写，匹配以jpg,png,gif结尾的url，http://192.168.110.1/2.jpg  访问的是 html3/img/2.jpg
location ~ \.(jpg|png|gif)$ {
	root html3/img
}

6、nginx监控

1.使用status监控的步骤

1、确定nginx中的status模块是否已安装

./nginx -V

nginx version: nginx/1.13.7
build by gcc 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC)
configure arguments: --with-http_stub_status_module

如果没有安装status模块，那么使用一下步骤进行安装：
—>找到nginx安装包所存放的位置，nginx安装报的目录是/home/software/nginx-1.13.7
—>执行以下命令

./configure --with-http_stub_status_module
make

2、在nginx.conf中输入以下代码

		location /nginx_status {
		            stub_status on;#让status模块打开
		            access_log off;# 监控状态日志文件关闭
		            allow all;# 权限 
		}

访问 ip:port/nginx_status 进入监控页面

Active connections: 6
server accepts handled requests
 36 36 63
 Reading: 0 Writing: 1 Waiting: 5

Active connections：活跃的连接数，最大连接数受worker_processes和worker_connections两个参数的影响。正常情况下最大的连接数可以为worker_processes * worker_connections，但是如果做了反向代理，那么最大的连接数就是worker_processes * worker_connections / 2

accepts：表示已接受的连接数
handled ：表示已处理的连接数
requests： 表示总共收到的Http请求

Reading： 表示正在读取请求的header的信息
Writing：表示正在响应的请求
Waiting： 表示Writing之后的状态，为等待的意思

2、ngxtop监控

ngxtop是一个日志分析工具

ngxtop语法格式：
Usage:
	ngxtop [optiones]
	ngxtop [optiones] (print|top|avg|sum) <var> ...
	ngxtop info
	ngxtop [optiones] query <query> ...
常见用法：
1.打开默认ngxtop日志文件
ngxtop

2.打开指定的日志文件
ngxtop -l /usr/local/nginx/logs/access.log

3.将错误状态码为404的钱10个请求打印出来
ngxtop top request_path --filter 'status == 404'

4.将发送字节数前10位的排序并显示出来
ngxtop --order-by 'avg(bytes_send) * count'

7、负载均衡/反向代理

反向代理：反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时，用户不需要知道目标服务器的地址，也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速，即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载，提高访问效率。

反向代理好处：
1.提高访问访问速度
由于目标主机返回的数据会存放在代理服务器的硬盘中，因此下一次客户在访问相同站点的数据时，会直接从代理服务器的硬盘中读取，起到了缓存的作用
2. 防火墙的作用
由于所有的客户机请求都必须通过代理服务器访问远程站点，因此可以在代理服务器上设限制，过滤掉某些不安全的信息。

server {
	listen 80;
	server_name localhost;
	location / {
		proxy_pass http://192.168.110.2:8080/;#代理到192.168.110.2:8080
	}
}

1、负载均衡原理

2、如何实现负载均衡

在HTTP上下文中声明一个upstream指令
#ecshop只是一个名称，代号。可以随便写
upstream 上游服务器

upstream ecshop {
	server 192.168.110.1:80;
	server 192.168.110.2:80;
	负载均衡算法的相关参数
}

在server的上下文中声明调用分发的upstream指令
location / {
	proxy_pass http://ecshop
	#ecshop是upstream中的名称，随便写的
}

3、负载均衡的算法

nginx收到客户端的请求后，如何将这个请求分发到我们的后台服务器，这个过程中负载均衡的算法，nginx负载均衡的算法通常有以下几种：

1.轮询
轮询是指请求按照顺序来分发给我们的服务器，默认采用的是轮询的方式

upstream ecshop {
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

2.最少连接数
优先将请求分发给目前连接数最少的服务器

upstream ecshop {
	least_conn;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

3.ip哈希
通过ip hash算法保证同一个连接访问的是同一台服务器

upstream ecshop {
	ip_hash;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

4.通用哈希
通过$request_uri和consistent密钥来计算出我们访问的ip

upstream ecshop {
	hash $request_uri consistent;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

5.最少时间
是指处理请求所花费的最小时间来分发（发送请求到处理的时间），衡量最少时间又有以下三种方式：
header：表示处理完第一个字节的时间
last_byte：表示服务器接受到所有内容的时间
last_byte inflight ：表示如果是一个不完整的请求，服务器接受到所有内容的时间

upstream ecshop {
	least_time header;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

6.随机
将请求随机的发送到服务器，如果使用two，那么应该需要设置两个参数来约束随机

upstream ecshop {
	random;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

upstream ecshop {
	# 按照处理请求所花费的最小时间来随机
	random two least_time=header;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}

4、设置服务器的权重

所谓的权重就是对分发服务器所处理请求的比例来进行约束，使用关键字weight来实现

upstream ecshop {
	server 192.168.110.1:80 weight=5 max_fails=3 fail_timeout=30s;# 5/6
	server 192.168.110.2:80;# 1/6
}
上面的含义表示：如果客户端一共发了6个请求到服务端
192.168.110.1:80这台服务器会处理5个请求。
192.168.110.2:80这台服务器会处理1个请求

5、慢启动

慢启动（晚点启动）是指服务器晚些时间来接受请求，慢启动可以尽量避免服务器被"淹没"

upstream ecshop {
	server 192.168.110.1:80 weight=5  slow_start=30s max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}
一般如果单台服务器会将慢启动与max_fails、fail_timeout两个参数一块使用

6、限制最大连接数

限制最大连接数是指可以对某服务器最大连接数进行约束

upstream ecshop {
	server 192.168.110.1:80 max_conns=10;
	server 192.168.110.2:80;
	queue 100 timeout=70;
}
如果连接超过最大连接数就会排队，所以还可以设置一个排队数以及超时时间
queue：表示队列长度
timeout：表示超时时间
如果在超时时间范围内都没有处理，那就会将错误返回给客户端

7、健康检查

健康检查是指如果分发服务器连接出错，那么就不应该继续给这台服务器分发请求，如果持续分发请求，就可能导致更多的错误，所以会使用max_fails和fail_timeout来约束

upstream ecshop {
	# 按照处理请求所花费的最小时间来随机
	random two least_time=header;
	server 192.168.110.1:80 max_fails=3 fail_timeout=30s;
	server 192.168.110.2:80;
}
max_fails：允许的最多的错误次数。表示达到这么多次失败后，nginx会将这台服务器标为失效的服务器。如果这个选项设置为0，那么表示这台服务器被禁用
fail_timeout：服务器多久可以恢复正常。表示这段时间内不接受客户端的请求。

8、负载均衡高可用

nginx作为负载均衡器，所有的请求都到了nginx，可见nginx处于非常重要的位置。如果nginx服务器宕机，后端的服务器将无法提供服务，后果就很严重
为了屏蔽负载均衡服务器的宕机，就需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送"i am alive"这样的信息来监控对方的运行状况。当把备份机不能在一定时间内收到这样的信息时，备份机就接管主服务器的服务ip，并继续提供负载均衡服务。当备份管理器又从主管理器收到"i am alive"这样的信息时，备份机就释放服务ip地址，这样主服务器就开始再次提供负载均衡服务

8.1、keepalived+nginx实现主备

8.1.1 什么是keepalived

keepalived是集群管理中心保证集群高可用的一个服务软件，用来防止单点故障
keepalived的作用是检测web服务器的状态。如果有一台web服务器死机或者工作出现故障，keepalived将检测到，并将有故障的web服务器从系统中剔除。当web服务器工作正常后keepalived自动的将web服务器加入到服务器组中，这些工作全部自动完成，不需要人工干涉，需要的仅仅是人工修复出现故障的web服务器。

8.1.2 keepalived的工作原理

keepalived是以VRRP协议为实现基础的，VRRP协议全称Virtual Router Redundancy Protocol，即虚拟路由冗余协议
虚拟路由冗余协议，可以认为是实现路由器高可用的协议。即将n台提供相同功能的路由器组成一个路由器组，这些组里有一个master和多个backup。master上游一个对外提供服务的vip（该路由器所在局域网内其他机器的默认路由为该vip），master会发组播，当backup收不到VRRP包时，就认为master宕机了。这时就需要根据VRRP的优先级来选举一个backup当master。这样就可以保证路由器的高可用了。
keepalived主要有三个模块。分别是：core、check和VRRP。core模块为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查，包括常见的各种检查方式。VRRP模块是来实现VRRP协议的。

8.1.3 keepalived+nginx的过程

1、初始状态

2、安装环境

su -root
yum -y install kernel-devel*
yum -y install opemssl-*
yum -y install popt-devel
yum -y install lrzsz
yum -y install openssh-clients
yum -y install libnl libnl-devel popt

3、安装keepalived
将keepalived-1.2.15.tar.gz上传到服务器/usr/local下

cd usr/local
tar -zxvf keepalived-1.2.15.tar.gz
cd keepalived-1.2.15

执行配置命令

./configure --prefix=/usr/local/keepalived

编译

make

安装

make install

到此安装成功。拷贝执行文件

cp /usr/local/keepalived/sbin/keepalived /usr/sbin

将init.d文件拷贝到etc下，加入开机启动项。

cp /usr/local/keepalived/etc/rc.d/init.d/keepalived  /etc/init.d/keepalived

将keepalived文件拷贝到etc下，加入网卡配置

cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

创建keepalived文件夹

mkdir -p /etc/keepalived

将keepalived配置文件拷贝到etc下

cp /usr/local/keepalived/etc/keepalived/keepalived.conf  /etc/keepalived/keepalived.conf

添加可执行权限

chomd +x /etc/init.d/keepalived

加入开机启动

chkconfig --add keepalived  #添加时必须保证/etc/init.d/keepalived存在
chkconfig keepalived on

添加完可查询系统服务是否存在：

chkconfig --list

启动keepalived

启动：service keepalived start
停止：service keepalived stop
重启：service keepalived restart

3、配置keepalived

主nginx配置
修改nginx下/etc/keepalived/keepalived.conf文件

!Configuration File for keepalived

#全局配置
global_defs{
	notification_email { # 指定keepalived在发生切换时需要发送email到的对象，一行一个
		xxx@xxx.com
	}
	notification_email_from xxx@xxx.com #指定发件人
	#smtp_server xxx.smtp.com  #指定smtp服务器地址
	#smtp_connect_time_out  #指定smtp连接超时时间 
	router_id LVS_DEVEL  #指定运行keepalived机器的一个标识
}

vrrp_instance Vl_1 {
	state MASTER #标示状态为MASTER 备份机为BACKUP
	interface eth0 #设置实例绑定的网卡
	virtual_router_id 51 #同一实例下，virtual_router_id 必须相同
	priority 100 #MASTER权重高于BACKUP，比如BACKUP为99
	advent_int 1 #MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
	authentication { #设置认证
		auth_type PASS #主从服务器验证方式
		auth_pass 8888
	}
	virtual_ipaddress { #设置vip
		192.168.110.1 #可以多个虚拟ip，换行即可
	}
}

测试

主备nginx都启动keepalived及nginx.
service keepalived start
./nginx

初识状态
查看主nginx的eth0设置
vip绑定到主nginx的eth0上
/sbin/ip addr show eth0

查看备nginx的eth0设置
vip没有绑定到主nginx的eth0上
/sbin/ip addr show eth0

访问192.168.110.1  可以访问

解决nginx进程和keepalived不同时存在的问题

keepalived是通过检测keepalived进程是否存在来判断服务器是否宕机。如果keepalived进程在但是nginx进程不在了，那么keepalived是不会做主备切换的。所以需要写一个脚本来监控nginx进程是否存在，当nginx进程不存在了就将keepalived进程杀掉

进程检测脚本。
在主nginx上需要编写nginx进程检测脚本（check_nginx.sh），判断nainx进程是否存在。如果nginx进程不存在，就将keepalived进程杀掉

#!/bin/bash
# 如果进程中没有nginx则将keepalived进程kill掉
A=`ps -C nginx --no-header |wc-|`  ##  查看是否有nginx进程，把值赋给变量A
if [ $A -eq 0 ];then ##  如果没有进程 值为 0
	service keepalived stop ##  则结束keepalived 进程
fi

#!/bin/bash
A=`ps -C nginx --no-header |wc-|`
if [ $A -eq 0 ];then
service keepalived stop
fi

将check_nginx.sh拷贝纸/etc/keepalived下，脚本测试。将nginx停止，将keepalived启动，执行脚本

sh /etc/keepalived/check_nginx.sh

查看执行结果就可以看到自动将keepalived进程kill掉了
修改keepalived主nginx的配置

!Configuration File for keepalived

#全局配置
global_defs{
	notification_email { # 指定keepalived在发生切换时需要发送email到的对象，一行一个
		xxx@xxx.com
	}
	notification_email_from xxx@xxx.com #指定发件人
	#smtp_server xxx.smtp.com  #指定smtp服务器地址
	#smtp_connect_time_out  #指定smtp连接超时时间 
	router_id LVS_DEVEL  #指定运行keepalived机器的一个标识
}
vrrp_script check_nginx {
	script "/etc/keepalived/check_nginx.sh" ##监控脚本
	interval 2 ##时间间隔 2 秒
	weight 2 ##权重
}
vrrp_instance Vl_1 {
	state MASTER #标示状态为MASTER 备份机为BACKUP
	interface eth0 #设置实例绑定的网卡
	virtual_router_id 51 #同一实例下，virtual_router_id 必须相同
	priority 100 #MASTER权重高于BACKUP，比如BACKUP为99
	advent_int 1 #MASTER与BACKUP负载均衡器之间同步检查的时间间隔，单位是秒
	authentication { #设置认证
		auth_type PASS #主从服务器验证方式
		auth_pass 8888
	}
	virtual_ipaddress { #设置vip
		192.168.110.1 #可以多个虚拟ip，换行即可
	}
	track_script {
		check_nginx   ## 监控脚本
	}
}

9、nginx压缩与解压

压缩是对请求进行压缩，来减小请求的字节数
所有关于压缩的相关参数，主要是写在http的上下文中

开启压缩
gzip on;

压缩的文件类型或者对什么文件类型进行压缩，多个用空格隔开。在请求头的content-type中
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

多大的文件开始压缩
下面的设置表示，超过100个字节的文件进行压缩
gzip_min_length 100;# 单位是字节数

如果使用了反向代理，希望对反向代理的文件进行压缩，那么可以使用以下命令：
	gzip_proxied 参数：
	常见参数：
	off：表示关闭所有的代理结果数据压缩
	expired：表示如果header中包含“Expires”头信息，启用压缩
	no-cache：表示如果header中包含“Cache-Control:no-cache”头信息，启用压缩
	no-store：表示如果header中包含“Cache-Control:no-store”头信息，启用压缩
	private：表示如果header中包含“Cache-Control:private”头信息，启用压缩
	no-last-modified：表示如果header中包含“Last_Modified”头信息，启用压缩
	no-etag：表示如果header中包含“Etag”头信息，启用压缩
	auth：表示如果header中包含“Authorization”头信息，启用压缩
	any：表示无条件压缩所有结果数据

对http协议的什么版本进行压缩
gzip_http_version 1.0|1.1;

表示客户端进行解压
guzip on;

发送压缩静态文件，表示对静态文件也进行压缩
gzip_static on;

10、nginx的rewrite

语法

server {
	rewrite 规则 定向路径 重写类型
}
规则：可以是字符串或者正则来表达想匹配的url
定向路径：表示匹配到规则后要定向的路径，如果规则里有正则，则可以使用$index来表示正则里的捕获分组
重写类型：
	last：表示完成rewrite，浏览器地址栏url不变
	break：本条规则匹配完成后，终止匹配。不在匹配后面的规则，浏览器地址栏url地址不变
	redirect：返回302临时重定向，浏览器地址会显示跳转后的url地址
	permanent：返回301永久重定向，浏览器地址栏会显示跳转后的url地址

例子：

server {
	# 访问/break.html的时候，压面内容重写到/index.html中，并终止后续的匹配
	rewrite /break.html /index.html break
	
	#访问/permanent.html的时候，页面直接301重定向到/index.html中
	rewrite /permanent.html /index.html permanent
}

last和break的区别

last一般写在server和if中，而break一般使用在location中
last不终止重写后的url匹配，即新的url会再从server走一遍匹配流程，而break终止重写后的匹配
在location里一旦返回break则直接生效，并停止后续的匹配location
server {
	location / {
		rewrite /last/ /q.html last;
		rewrite /break/ q.html break;
	}
	location = /q.html {
		return 400;
	}
}
访问/last/时重写到了/q.html，然后使用新的uri再匹配，正好匹配到location = /q.html，然后返回400
访问/break/时重写到/q.html，由于返回了break，则直接停止了

if判断
需要判断当文件不存在时、当路径包含xx时等条件，则需要用到if

if (表达式) {
}
当表达式知识一个变量时，如果值为空或任何以0开头的字符串都会当成false
直接比较变量和内容时，使用=或者!=
~正则表达式匹配，~*不区分大小写的匹配，!~区分大小写的匹配

一些内置的条件判断
	-f和!-f用来判断是否存在文件
	-d和!-d用来判断是否存在目录
	-e和!-e用来判断是否存在文件或目录
	-x和!-x用来判断文件是否可以执行

内置的全局变量
	$args:这个变量等于请求行中的参数，同$query_string
	$content_length:请求头中的Content-length字段
	$content_type:请求头中的Content-type字段
	$document_root:当前请求在root指令中指定的值
	$host:请求主机头字段，否则为服务器名称
	$http_user_agent:客户端agent信息
	$http_cookie:客户端cookie信息
	$limit_rate:这个变量可以限制连接速率
	$request_method:客户端请求的动作，通常为GET或POST
	$remote_addr:客户端的ip地址
	$remote_port:客户端的端口
	$remote_user:已经经过Auth Basic Module验证的用户名
	$request_filename:当前请求的文件路径，由root或alias指令与URI请求生成
	$schme:HTTP方法（如http，https）
	$server_protocol:请求使用的协议，通常是http/1.0 或 http/1.1
	$server_addr:服务器地址，在完成一次系统调用后可以确定这个值
	$server_name:服务器名称
	$server_port:请求到达服务器的端口
	$request_uri:包含请求参数的原始URI，不包含主机名，如"、foo/bar.php?arg=baz"
	$uri:不带请求参数的当前URI，$uri不包含主机名，如"/foo/bar.html"
	$document_uri:与$uri相同

示例
如果请求类型不是GET  返回405
if ($request_method = "GET"){
	return 405;
}