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可以指定
Nginxlocation
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/denyaddress|CIDR|unix:|all
它表示，允许/拒绝某个ip或者一个ip段访问.如果指定unix:,那将允许socket的访问。
注意：unix在1.5.1中新加入的功能。
在nginx中，allow和deny的规则是按顺序执行的。
示例1：
location/
{
allow192.168.0.0/24;
allow127.0.0.1;
denyall;
}
说明：这段配置值允许192.168.0.0/24网段和127.0.0.1的请求，其他来源IP全部拒绝。
示例2：
location~"admin"
{
allow192.168.30.7;
denyall
}
说明：访问的uri中包含admin的请求，只允许192.168.30.7这个IP的请求。
基于location的访问控制
日常上，访问控制基本是配合location来做配置的，直接例子吧。
示例1：
location/blog/
{
denyall;
}
说明：针对/blog/目录，全部禁止访问，这里的denyall;可以改为return403;.
示例2
location~".bak|\.ht"
{
return403;
}
说明：访问的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$
{
denyall;
}
说明：请求的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/")
{
return403;
}
说明：当请求的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)
{
return403;
}
说明：请求的uri为/admin.php时返回403状态码。
测试链接：
1.www.xxxxx.com/admin.php#匹配
2.www.xxxxx.com/123/admin.php#不匹配
示例3
if($document_uri~'/data/|/cache/.*\.php$')
{
return403;
}
说明：请求的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}")
{
return403;
}
说明：\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
实际上，这样的请求并不是正常的请求，网站会抛出一个页面，提示帖子不存在。
所以，可以直接针对这样的请求，return403状态码。
基于$http_user_agent的访问控制(反爬虫)
user_agent可以简单理解成浏览器标识，包括一些蜘蛛爬虫都可以通过user_agent来辨识。假如观察访问日志，发现一些搜索引擎的蜘蛛对网站访问特别频繁，它们并不友好。为了减少服务器的压力，其实可以把除主流搜索引擎蜘蛛外的其他蜘蛛爬虫全部封掉。
示例
if($user_agent~'YisouSpider|MJ12bot/v1.4.2|YoudaoBot|Tomato')
{
return403;
}
说明：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')
{
return404;
}
或者
if($http_referer~'baidu.com')
{
return200"";
}
Nginx参数优化
Nginx作为高性能web服务器，即使不特意调整配置参数也可以处理大量的并发请求。当然，配置调优会使Nginx性能更加强悍，配置参数需要结合服务器硬件性能等做参考。
worker进程优化
worker_processesnum;
该参数表示启动几个工作进程，建议和本机CPU核数保持一致，每一核CPU处理一个进程，num表示数字。
worker_rlimit_nofile
它表示Nginx最大可用的文件描述符个数，需要配合系统的最大描述符，建议设置为102400。
还需要在系统里执行ulimit-n102400才可以。
也可以直接修改配置文件/etc/security/limits.conf修改
增加：
#*softnofile655350(去掉前面的#)
#*hardnofile655350(去掉前面的#)
worker_connections
该参数用来配置每个Nginxworker进程最大处理的连接数,
这个参数也决定了该Nginx服务器最多能处理多少客户端请求（worker_processes*worker_connections)
建议把该参数设置为10240，不建议太大。
http/tcp连接数优化
useepoll
使用epoll模式的事件驱动模型，该模型为Linux系统下最优方式。
multi_accepton
使每个worker进程可以同时处理多个客户端请求。
sendfileon
使用内核的FD文件传输功能，可以减少usermode和kernelmode的切换，从而提升服务器性能。
tcp_nopushon
当tcp_nopush设置为on时，会调用tcp_cork方法进行数据传输。
使用该方法会产生这样的效果：当应用程序产生数据时，
内核不会立马封装包，而是当数据量积累到一定量时才会封装，然后传输。
tcp_nodelayon
不缓存data-sends（关闭Nagle算法），这个能够提高高频发送小数据报文的实时性。
(关于Nagle算法)
【假如需要频繁的发送一些小包数据，比如说1个字节，以IPv4为例的话，则每个包都要附带40字节的头，
也就是说，总计41个字节的数据里，其中只有1个字节是我们需要的数据。
为了解决这个问题，出现了Nagle算法。
它规定：如果包的大小满足MSS，那么可以立即发送，否则数据会被放到缓冲区，等到已经发送的包被确认了之后才能继续发送。
通过这样的规定，可以降低网络里小包的数量，从而提升网络性能。
keepalive_timeout
定义长连接的超时时间，建议30s，太短或者太长都不一定合适，当然，最好是根据业务自身的情况来动态地调整该参数。
keepalive_requests
定义当客户端和服务端处于长连接的情况下，每个客户端最多可以请求多少次，可以设置很大，比如50000.
reset_timeout_connectionon
设置为on的话，当客户端不再向服务端发送请求时，允许服务端关闭该连接。
client_body_timeout
客户端如果在该指定时间内没有加载完body数据，则断开连接，单位是秒，默认60，可以设置为10。
send_timeout
这个超时时间是发送响应的超时时间，即Nginx服务器向客户端发送了数据包，但客户端一直没有去接收这个数据包。
如果某个连接超过send_timeout定义的超时时间，那么Nginx将会关闭这个连接。单位是秒，可以设置为3。
压缩
对于纯文本的内容，Nginx是可以使用gzip压缩的。使用压缩技术可以减少对带宽的消耗。
由ngx_http_gzip_module模块支持
配置如下：
gzipon;//开启gzip功能 gzip_min_length1024;//设置请求资源超过该数值才进行压缩，单位字节 gzip_buffers168k;//设置压缩使用的buffer大小，第一个数字为数量，第二个为每个buffer的大小 gzip_comp_level6;//设置压缩级别，范围1-9,9压缩级别最高，也最耗费CPU资源 gzip_typestext/plainapplication/x-javascripttext/cssapplication/xmlimage/jpegimage/gifimage/png;//指定哪些类型的文件需要压缩 gzip_disable"MSIE6\.";//IE6浏览器不启用压缩
测试：
curl-I-H"Accept-Encoding:gzip,deflate"http://www.xxxxx.com/1.css
日志
- 错误日志级别调高，比如crit级别，尽量少记录无关紧要的日志。
- 对于访问日志，如果不要求记录日志，可以关闭，
- 静态资源的访问日志关闭
静态文件过期
对于静态文件，需要设置一个过期时间，这样可以让这些资源缓存到客户端浏览器，
在缓存未失效前，客户端不再向服务期请求相同的资源，从而节省带宽和资源消耗。
配置示例如下：
location~*^.+\.(gif|jpg|png|css|js)$
{
expires1d;//1d表示1天，也可以用24h表示一天。
}
访问控制和参数调优只记录其中一些部分，有些可能会在工作中用到，SSL的配置后续再作笔记吧，春招笔试好难呀，努力学习吧...
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：czq8825#qq.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。