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的配置後續再做筆記吧，春招筆試好難呀，努力學習吧...