小編給大家分享一下Nginx如何實現(xiàn)訪問控制與參數(shù)調(diào)優(yōu),相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比澤庫網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式澤庫網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們,業(yè)務(wù)覆蓋澤庫地區(qū)。費用合理售后完善,十余年實體公司更值得信賴。Nginx全局變量
Nginx中有很多的全局變量,可以通過$變量名來使用。下面列舉一些常用的全局變量:
變量 | 說明 |
---|---|
$args | 請求中的參數(shù),如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參數(shù)對應(yīng)的值 |
$document_uri | 當(dāng)前請求中不包含指令的URI,如www.123.com/1.php?a=1&b=2的$document_uri就是1.php,不包含后面的參數(shù) |
$host | 主機頭,也就是域名 |
$http_user_agent | 客戶端的詳細(xì)信息,也就是瀏覽器的標(biāo)識,用curl -A可以指定 |
$http_cookie | 客戶端的cookie信息 |
$limit_rate | 如果nginx服務(wù)器使用limit_rate配置了顯示網(wǎng)絡(luò)速率,則會顯示,如果沒有設(shè)置, 則顯示0 |
$remote_addr | 客戶端的公網(wǎng)ip |
$remote_port | 客戶端的port |
$remote_user | 如果nginx有配置認(rèn)證,該變量代表客戶端認(rèn)證的用戶名 |
$request_body_file | 做反向代理時發(fā)給后端服務(wù)器的本地資源的名稱 |
$request_method | 請求資源的方式,GET/PUT/DELETE等 |
$request_filename | 當(dāng)前請求的資源文件的路徑名稱,相當(dāng)于是$document_root/$document_uri的組合 |
$request_uri | 請求的鏈接,包括$document_uri和$args |
$scheme | 請求的協(xié)議,如ftp,http,https |
$server_protocol | 客戶端請求資源使用的協(xié)議的版本,如HTTP/1.0,HTTP/1.1,HTTP/2.0等 |
$server_addr | 服務(wù)器IP地址 |
$server_name | 服務(wù)器的主機名 |
$server_port | 服務(wù)器的端口號 |
$uri | 和$document_uri相同 |
$http_referer | 客戶端請求時的referer,通俗講就是該請求是通過哪個鏈接跳過來的,用curl -e可以指定 |
Nginx location
location作用
location指令的作用是根據(jù)用戶請求的URI來執(zhí)行不同的應(yīng)用。即根據(jù)用戶請求的網(wǎng)站地址URL進行匹配,匹配成功就進行相應(yīng)的操作。
語法
location的語法規(guī)則:location [=|~|~*|^~] /uri/ { … }
location匹配的變量是$uri
關(guān)于幾種字符的說明
字符 | 描述 |
---|---|
= | 表示精準(zhǔn)匹配 |
~ | 表示區(qū)分大小寫的正則匹配 |
~* | 表示不區(qū)分大小寫的正則匹配 |
^~ | 表示uri以指定字符或字符串開頭 |
/ | 通用匹配,任何請求都會匹配到 |
規(guī)則優(yōu)先級
= 高于 ^~ 高于 ~* 等于 ~ 高于 /
示例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優(yōu)先級小于if )來實現(xiàn),如: if ($uri !~ 'png') { ... }
訪問控制
web2.0時代,很多網(wǎng)站都是以用戶為中心,網(wǎng)站允許用戶發(fā)布內(nèi)容到服務(wù)器。由于為用戶開放了上傳功能,因此有很大的安全風(fēng)險,比如黑客上傳木馬程序等等。因此,訪問控制就很有必要配置了。
deny與allow
字面上很容易理解就是拒絕和允許。
Nginx的deny和allow指令是由ngx_http_access_module模塊提供,Nginx安裝默認(rèn)內(nèi)置了該模塊。
語法
語法:allow/deny address | CIDR | unix: | all
它表示,允許/拒絕某個ip或者一個ip段訪問.如果指定unix:,那將允許socket的訪問。
注意:unix在1.5.1中新加入的功能。
在nginx中,allow和deny的規(guī)則是按順序執(zhí)行的。
示例1:
location / { allow 192.168.0.0/24; allow 127.0.0.1; deny all; }
說明:這段配置值允許192.168.0.0/24網(wǎng)段和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狀態(tài)碼。
測試鏈接舉例:
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結(jié)尾的,全部禁止訪問。
測試鏈接舉例:
www.xxxxxx.com/aming/cache/1.php
www.xxxxxxx.com/image/123.phps
www.xxxxxx.com/aming/datas/1.php
基于$document_uri的訪問控制
前面介紹了內(nèi)置變量$document_uri含義是當(dāng)前請求中不包含指令的URI。
如www.123.com/1.php?a=1&b=2的$document_uri就是1.php,不包含后面的參數(shù)。
我們可以針對這個變量做訪問控制。
示例1
if ($document_uri ~ "/admin/") { return 403; }
說明:當(dāng)請求的uri中包含/admin/時,直接返回403.
注意:if結(jié)構(gòu)中不支持使用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狀態(tài)碼。
測試鏈接:
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狀態(tài)碼。
測試鏈接:
1. www.xxxxx.com/data/123.php # 匹配
2. www.xxxxx.com/cache1/123.php # 不匹配
基于$request_uri訪問控制
$request_uri比$docuemnt_uri多了請求的參數(shù)。主要是針對請求的uri中的參數(shù)進行控制。
示例
if ($request_uri ~ "gid=\d{9,12}") { return 403; }
說明:\d{9,12}是正則表達式,表示9到12個數(shù)字,例如gid=1234567890就符號要求。
測試鏈接:
1. www.xxxxx.com/index.php?gid=1234567890&pid=111 匹配
2. www.xxxxx.com/gid=123 不匹配
背景知識:
曾經(jīng)有一個客戶的網(wǎng)站cc攻擊,對方發(fā)起太多類似這樣的請求:/read-123405150-1-1.html
實際上,這樣的請求并不是正常的請求,網(wǎng)站會拋出一個頁面,提示帖子不存在。
所以,可以直接針對這樣的請求,return 403狀態(tài)碼。
基于$http_user_agent的訪問控制(反爬蟲)
user_agent可以簡單理解成瀏覽器標(biāo)識,包括一些蜘蛛爬蟲都可以通過user_agent來辨識。假如觀察訪問日志,發(fā)現(xiàn)一些搜索引擎的蜘蛛對網(wǎng)站訪問特別頻繁,它們并不友好。為了減少服務(wù)器的壓力,其實可以把除主流搜索引擎蜘蛛外的其他蜘蛛爬蟲全部封掉。
示例
if ($user_agent ~ 'YisouSpider|MJ12bot/v1.4.2|YoudaoBot|Tomato') { return 403; }
說明:user_agent包含以上關(guān)鍵詞的請求,全部返回403狀態(tài)碼。
測試:
1. curl -A "123YisouSpider1.0"
2. curl -A "MJ12bot/v1.4.1"
基于$http_referer的訪問控制
$http_referer除了可以實現(xiàn)防盜鏈的功能外,還可以做一些特殊的需求。
比如:
網(wǎng)站被黑掛馬,搜索引擎收錄的網(wǎng)頁是有問題的,當(dāng)通過搜索引擎點擊到網(wǎng)站時,卻顯示一個bocai網(wǎng)站。
由于查找木馬需要時間,不能馬上解決,為了不影響用戶體驗,可以針對此類請求做一個特殊操作。
比如,可以把從百度訪問的鏈接直接返回404狀態(tài)碼,或者返回一段html代碼。
示例
if ($http_referer ~ 'baidu.com') { return 404; }
或者
if ($http_referer ~ 'baidu.com') { return 200 ""; }
Nginx參數(shù)優(yōu)化
Nginx作為高性能web服務(wù)器,即使不特意調(diào)整配置參數(shù)也可以處理大量的并發(fā)請求。當(dāng)然,配置調(diào)優(yōu)會使Nginx性能更加強悍,配置參數(shù)需要結(jié)合服務(wù)器硬件性能等做參考。
worker進程優(yōu)化
worker_processes num;
該參數(shù)表示啟動幾個工作進程,建議和本機CPU核數(shù)保持一致,每一核CPU處理一個進程,num表示數(shù)字。
worker_rlimit_nofile
它表示Nginx大可用的文件描述符個數(shù),需要配合系統(tǒng)的大描述符,建議設(shè)置為102400。
還需要在系統(tǒng)里執(zhí)行ulimit -n 102400才可以。
也可以直接修改配置文件/etc/security/limits.conf修改
增加:
#* soft nofile 655350 (去掉前面的#)
#* hard nofile 655350 (去掉前面的#)
worker_connections
該參數(shù)用來配置每個Nginx worker進程大處理的連接數(shù),
這個參數(shù)也決定了該Nginx服務(wù)器最多能處理多少客戶端請求(worker_processes * worker_connections)
建議把該參數(shù)設(shè)置為10240,不建議太大。
http/tcp連接數(shù)優(yōu)化
use epoll
使用epoll模式的事件驅(qū)動模型,該模型為Linux系統(tǒng)下最優(yōu)方式。
multi_accept on
使每個worker進程可以同時處理多個客戶端請求。
sendfile on
使用內(nèi)核的FD文件傳輸功能,可以減少user mode和kernel mode的切換,從而提升服務(wù)器性能。
tcp_nopush on
當(dāng)tcp_nopush設(shè)置為on時,會調(diào)用tcp_cork方法進行數(shù)據(jù)傳輸。
使用該方法會產(chǎn)生這樣的效果:當(dāng)應(yīng)用程序產(chǎn)生數(shù)據(jù)時,
內(nèi)核不會立馬封裝包,而是當(dāng)數(shù)據(jù)量積累到一定量時才會封裝,然后傳輸。
tcp_nodelay on
不緩存data-sends(關(guān)閉 Nagle 算法),這個能夠提高高頻發(fā)送小數(shù)據(jù)報文的實時性。
(關(guān)于Nagle算法)
【假如需要頻繁的發(fā)送一些小包數(shù)據(jù),比如說1個字節(jié),以IPv4為例的話,則每個包都要附帶40字節(jié)的頭,
也就是說,總計41個字節(jié)的數(shù)據(jù)里,其中只有1個字節(jié)是我們需要的數(shù)據(jù)。
為了解決這個問題,出現(xiàn)了Nagle算法。
它規(guī)定:如果包的大小滿足MSS,那么可以立即發(fā)送,否則數(shù)據(jù)會被放到緩沖區(qū),等到已經(jīng)發(fā)送的包被確認(rèn)了之后才能繼續(xù)發(fā)送。
通過這樣的規(guī)定,可以降低網(wǎng)絡(luò)里小包的數(shù)量,從而提升網(wǎng)絡(luò)性能。
keepalive_timeout
定義長連接的超時時間,建議30s,太短或者太長都不一定合適,當(dāng)然,最好是根據(jù)業(yè)務(wù)自身的情況來動態(tài)地調(diào)整該參數(shù)。
keepalive_requests
定義當(dāng)客戶端和服務(wù)端處于長連接的情況下,每個客戶端最多可以請求多少次,可以設(shè)置很大,比如50000.
reset_timeout_connection on
設(shè)置為on的話,當(dāng)客戶端不再向服務(wù)端發(fā)送請求時,允許服務(wù)端關(guān)閉該連接。
client_body_timeout
客戶端如果在該指定時間內(nèi)沒有加載完body數(shù)據(jù),則斷開連接,單位是秒,默認(rèn)60,可以設(shè)置為10。
send_timeout
這個超時時間是發(fā)送響應(yīng)的超時時間,即Nginx服務(wù)器向客戶端發(fā)送了數(shù)據(jù)包,但客戶端一直沒有去接收這個數(shù)據(jù)包。
如果某個連接超過send_timeout定義的超時時間,那么Nginx將會關(guān)閉這個連接。單位是秒,可以設(shè)置為3。
壓縮
對于純文本的內(nèi)容,Nginx是可以使用gzip壓縮的。使用壓縮技術(shù)可以減少對帶寬的消耗。
由ngx_http_gzip_module模塊支持
配置如下:
gzip on; //開啟gzip功能 gzip_min_length 1024; //設(shè)置請求資源超過該數(shù)值才進行壓縮,單位字節(jié) gzip_buffers 16 8k; //設(shè)置壓縮使用的buffer大小,第一個數(shù)字為數(shù)量,第二個為每個buffer的大小 gzip_comp_level 6; //設(shè)置壓縮級別,范圍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
日志
錯誤日志級別調(diào)高,比如crit級別,盡量少記錄無關(guān)緊要的日志。
對于訪問日志,如果不要求記錄日志,可以關(guān)閉,
靜態(tài)資源的訪問日志關(guān)閉
靜態(tài)文件過期
對于靜態(tài)文件,需要設(shè)置一個過期時間,這樣可以讓這些資源緩存到客戶端瀏覽器,
在緩存未失效前,客戶端不再向服務(wù)期請求相同的資源,從而節(jié)省帶寬和資源消耗。
配置示例如下:
location ~* ^.+\.(gif|jpg|png|css|js)$ { expires 1d; //1d表示1天,也可以用24h表示一天。 }
以上是“Nginx如何實現(xiàn)訪問控制與參數(shù)調(diào)優(yōu)”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道!