Nginx访问控制与参数调优

Nginx全局变量

Nginx中有不少的全局变量，能够经过$变量名来使用。下面列举一些经常使用的全局变量：

变量	说明
$args	请求中的参数，如www.123.com/1.php?a=1&b=2的$args就是a=1&b=2
$content_length	HTTP请求信息里的”Content-Length”
$conten_type	HTTP请求信息里的”Content-Type”
$document_root	nginx虚拟主机配置文件中的root参数对应的值
$document_uri	当前请求中不包含指令的URI，如www.123.com/1.php?a=1&b=2的$document_uri就是1.php,不包含后面的参数
$host	主机头，也就是域名
$http_user_agent	客户端的详细信息，也就是浏览器的标识，用curl -A能够指定
$http_cookie	客户端的cookie信息
$limit_rate	若是nginx服务器使用limit_rate配置了显示网络速率，则会显示，若是没有设置， 则显示0
$remote_addr	客户端的公网ip
$remote_port	客户端的port
$remote_user	若是nginx有配置认证，该变量表明客户端认证的用户名
$request_body_file	作反向代理时发给后端服务器的本地资源的名称
$request_method	请求资源的方式，GET/PUT/DELETE等
$request_filename	当前请求的资源文件的路径名称，至关因而$document_root/$document_uri的组合
$request_uri	请求的连接，包括$document_uri和$args
$scheme	请求的协议，如ftp,http,https
$server_protocol	客户端请求资源使用的协议的版本，如HTTP/1.0，HTTP/1.1，HTTP/2.0等
$server_addr	服务器IP地址
$server_name	服务器的主机名
$server_port	服务器的端口号
$uri	和$document_uri相同
$http_referer	客户端请求时的referer，通俗讲就是该请求是经过哪一个连接跳过来的，用curl -e能够指定

Nginx location

location做用

location指令的做用是根据用户请求的URI来执行不一样的应用。即根据用户请求的网站地址URL进行匹配，匹配成功就进行相应的操做。

语法

location的语法规则：location [=|~|~*|^~] /uri/ { … }
location匹配的变量是$uri
关于几种字符的说明

字符	描述
=	表示精准匹配
~	表示区分大小写的正则匹配
~*	表示不区分大小写的正则匹配
^~	表示uri以指定字符或字符串开头
/	通用匹配，任何请求都会匹配到

规则优先级

= 高于 ^~ 高于 ~* 等于 ~ 高于 /

示例1

location = "/12.jpg" { ... }
如：
www.syushin.com/12.jpg 匹配
www.syushin.com/abc/12.jpg 不匹配

location ^~ "/abc/" { ... }
如：
www.syushin.com/abc/123.html 匹配
www.syushin.com/a/abc/123.jpg 不匹配

location ~ "png" { ... }
如：
www.syushin.com/aaa/bbb/ccc/123.png 匹配
www.syushin.com/aaa/png/123.html 匹配

location ~* "png" { ... }
如：
www.syushin.com/aaa/bbb/ccc/123.PNG 匹配
www.syushin.com/aaa/png/123.html 匹配


location /admin/ { ... }
如：
www.syushin.com/admin/aaa/1.php 匹配
www.syushin.com/123/admin/1.php 不匹配

注意：
有些资料上介绍location支持不匹配 !~如： location !~ 'png'{ ... }
这是错误的，location不支持 !~
若是有这样的需求，能够经过if(location优先级小于if )来实现，如： if ($uri !~ 'png') { ... }

访问控制

web2.0时代，不少网站都是以用户为中心，网站容许用户发布内容到服务器。因为为用户开放了上传功能，所以有很大的安全风险，好比黑客上传木马程序等等。所以，访问控制就颇有必要配置了。

deny与allow

字面上很容易理解就是拒绝和容许。
Nginx的deny和allow指令是由ngx_http_access_module模块提供，Nginx安装默认内置了该模块。

语法
语法：allow/deny address | CIDR | unix: | all

它表示，容许/拒绝某个ip或者一个ip段访问.若是指定unix:,那将容许socket的访问。
注意：unix在1.5.1中新加入的功能。
在nginx中，allow和deny的规则是按顺序执行的。

示例1：

location /
{
    allow 192.168.0.0/24;
    allow 127.0.0.1;
    deny all;
}

说明：这段配置值容许192.168.0.0/24网段和127.0.0.1的请求，其余来源IP所有拒绝。

示例2：

location ~ "admin"
{
    allow 192.168.30.7;
    deny all
}

说明：访问的uri中包含admin的请求，只容许192.168.30.7这个IP的请求。

