国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Nginx訪問控制與參數調優

miguel.jiang / 812人閱讀

摘要:示例說明請求的中包含并且以結尾的,全部禁止訪問。測試鏈接匹配不匹配基于訪問控制比多了請求的參數。訪問控制和參數調優只記錄其中一些部分,有些可能會在工作中用到,的配置后續再作筆記吧,春招筆試好難呀,努力學習吧

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的denyallow指令是由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結構中不支持使用allowdeny。

測試鏈接:

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 "";
}
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的配置后續再作筆記吧,春招筆試好難呀,努力學習吧...

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/40365.html

相關文章

  • nginx網站性能優化篇(4)】理解nginx的高并發原理及其配置調優

    摘要:使用了多路復用技術的,就成了并發事件驅動的服務器。進程主要負責收集分發請求。同時進程也負責監控的狀態,保證高可靠性進程一般設置為跟核心數一致。所以才使得支持更高的并發。配置調優調整指要生成的數量最佳實踐是每個運行個工作進程。 Nginx 是如何實現高并發的? Nginx 采用的是多進程(單線程) & 多路IO復用模型。使用了 I/O 多路復用技術的 Nginx,就成了并發事件驅動的服務...

    CODING 評論0 收藏0
  • 后端技術精選 - 收藏集 - 掘金

    摘要:使用簽署免費證書后端掘金本文操作在操作系統下完成,需要和超文本傳輸安全協議英語,縮寫,常稱為,紅黑樹深入剖析及實現后端掘金紅黑樹是平衡二叉查找樹的一種。 使用 Lets Encrypt 簽署免費 Https 證書 - 后端 - 掘金 本文操作在Linux操作系統下完成,需要Python和Nginx 超文本傳輸安全協議(英語:Hypertext Transfer Protocol Sec...

    Meils 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<