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狀態碼。
測試鏈接舉例：
如果用戶輸入的URL是上面其中之一都會返回403。
示例3
location ~ (data|cache|tmp|image|attachment).*/.php${ deny all;}說明：請求的uri中包含data、cache、tmp、image、attachment并且以.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
日志
靜態文件過期
對于靜態文件，需要設置一個過期時間，這樣可以讓這些資源緩存到客戶端瀏覽器，
在緩存未失效前，客戶端不再向服務期請求相同的資源，從而節省帶寬和資源消耗。
配置示例如下：
location ~* ^.+/.(gif|jpg|png|css|js)$ { expires 1d; //1d表示1天，也可以用24h表示一天。}訪問控制和參數調優只記錄其中一些部分，有些可能會在工作中用到，SSL的配置后續再作筆記吧，春招筆試好難呀，努力學習吧...
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持ASPKU武林網。
新聞熱點
疑難解答