基于location的访问控制

平常上，访问控制基本是配合location来作配置的，直接例子吧。
示例1：

location /blog/
{
    deny all;
}

说明：针对/blog/目录，所有禁止访问，这里的deny all;能够改成return 403;.
示例2

location ~ ".bak|\.ht"
{
    return 403;
}

说明：访问的uri中包含.bak字样的或者包含.ht的直接返回403状态码。

测试连接举例：

• www.syushin.com/abc.bak
• www.syushin.com/blog/123/.htalskdjf

若是用户输入的URL是上面其中之一都会返回403。
示例3

location ~ (data|cache|tmp|image|attachment).*\.php$
{
    deny all;
}

说明：请求的uri中包含data、cache、tmp、image、attachment而且以.php结尾的，所有禁止访问。

测试连接举例：

• www.xxxxxx.com/aming/cache/1.php
• www.xxxxxxx.com/image/123.phps
• www.xxxxxx.com/aming/datas/1.php

基于$document_uri的访问控制

前面介绍了内置变量$document_uri含义是当前请求中不包含指令的URI。
如www.123.com/1.php?a=1&b=2的$document_uri就是1.php,不包含后面的参数。
咱们能够针对这个变量作访问控制。
示例1

if ($document_uri ~ "/admin/")
{
    return 403;
}

说明：当请求的uri中包含/admin/时，直接返回403.

注意：if结构中不支持使用allow和deny。

测试连接：

1. www.xxxxx.com/123/admin/1.html 匹配
2. www.xxxxx.com/admin123/1.html  不匹配
3. www.xxxxx.com/admin.php  不匹配

示例2

if ($document_uri = /admin.php)
{
    return 403;
}

说明：请求的uri为/admin.php时返回403状态码。

测试连接：

1. www.xxxxx.com/admin.php # 匹配
2. www.xxxxx.com/123/admin.php # 不匹配

示例3

if ($document_uri ~ '/data/|/cache/.*\.php$')
{
    return 403;
}

说明：请求的uri包含data或者cache目录，而且是php时，返回403状态码。

测试连接：

1. www.xxxxx.com/data/123.php  # 匹配
2. www.xxxxx.com/cache1/123.php # 不匹配

基于$request_uri访问控制

$request_uri比$docuemnt_uri多了请求的参数。主要是针对请求的uri中的参数进行控制。
示例

if ($request_uri ~ "gid=\d{9,12}")
{
    return 403;
}

说明：\d{9,12}是正则表达式，表示9到12个数字，例如gid=1234567890就符号要求。

测试连接：

1. www.xxxxx.com/index.php?gid=1234567890&pid=111  匹配
2. www.xxxxx.com/gid=123  不匹配

背景知识：
曾经有一个客户的网站cc攻击，对方发起太多相似这样的请求：/read-123405150-1-1.html
实际上，这样的请求并非正常的请求，网站会抛出一个页面，提示帖子不存在。
因此，能够直接针对这样的请求，return 403状态码。

基于$http_user_agent的访问控制(反爬虫)

user_agent能够简单理解成浏览器标识，包括一些蜘蛛爬虫均可以经过user_agent来辨识。假如观察访问日志，发现一些搜索引擎的蜘蛛对网站访问特别频繁，它们并不友好。为了减小服务器的压力，其实能够把除主流搜索引擎蜘蛛外的其余蜘蛛爬虫所有封掉。
示例

if ($user_agent ~ 'YisouSpider|MJ12bot/v1.4.2|YoudaoBot|Tomato')
{
    return 403;
}

说明：user_agent包含以上关键词的请求，所有返回403状态码。

测试：

1. curl -A "123YisouSpider1.0"
2. curl -A "MJ12bot/v1.4.1"

基于$http_referer的访问控制

$http_referer除了能够实现防盗链的功能外，还能够作一些特殊的需求。
好比：

网站被黑挂马，搜索引擎收录的网页是有问题的，当经过搜索引擎点击到网站时，却显示一个博彩网站。
因为查找木马须要时间，不能立刻解决，为了避免影响用户体验，能够针对此类请求作一个特殊操做。
好比，能够把从百度访问的连接直接返回404状态码，或者返回一段html代码。

示例

if ($http_referer ~ 'baidu.com')
{
    return 404;
}

或者

if ($http_referer ~ 'baidu.com')
{
    return 200 "<html><script>window.location.href='//$host$request_uri';</script></html>";
}

Nginx参数优化

Nginx做为高性能web服务器，即便不特地调整配置参数也能够处理大量的并发请求。固然，配置调优会使Nginx性能更增强悍，配置参数须要结合服务器硬件性能等作参考。

worker进程优化

worker_processes num;

该参数表示启动几个工做进程，建议和本机CPU核数保持一致，每一核CPU处理一个进程，num表示数字。

worker_rlimit_nofile

它表示Nginx最大可用的文件描述符个数，须要配合系统的最大描述符，建议设置为102400。
还须要在系统里执行ulimit -n 102400才能够。
也能够直接修改配置文件/etc/security/limits.conf修改
增长：
#* soft nofile 655350 (去掉前面的#)
#* hard nofile 655350 (去掉前面的#)

worker_connections

该参数用来配置每一个Nginx worker进程最大处理的链接数,
这个参数也决定了该Nginx服务器最多能处理多少客户端请求（worker_processes * worker_connections)
建议把该参数设置为10240，不建议太大。

http/tcp链接数优化

use epoll

使用epoll模式的事件驱动模型，该模型为Linux系统下最优方式。

multi_accept on

使每一个worker进程能够同时处理多个客户端请求。

sendfile on

使用内核的FD文件传输功能，能够减小user mode和kernel mode的切换，从而提高服务器性能。

tcp_nopush on

当tcp_nopush设置为on时，会调用tcp_cork方法进行数据传输。
使用该方法会产生这样的效果：当应用程序产生数据时，
内核不会立马封装包，而是当数据量积累到必定量时才会封装，而后传输。

tcp_nodelay on

不缓存data-sends（关闭 Nagle 算法），这个可以提升高频发送小数据报文的实时性。

(关于Nagle算法)

【假如须要频繁的发送一些小包数据，好比说1个字节，以IPv4为例的话，则每一个包都要附带40字节的头，
也就是说，总计41个字节的数据里，其中只有1个字节是咱们须要的数据。
为了解决这个问题，出现了Nagle算法。
它规定：若是包的大小知足MSS，那么能够当即发送，不然数据会被放到缓冲区，等到已经发送的包被确认了以后才能继续发送。
经过这样的规定，能够下降网络里小包的数量，从而提高网络性能。

keepalive_timeout

定义长链接的超时时间，建议30s，过短或者太长都不必定合适，固然，最好是根据业务自身的状况来动态地调整该参数。

keepalive_requests

定义当客户端和服务端处于长链接的状况下，每一个客户端最多能够请求多少次，能够设置很大，好比50000.

reset_timeout_connection on

设置为on的话，当客户端再也不向服务端发送请求时，容许服务端关闭该链接。

client_body_timeout

客户端若是在该指定时间内没有加载完body数据，则断开链接，单位是秒，默认60，能够设置为10。

send_timeout

这个超时时间是发送响应的超时时间，即Nginx服务器向客户端发送了数据包，但客户端一直没有去接收这个数据包。
若是某个链接超过send_timeout定义的超时时间，那么Nginx将会关闭这个链接。单位是秒，能够设置为3。

压缩

对于纯文本的内容，Nginx是可使用gzip压缩的。使用压缩技术能够减小对带宽的消耗。
由ngx_http_gzip_module模块支持

配置以下：

gzip on; //开启gzip功能
gzip_min_length 1024; //设置请求资源超过该数值才进行压缩，单位字节
gzip_buffers 16 8k; //设置压缩使用的buffer大小，第一个数字为数量，第二个为每一个buffer的大小
gzip_comp_level 6; //设置压缩级别，范围1-9,9压缩级别最高，也最耗费CPU资源
gzip_types text/plain application/x-javascript text/css application/xml image/jpeg image/gif image/png; //指定哪些类型的文件须要压缩
gzip_disable "MSIE 6\."; //IE6浏览器不启用压缩

测试：

curl -I -H "Accept-Encoding: gzip, deflate" http://www.xxxxx.com/1.css

日志

• 错误日志级别调高，好比crit级别，尽可能少记录可有可无的日志。
• 对于访问日志，若是不要求记录日志，能够关闭，
• 静态资源的访问日志关闭

静态文件过时

对于静态文件，须要设置一个过时时间，这样可让这些资源缓存到客户端浏览器，
在缓存未失效前，客户端再也不向服务期请求相同的资源，从而节省带宽和资源消耗。

配置示例以下：

location ~* ^.+\.(gif|jpg|png|css|js)$                                      
{
    expires 1d; //1d表示1天，也能够用24h表示一天。
}

访问控制和参数调优只记录其中一些部分，有些可能会在工做中用到，SSL的配置后续再做笔记吧，春招笔试好难呀，努力学习吧...