Linux實戰教學筆記38：企業級Nginx Web服務優化實戰（下）

時間  2019-11-17
標籤 linux 實戰 教學 筆記 企業 nginx web 服務 優化 欄目 Linux 简体版
原文   原文鏈接

四，Nginx站點目錄及文件URL訪問控制

4.1 根據擴展名限制程序和文件訪問

  • Web2.0時代，絕大多數網站都是以用戶爲中心多的，例如：bbs，blog，sns產品，這幾個產品都有一個共同特色，就是不但容許用戶發佈內容到服務器，還容許用戶發圖片甚至上傳附件到服務器上，因爲爲用戶開了上傳功能，所以給服務器帶來了很大的安全風險。雖然不少程序在上傳前會着必定的控制，例如：文件大小，類型等，可是，一不當心就會被黑客鑽了控制，上傳了木馬程序。
  • 下面將利用Nginx配置禁止訪問上傳資源目錄下的PHP，Shell，Perl，Python程序文件，這樣用戶即便上傳了木馬文件也無法執行，從而增強了網站的安全。

範例1：配置Nginx，禁止解析指定目錄下的指定程序。javascript

location ~ ^/images/.*\.(php|php5|sh|pl|py)$ { deny all; } location ~ ^/static/.*\.(php|php5|sh|pl|py)$ { deny all; } location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$ { deny all; } #對上述目錄的限制必須寫在Nginx處理PHP服務配置的前面，以下： location ~ .*\.(php|php5)$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fcgi.conf; }

範例2：Nginx下配置禁止訪問*.txt和*.doc文件。php

實際配置信息以下：css

location ~* \.(txt|doc)$
{
    if (-f $request_filename) { root /data/www/www; #rewrite ...能夠重定向到某個URL break； } } location ~* \.(txt|doc)$ { root /data/www/www; deny all; }

4.2 禁止訪問指定目錄下的全部文件和目錄

範例1：配置禁止訪問指定的單個或多個目錄html

#禁止訪問單個目錄的命令以下： location ~ ^/static { deny all; } #禁止訪問多個目錄的命令以下： location ~ ^/(static|js) { deny all; }

範例2：禁止訪問目錄並返回指定的HTTP狀態碼，命令以下：前端

server { listen 80; server_name www.yunjisuan.com yunjisuan.com; root /data/www/www; index index.html index.htm; access_log logs/www_access.log commonlog; location /admin/ { return 404; } location /tmplates/ { return 403; } }

做用：
禁止訪問目錄下的指定文件1，或者禁止訪問指定目錄下的全部內容。
最佳應用場景：
對於集羣的共享存儲，通常是存放靜態資源文件，因此，可禁止執行指定擴展名的程序，例：.php,.sh,.pl,.pyjava

4.3 限制網站來源IP訪問

下面介紹如何使用ngx_http_access_module限制網站來源IP訪問node

案例環境：phpmyadmin數據庫的Web客戶端，內部開發人員用的。ios

範例1：禁止某目錄讓外界訪問，但容許某IP訪問該目錄，且支持PHP解析，命令以下：nginx

location ~ ^/yunjisuan/ { allow 202.111.12.211; deny all; } location ~ .*\.(php|php5)$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; }

範例2：限制指定IP或IP段訪問，命令以下：web

location / { deny 192.168.1.1; allow 192.168.1.0/24; allow 10.1.1.0/16; deny all; }

參考資料：http://nginx.org/en/docs/http/ngx_http_access_module.html

企業問題案例： Nginx作反向代理的時候能夠限制客戶端IP嗎？

答：能夠，具體方法以下：

方法一：使用if來控制，命令以下：

if ($remote_addr = 10.0.0.7) { return 403; } if ($remote_addr = 218.247.17.130) { set $allow_access_root 'ture'; #我也不知道什麼意思 }

方法二：利用deny和allow只容許IP訪問，命令以下：

location / { root html/blog; index index.php index.html index.htm; allow 10.0.0.7; deny all; }

方法三：只拒絕某些IP訪問，命令以下：

location / { root html/blog; index index.php index.html index.htm; deny 10.0.0.7; allow all; }

注意事項：

  • deny必定要加一個IP，不然會直接跳轉到403，再也不往下執行了，若是403默認頁是在同一域名下，會形成死循環訪問。
  • 對於allow的IP段，從容許訪問的段位從小到大排列，如127.0.0.0/24的下面才能是10.10.0.0/16，其中：
  • 24表示子網掩碼：255.255.255.0
  • 16表示子網掩碼：255.255.0.0
  • 8表示子網掩碼：255.0.0.0
  • 以deny all:結尾，表示除了上面容許的，其餘的都禁止。如：
deny 192.168.1.1; allow 127.0.0.0/24; allow 192.168.0.0/16; allow 10.10.0.0/16; deny all;

4.4 配置Nginx，禁止非法域名解析訪問企業網站

問題：Nginx如何防止用戶IP訪問網站（惡意域名解析，也至關因而直接IP訪問企業網站）

方法一：讓使用IP訪問網站的用戶，或者惡意解析域名的用過戶，收到501錯誤，命令以下：

server { listen 80 default_server; server_name _; return 501; } #說明：直接報501錯誤，從用戶體驗上不是很好

方法二：經過301跳轉到主頁，命令以下：

server { listen 80 default_server; server_name _; rewrite ^(.*) http://www.yunjisuan.com/$1 permanent; }

方法三：發現某域名惡意解析到公司的服務器IP，在server標籤裏添加如下代碼便可，如有多個server則要多處添加。

if ($host ! ~ ^www\.yunjisuan\.com$) { rewrite ^(.*) http://www.yunjisuan.com/$1 permanent; } #說明：代碼含義爲若是header信息的host主機名字非www.yunjisuan.com，就301跳轉到www.yunjisuan.com

五，Nginx圖片及目錄防盜鏈解決方案

5.1 什麼是資源盜鏈

簡單的說，就是某些不法網站未經容許，經過在其自身網站程序裏非法調用其餘網站的資源，而後在本身的網站上顯示這些調用的資源，達到填充自身網站的效果。這一舉動不只浪費了調用資源網站的網絡流量，還形成其餘網站的帶寬及服務壓力吃緊，甚至宕機。

下面經過示意圖闡述資源被盜鏈原理，以下圖所示：

QQ截圖20170831214823.png-89.1kB

5.2 網站資源被盜鏈帶來的問題

若網站圖片及相關資源被盜鏈，最直接的影響就是網絡帶寬佔用加大了，帶寬費用多了，網絡流量也可能忽高忽低，Nagios/Zabbix等報警服務頻繁報警，相似下圖所示：

QQ截圖20170831215104.png-187.4kB

最嚴重的狀況就是網站的資源被非法使用，使網站帶寬成本加大和服務器壓力加大，這有可能致使數萬元的損失，且網站的正經常使用戶訪問也會受到影響。

5.3 企業真實案例：網站資源被盜鏈，出現嚴重問題

某日，接到從事運維工做的朋友的緊急求助，其公司的CDN源站，源站的流量沒有變更，但CDN加速那邊的流量無端超了好幾個GB，不知道怎麼處理。
該故障的影響：因爲是購買的CDN網站加速服務，所以雖然流量多了幾個GB，可是業務未受影響。只是，這麼大的異常流量，持續下去可直接致使公司無端損失數萬元。解決這個問題可體現運維的價值。

那麼，這樣的問題如何及時發現，又如何處理呢？

第一：對IDC及CDN帶寬作監控報警
第二：做爲高級運維或運維經理，天天上班的重要任務，就是常常查看網站流量圖，關注流量變化，關注異常流量。
第三：對訪問日誌作分析，迅速定位異常流量，而且和公司市場推廣等保持較好的溝通，以便調度帶寬和服務器資源，確保網站正常的訪問體驗。

5.4 常見防盜鏈解決方案的基本原理

（1）根據HTTP referer實現防盜鏈

  • 在HTTP協議中，有一個表頭字段叫referer，使用URL格式來表示是哪裏的連接用了當前網頁的資源。經過referer能夠檢測訪問的來源網頁，若是是資源文件，能夠跟蹤到顯示它的網頁地址，一旦檢測出來源不是本站，立刻進行阻止或返回指定的頁面。
  • HTTP referer是header的一部分，當瀏覽器向Web服務器發送請求時，通常會帶上referer，告訴服務器我是從哪一個頁面連接過來的，服務器藉此得到一些信息用於處理。Apache，Nginx，Lighttpd三者都支持根據HTTP referer實現防盜鏈，referer是目前網站圖片，附件，html等最經常使用的防盜鏈手段。下圖是referer防盜鏈的基本原理圖。

QQ截圖20170901200511.png-157.1kB

（2）根據cookie防盜鏈

  • 對於一些特殊的業務數據，例如流媒體應用經過ActiveX顯示的內容（例如，Flash，Windows Media視頻，流媒體的RTSP協議等），由於他們不向服務器提供referer header，因此若採用上述的referer的防盜鏈手段，就達不到想要的效果。
  • 對於Flash，Windows Media視頻這種佔用流量較大的業務數據，防盜鏈是比較困難的，此時能夠採用Cookie技術，解決Flash，Windows Media視頻等的防盜鏈問題。

例如：ActiveX插件不傳遞referer，但會傳遞Cookie，能夠在顯示ActiveX的頁面的<head></head>標籤內嵌入一段JavaScript代碼，設置「Cookie：Cache=av」以下：

<script>document.cookie="Cache=av;domain=domain.com;path=/";</script>

而後就能夠經過各類手段來判斷這個Cookie的存在，以及驗證其值的操做了。
根據Cookie來防盜鏈的技術比較複雜，咱們不在這裏涉及，同窗們若是感興趣，或者企業確實須要，可經過網絡來了解相關方法。

（3）經過加密變換訪問路徑實現防盜鏈

此種方法比較適合視頻及下載類業務數據的網站。例如：Lighttpd有相似的插件mod_secdownload來實現此功能。先在服務器端配置此模塊，設置一個固定用於加密的字符串，好比yunjisuan，而後設置一個url前綴，好比/mp4/，再設置一個過時時間，好比1小時，而後寫一段PHP代碼，利用加密字符串和系統時間等經過md5算法生成一個加密字符串。最終獲取到的文件的URL連接中會帶有一個時間戳和一個加密字符的MD5數值，在訪問時系統會對這兩個數據進行驗證。若是時間不在預期的時間段內（如1小時內）則失效；若是時間戳符合條件，可是加密的字符串不符合條件也會失效，從而達到防盜鏈的效果。

5.5 Nginx Web服務實現防盜鏈實戰

在默認狀況下，只須要進行簡單的配置，便可實現防盜鏈處理。請看下面的實例。

（1）利用referer，而且針對擴展名rewrite重定向

#下面的代碼爲利用referer且針對擴展名rewrite重定向，即實現防盜鏈的Nginx配置。 location ~* \.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ { valid_referers none blocked *.yunjisuan.com yunjisuan.com; # if ($invalid_referer) { rewrite ^/ http://www.yunjisuan.com/img/nolink.jpg; } } #提示：要根據本身公司的實際業務（是否有外鏈的合做）進行域名設置。

（2）利用referer，而且針對站點目錄過濾返回錯誤碼

針對目錄的方法以下：

location /images {
    root /data/www/www; valid_referers none blocked *.yunjisuan.com yunjisuan.com; if ($invalid_referer) { return403; } }

在上面這段防盜鏈設置中，分別針對不一樣文件類型和不一樣的目錄進行了設置，同窗們能夠根據本身需求進行相似設定。下面是上述代碼的說明：

5.6 NginxHttpAccessKeyModule實現防盜鏈介紹

  • 若是不怕麻煩，有條件實現的話，推薦使用NginxHttpAccessKeyModule。
  • 其運行方式是：如download目錄下有一個file.zip文件。對應的URI是http：//www.abc.com/download/file.zip,使用ngx_http_accesskey_module 模塊後就成了http://www.bac.com/download/file.zipkey=09093abeac094,只有正確地給定了key值，才能下載download目錄下的file.zip，並且key值是與用戶的IP相關的，這樣就能夠避免被盜鏈了。聽說，如今NginxHttpAccessKeyModule連迅雷均可以防了，同窗們執行嘗試一下。

5.7 在產品設計上解決盜鏈方案

產品設計時，處理盜鏈問題可將計就計，爲網站上傳的圖片增長水印。例如：下圖就是爲網站上傳的圖片增長的水印。

QQ截圖20170901211858.png-23kB

爲圖片添加版權水印是頗有效的方法。網站直接轉載圖片通常是爲了快捷，可是對於有水印的圖片，不少站長是不肯意轉載的。

六，Nginx錯誤頁面的優雅顯示

6.1 生產環境常見的HTTP狀態碼列表

QQ截圖20170901213041.png-357.1kB

6.2 爲何要配置錯誤頁面優雅顯示

在網站的運行過程當中，可能由於頁面不存在或系統過載等緣由，致使網站沒法正常響應用戶的請求，此時Web服務會返回系統默認的錯誤碼，或者很不友好的頁面，以下圖所示：

QQ截圖20170901213712.png-32.9kB

咱們能夠將404，403等的錯誤信息頁面重定向到網站首頁或其餘事先指定的頁面，提高網站的用戶訪問體驗。

範例1：對錯誤代碼403實行本地頁面跳轉，命令以下：

server { listen 80; server_name www.yunjisuan.com; location / { root html/www; index index.html index.htm; } error_page 403 /403.html; #當出現403錯誤時，會跳轉到403.html頁面 } #上面的/403.html是相對於站點根目錄html/www的。

範例2：對錯誤代碼404實行本地頁面優雅顯示，命令以下：

server { listen 80; server_name www.yunjisuan.com; location / { root html/www; index index.html index.htm; error_page 404 /404.html; #當出現404錯誤時，會跳轉到404.html頁面 } } #代碼中的/404.html是相對於站點根目錄html/www的

範例3： 50x頁面放到本地單獨目錄下，進行優雅顯示

error_page 500 502 503 504 /50x.html; location = /50x.html { root /data/www/html; } #這裏指定單獨的站點目錄存放到50x.html文件中。

範例4： 錯誤狀態碼URL重定向，命令以下：

server { listen 80; server_name www.yunjisuan.com; location / { root html/www; index index.html index.htm; error_page 404 http://bbs.yunjisuan.com; #當出現404錯誤時，會跳轉到指定的URL http://bbs.yunjisuan.com頁面顯示給用戶，這個URL通常是企業另外的可用地址。 access_log /usr/local/nginx/logs/bbs_access.log commonlog; } } #代碼中的/404.html是相對於站點根目錄html/www的。

範例5： 將錯誤狀態碼重定向到一個location，命令以下：

location / { error_page 404 = @fallback; } location @fallback { proxy_pass http://backend; }

6.3 阿里門戶網站天貓的Nginx優雅顯示配置案例以下：

error_page 500 501 502 503 504 http://err.tmall.com/error2.html; error_page 400 403 404 405 408 410 411 412 413 414 415 http://err.tmall.com/error1.html;

七，Nginx站點目錄文件及目錄權限優化

7.1 單機LNMP環境目錄權限嚴格控制措施

爲了保證網站不遭受木馬入侵，全部站點目錄的用戶和組都應該爲root，全部的目錄權限是755；全部的文件權限是644.設置以下：

[root@LNMP nginx]# ls -l /usr/local/nginx/html/ | tail -5 -rw-r--r--. 1 root root 8048 Jan 11 2017 wp-mail.php -rw-r--r--. 1 root root 16255 Apr 6 14:23 wp-settings.php -rw-r--r--. 1 root root 29896 Oct 19 2016 wp-signup.php -rw-r--r--. 1 root root 4513 Oct 14 2016 wp-trackback.php -rw-r--r--. 1 root root 3065 Aug 31 2016 xmlrpc.php
  • 以上的權限設置能夠防止黑客上傳木馬，以及修改站點文件，可是，合理的網站用戶上傳的內容也會被拒之門外。那麼如何讓合法的用戶能夠上傳文件，而又不至於被黑客利用攻擊呢？
  • 若是是單機的LNMP環境，站點目錄和文件屬性設置以下。
  • 先把全部的目錄權限設置爲755，全部的文件權限設置爲644，所用的目錄，以及文件用戶和組都是root；而後把用戶上傳資源的目錄權限設置爲755，將用戶和組設置爲Nginx服務的用戶；最後針對上傳資源的目錄作資源訪問限制。
  • 部分公司所採用的受權方式不是很安全，常見的有以下兩種：
chmod -R 777 /directory chmod -R nginx.nginx /directory
  • 上述兩種受權方法雖然不能說錯誤，可是沒有作到受權最小化，會給網站帶來很是大的安全隱患，特別是木馬入侵的時候。
  • 在比較好的網站業務架構中，應把資源文件，包括用戶上傳的圖片，附件等服務和程序服務分離，最好把上傳程序服務也分離出來，這樣就能夠從容地按照以前所述進行安全受權了。

7.2 Nginx企業網站集羣超級安全設置

結合Linux權限體系及Nginx大型集羣架構進行配置，嚴格控制針對Nginx目錄的訪問才能下降網站被入侵的風險。好比，可根據下圖中的企業集羣架構邏輯圖和不一樣角色提供的不一樣服務來嚴格控制不一樣服務器的Nginx目錄權限。

QQ截圖20170901234255.png-157.2kB

下圖爲集羣架構中不一樣於前面Web業務的權限管理細化。

服務器角色 權限處理 安全係數
動態Web集羣 目錄權限755，文件權限644，所用目錄，以及文件用戶和組都是root。環境爲Nginx+PHP 文件不能被改，目錄不能被寫入，安全係數10
static圖片集羣 目錄權限755，文件權限644，所用的目錄，以及文件用戶和組都是root。環境爲Nginx 文件不能被改，目錄不能被寫入，安全係數10
上傳upload集羣 目錄權限755，文件權限644，所用的目錄，以及文件用戶和組都是root。特別：用戶上傳的目錄設置爲755，用戶和組使用Nginx服務配置的用戶 文件不能被改，目錄不能被寫入，可是用戶上傳的目錄容許寫入文件且須要經過Nginx的其餘功能來禁止讀文件，安全係數8

作到上述的設置後，網站服務在系統層面被入侵的風險就大大下降了。

八，Nginx防爬蟲優化

8.1 robots.txt機器人協議常識

  • Robots協議（也稱爲爬蟲協議，機器人協議等）的全稱是「網絡爬蟲排除標準」(Robots Exclusion Protocol),網站經過Robots協議告訴搜索引擎哪些頁面能夠抓取，哪些頁面不能抓取。
  • 我理解的是robots.txt是經過代碼控制搜索引擎蜘蛛索引的一個手段，以便減輕網站服務器的帶寬使用率，從而讓網站的空間更穩定，同時也能夠提升網站其餘頁面的索引效率，提升網站收錄。
  • 咱們只須要建立一個robots.txt文本文件，而後在文檔內設置好代碼，告訴搜索引擎我網站的哪些文件你不能訪問。而後上傳到網站根目錄下面，由於當搜索引擎蜘蛛在索引一個網站時，會先爬行查看網站根目錄下是否有robots.txt文件。

8.2 機器人協議起源

  • 2011年10月25日，京東商城正式將一淘網的搜索爬蟲屏蔽，以防止一淘網對其內容進行抓取。

京東的robots.txt設置以下：
https://www.jd.com/robots.txt

QQ截圖20170902000613.png-27.6kB

  • 2008年9月8日，淘寶網宣佈封殺百度爬蟲，百度忍痛遵照爬蟲協議。由於一旦破壞協議，用戶的隱私和利益就沒法獲得保障，搜索網站就談不上人性關懷。

淘寶的robots.txt設置以下：
https://www.taobao.com/robots.txt

QQ截圖20170902000647.png-41.3kB

  • 2012年8月，360綜合搜索被指違反robots協議。

360的robots.txt設置以下：
http://www.360.cn/robots.txt

QQ截圖20170902000824.png-27.4kB

8.3 Nginx防爬蟲優化配置

咱們能夠根據客戶端的user-agents信息，輕鬆地阻止指定的爬蟲爬取咱們的網站。下面來看幾個案例。

範例1：阻止下載協議代理，命令以下：

##Block download agents## if ($http_user_agent ~* LWP:Simple | BBBike | wget) { return 403; } #說明：若是用戶匹配了if後面的客戶端（例如wget），就返回403.

這裏根據$http_user_agent獲取客戶端agent，而後判斷是否容許或返回指定錯誤碼。

範例2：添加內容防止N多爬蟲代理訪問網站，命令以下：

#這些爬蟲代理使用「|」分隔，具體要處理的爬蟲能夠根據需求增長或減小，添加的內容以下： if ($http_user_agent ~* "qihoobot|Baiduspider|Googlebot-Modile|Googlebot-Image|Mediapartners-Google|Adsbot-Google|Yahoo! SSlurp China|YoudaoBot|Sosospider|Sogou spider|Sogou web spider|MSNBot") { return 403; }

範例3：測試禁止不一樣的瀏覽器軟件訪問

示例代碼以下：

if ($http_user_agent ~* "Firefox|MSIE") { rewrite ^(.*) http://www.yunjisuan.com/$1 permanent; } #若是瀏覽器爲Firefox或IE，就會跳轉到http://www.yunjisuan.com

九，利用Nginx限制HTTP的請求方法

在以前的HTTP協議原理一節中，講解了不少HTTP方法，其中最經常使用的HTTP方法爲GET，POST，咱們能夠經過Nginx限制HTTP請求的方法來達到提高服務器安全的目的，例如，讓HTTP只能使用GET，HEAD和POST方法的配置以下：

#Only allow these request methods if ($request_method ! ~ ^(GET|HEAD|POST)$) { return 501; }

當上傳服務器上傳數據到存儲服務器時，用戶上傳寫入的目錄就不得不給Nginx對應的用戶相關權限，這樣一旦程序有漏洞，木馬就有可能被上傳到服務器掛載的對應存儲服務器的目錄裏，雖然咱們也作了禁止PHP，SH，PL，PY等擴展名的解析限制，但仍是會遺漏一些想不到的可執行文件。對於這樣狀況，該怎麼辦呢？事實上，還能夠經過限制上傳服務器的Web服務（能夠具體到文件）使用GET方法，防止用戶經過上傳服務器訪問存儲內容，讓訪問存儲渠道只能從靜態或圖片服務器入口進入。例如，在上傳服務器上限制HTTP的GET方法的配置以下：

#Only deny GET request methods ## if ($request_method ~* ^(GET)$) { return 501; } #提示：還能夠加一層location，更具體地限制文件名

實際效果以下圖所示：

QQ截圖20170902210551.png-30kB

十，使用CDN作網站內容加速

10.1 什麼是CDN

  • CDN的全稱是Content Delivery Network，中文意思是內容分發網絡。簡單地講，經過在現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的Cache服務器內，經過智能DNS負載均衡技術，判斷用戶的來源，讓用戶就近使用與服務器相同線路的帶寬訪問Cache服務器，取得所需的內容。例如：天津網通用戶訪問天津網通Cache服務器上的內容，北京電信訪問北京電信Cache服務器上的內容。這樣能夠有效減小數據在網絡上傳輸的時間，提升訪問速度。
  • CDN是一套全國或全球的1分佈式緩存集羣，其實質是經過智能DNS判斷用戶的來源地域及上網線路，爲用戶選擇一個最接近用戶地域，以及和用戶上網線路相同的服務器節點，由於地域近，且線路相同，因此，能夠大幅提高用戶瀏覽網站的體驗。
  • CDN產生背景之一：BGP機房雖然能夠提高用戶體驗，可是價格昂貴，對於用戶來講，CDN的誕生能夠提供比BGP機房更好的體驗（讓同一地區，同一線路的用戶訪問和當地同一線路的網站），BGP機房和普通機房有將近5~10倍的價格差。CDN多使用單線的機房，根據用戶的線路及位置，爲用戶選擇靠近用戶的位置，以及相同的運營商線路，不但提高了用戶體驗，價格也降下來了。
  • [x] CDN的價值：
    • 爲架設網站的企業省錢
    • 提高企業網站的用戶訪問體驗（相同線路，相同地域，內存訪問）
    • 能夠阻擋大部分流量攻擊，例如：DDOS攻擊

10.2 CDN的特色

  • [x] CDN就是一個具有根據用戶區域和線路智能調度的分佈式內存緩存集羣。其特色以下：
    • 經過服務器內存緩存網站數據，提升了企業站點（尤爲含有大量圖片，視頻等的站點）的訪問速度，並大大提升企業站點的穩定性（省錢且提高用戶體驗）。
    • 用戶根據智能DNS技術自動選擇最適合的Cache服務器，下降了不一樣運營商之間互聯瓶頸形成的影響，實現了跨運營商的網絡加速，保證不一樣網絡中的用戶都能獲得良好的訪問質量。
    • 加快了訪問速度，減小了原站點的帶寬
    • 用戶訪問時從服務器的內存中讀取數據，分擔了網絡流量，同時減輕了原站點負載壓力等。
    • 使用CDN能夠分擔源站的網絡流量，同時能夠減輕原站點的負載壓力，並下降黑客入侵及各類DDOS攻擊對網站的影響，保證網站有較好的服務質量。

下面是經過curl命令訪問163網站的header信息，能夠看到163網站的首頁就使用了CDN進行加速。

[root@LNMP logs]# curl -I www.163.com HTTP/1.1 200 OK Expires: Sat, 02 Sep 2017 13:53:55 GMT Date: Sat, 02 Sep 2017 13:52:35 GMT Server: nginx Content-Type: text/html; charset=GBK Transfer-Encoding: chunked Vary: Accept-Encoding,User-Agent,Accept Cache-Control: max-age=80 Age: 34 X-Via: 1.1 fzhwtxz25:6 (Cdn Cache Server V2.0), 1.1 wangtong42:0 (Cdn Cache Server V2.0) Connection: keep-alive

上面的「（CdnCacheServerV2.0）」表示163首頁使用了CDN加速。

10.3 企業使用CDN的基本要求

首先要說的是，不是全部的網站均可以一上來就能用CDN的。要加速的業務數據應該存在獨立的域名，例如：img1-4.yunjisuan.com/video1-4.yunjisuan.com，業務內容圖片，附件，JS，CSS等靜態元素，這樣的靜態網站域名纔可使用CDN。

下面來看一個DNS解析範例。DNS服務器加速前的A記錄以下：

;A records img.yunjisuanl.com IN A 124.106.0.21 (企業服務器的IP) #刪除上面的記錄，命令以下： img.yunjisuanl.com IN A 124.106.0.21 (服務器的IP) #而後，作下面的別名解析： ；CNAME records img.yunjisuan.com IN CNAME bbs img.yunjisuan.com 3M IN CNAME img.yunjisuan.com.cachecn.com.

提示：
這個img.yunjisuan.com.cachecn.com.地址必須是事先由CDN公司配置好的CDN公司的域名。國內較大的CDN提供商爲網宿，藍訊，快網。

十一，Nginx程序架構優化

解耦是開發人員中流行的一個名詞，簡單地說就是把一堆程序代碼按照業務用途分開，而後提供服務，例如：註冊登陸，上傳，下載，瀏覽列表，商品內容頁面，訂單支付等都應該是獨立的程序服務，只不過在客戶端看來是一個總體而已。若是中小公司作不到上述細緻的解耦，起碼也要讓下面的幾個程序模塊獨立。

  • 網頁頁面服務。（靜態，動態頁面）
  • 圖片附件及下載服務。（upload）
  • 上傳圖片服務。（static）
  • 上述三者的功能儘可能分離。分離的最佳方式是分別使用獨立的服務器（須要改動程序），若是程序實在不易更改，次選方案是在前端負載均衡器Haproxy/Nginx上，根據URI（例如目錄或擴展名）過濾請求，而後拋給後面對應的服務器。
  • 例如：根據擴展名分發，請求http://www.yunjisuan.com/a/b.jpg就應拋給圖片服務器（獨立的靜態服務器最適合使用CDN）；根據URL路徑分發，請求http://www.yunjisuan.com/upload/index.php就應拋給上傳服務器。不符合上面兩個要求的，默認拋給Web服務器。

說明：能夠部署3臺服務器，人爲分佈請求服務器。固然了，這適合併發比較高，服務器較多的狀況。程序架構分離了，效率，安全性都會提升不少。

十二，使用普通用戶啓動Nginx（監牢模式）

12.1 爲何要讓Nginx服務使用普通用戶

默認狀況下，Nginx的Master進程使用的是root用戶，worker進程使用的是Nginx指定的普通用過戶，使用root用戶跑Nginx的Master進程有兩個最大的問題：

  • 管理權限必須是root，這就使得最小化分配權限原則遇到難題。
  • 使用root跑Nginx服務，一旦網站出現漏洞，用戶就能夠很容易地得到服務器的root權限。

所以，若是能有一種不用給開發人員，甚至普通運維人員管理員權限，就能夠很好地管理Nginx服務的方法，具體內容將在下節爲你們講解。

12.2 給Nginx服務降權的解決方案

解決方案以下：

  • 給Nginx服務降權，用inca用戶跑Nginx服務，給開發及運維設置普通帳號，只要與inca同組便可管理Nginx，該方案解決了Nginx管理問題，防止root分配權限過大。
  • 開發人員使用普通帳戶便可管理Nginx服務及站點下的程序和日誌。
  • 採起項目負責制度，即誰負責項目維護，出了問題就是誰負責。

不少公司開發和運維爲root權限爭得不可開交，甚至大打出手。
參考資料：到底要不要給開發人員管理服務器的權限？（http://down.51cto.com/data/844517）.

12.3 給Nginx服務降權實戰

本優化屬架構優化（一樣適合其餘軟件），經過Nginx啓動命令的-c參數指定不一樣的Nginx配置文件，能夠同時啓動多個實例，並使用普通的用戶運行服務。
Nginx安裝後的啓動命令路徑爲「/usr/local/nginx/sbin/nginx」,能夠經過加-h參數查看相關參數的用法，命令及結果以下：

[root@LNMP logs]# /usr/local/nginx/sbin/nginx -h
nginx version: nginx/1.6.2 Usage: nginx [-?hvVtq] [-s signal] [-c filename] [-p prefix] [-g directives] Options: -?,-h : this help -v : show version and exit -V : show version and configure options then exit -t : test configuration and exit -q : suppress non-error messages during configuration testing -s signal : send signal to a master process: stop, quit, reopen, reload -p prefix : set prefix path (default: /usr/local/nginx/) -c filename : set configuration file (default: conf/nginx.conf) #使用指定的配置文件而不是conf目錄下的nginx.conf這裏咱們就是經過nginx -c路徑的功能來實現跑多實例nginx -g directives : set global directives out of configuration file

較經常使用的方法是使服務跑在指定用戶的家目錄下面，這樣相對比較安全，同時有利於批量業務部署和上線。

配置普通用戶啓動Nginx的過程以下：

1）添加用戶並建立相關目錄和文件，操做以下：

[root@LNMP ~]# useradd yunjisuan [root@LNMP ~]# su - yunjisuan [yunjisuan@LNMP ~]$ pwd /home/yunjisuan [yunjisuan@LNMP ~]$ mkdir conf logs www #在普通用戶家目錄下建立nginx配置文件目錄 [yunjisuan@LNMP ~]$ ls conf logs www [yunjisuan@LNMP ~]$ cp /usr/local/nginx/conf/mime.types ~/conf/ #複製媒體類型配置文件 [yunjisuan@LNMP ~]$ echo "yunjisuan" > www/index.html #建立網頁首頁

2）配置Nginx配置文件。配置後的查看命令以下：

[yunjisuan@LNMP ~]$ cat conf/nginx.conf worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; worker_rlimit_nofile 65535; error_log /home/yunjisuan/logs/error.log; user yunjisuan yunjisuan; pid /home/yunjisuan/logs/nginx.pid; events { use epoll; worker_connections 10240; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; log_format main '$remote_addr-$remote_user[$time_local]"$request"' '$status $body_bytes_sent "$http_referer"' '"$http_user_agent""$http_x_forwarded_for"'; server { listen 8080; server_name www.yunjisuan.com; root /home/yunjisuan/www; location / { index index.php index.html index.htm; } access_log /home/yunjisuan/logs/web_blog_access.log main; } } [yunjisuan@LNMP ~]$ tree . ├── conf │   ├── mime.types │   └── nginx.conf ├── logs └── www └── index.html 3 directories, 3 files

說明以下：

  • 全部參數的值，帶路徑的都要改爲/home/yunjisuan.
  • 特權用戶root使用的80端口，改成普通用過戶使用的端口，在1024以上，這裏爲8080.

3）啓動Nginx，命令以下：

[yunjisuan@LNMP ~]$ ps -ef | grep nginx | grep -v grep [yunjisuan@LNMP ~]$ /usr/local/nginx/sbin/nginx -c /home/yunjisuan/conf/nginx.conf &>/dev/null & [1] 2478 [yunjisuan@LNMP ~]$ ps -ef | grep nginx | grep -v grep 503 2479 1 0 14:34 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /home/yunjisuan/conf/nginx.conf 503 2480 2479 0 14:34 ? 00:00:00 nginx: worker process 503 2481 2479 0 14:34 ? 00:00:00 nginx: worker process 503 2482 2479 0 14:34 ? 00:00:00 nginx: worker process 503 2483 2479 0 14:34 ? 00:00:00 nginx: worker process [1]+ Done /usr/local/nginx/sbin/nginx -c /home/yunjisuan/conf/nginx.conf &>/dev/null #提示503是用戶yunjisuan的UID號 [yunjisuan@LNMP ~]$ id yunjisuan uid=503(yunjisuan) gid=503(yunjisuan) groups=503(yunjisuan)

特別提示：
此處啓動nginx，若是不定向到空會顯示一些提示，不是錯誤，能夠經過&>/dev/null 定向到空，從而忽略不見。

[yunjisuan@LNMP ~]$ killall nginx
[yunjisuan@LNMP ~]$ ps -ef | grep nginx | grep -v grep [yunjisuan@LNMP ~]$ /usr/local/nginx/sbin/nginx -c /home/yunjisuan/conf/nginx.conf & [1] 2495 [yunjisuan@LNMP ~]$ nginx: [alert] could not open error log file: open() "/usr/local/nginx/logs/error.log" failed (13: Permission denied) 2017/08/30 14:38:20 [warn] 2495#0: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /home/yunjisuan/conf/nginx.conf:5 #此處錯誤能夠忽略，定向輸出到&>/dev/null

4）配置好解析後，瀏覽器帶端口訪問結果以下圖所示：

QQ截圖20170903013350.png-11.8kB

5）解決普通端口非80提供服務的問題

用負載均衡器解決Web服務非80端口的轉換問題，負載均衡器可爲Haproxy，Nginx，F5等。

本解決方案的優勢以下：

  • 給Nginx服務降權，讓網站更安全。
  • 按用戶設置站點權限，使站點更獨立（無需虛擬化隔離）
  • 開發不須要用root便可完整管理服務及站點。
  • 可實現責任劃分，即網絡問題屬於運維的責任，網站打不開就是開發的責任，或者二者共同承擔。

十三，控制Nginx併發鏈接數量

  • ngx_http_limit_conn_module這個模塊用於限制每一個定義的key值的鏈接數(Nginx默認已經被編譯)，特別是單IP的鏈接數。
  • 不是全部的鏈接數都會被計數。一個符合計數要求的鏈接是整個請求頭已經被讀取的鏈接。

控制Nginx併發鏈接數量參數的說明以下：

1）limit_conn_zone參數：

語法：limit_conn_zone key zone=name:size;
上下文：http
#用於設置共享內存區域，key能夠是字符串，Nginx自帶變量或前兩個組合，如$binary_remote_addr,$server_name.name爲內存區域的名稱，size爲內存區域的大小。

2）limit_conn參數：

語法：limit_conn zone number;
上下文：http,server,location
#用於指定key設置最大鏈接數。當超過最大鏈接數時，服務器會返回503（Service Temporarily Unavailable）錯誤

13.1 限制單IP併發鏈接數

Nginx的配置文件以下：

[root@web03 nginx]# cat conf/nginx.conf worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; limit_conn_zone $binary_remote_addr zone=addr:10m; server { listen 80; server_name www.yunjisuan.com; location / { root html; index index.html index.htm; limit_conn addr 1; #限制同IP的併發爲1； } } }

測試1：利用Webbench進行併發鏈接測試（模擬一個客戶端）

[root@localhost ~]# webbench -c 1 -t 5 http://192.168.0.225/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://192.168.0.225/ 1 client, running 5 sec. Speed=341472 pages/min, 4808941 bytes/sec. Requests: 28456 susceed, 0 failed. #提示：192.168.0.225爲web服務器， #-c：指定客戶端數量 #-t：指定持續時間

咱們查看Web服務器的access.log日誌以下：

[root@web03 nginx]# tail logs/access.log 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:29:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5"

從上邊的日誌咱們能夠看到，當併發數爲1時（就一個客戶端），nginx正常記錄用戶的訪問狀況，http返回狀態碼爲200

測試2：利用Webbench進行多客戶端併發測試(模擬2個客戶端)

[root@localhost ~]# webbench -c 2 -t 5 http://192.168.0.225/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://192.168.0.225/ 2 clients, running 5 sec. Speed=565608 pages/min, 5808154 bytes/sec. Requests: 47134 susceed, 0 failed.

咱們查看Web服務器的access.log日誌以下：

[root@web03 nginx]# tail logs/access.log 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:31:08 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5"

從上邊的日誌咱們能夠看出，當咱們用單IP地址模擬兩個併發客戶端進行鏈接時，日誌以1：1比例交替出現了503錯誤。即Nginx已經作了併發鏈接限制，對超過限制的請求返回503.

測試3：利用Webbench進行多客戶端併發測試(模擬3個客戶端)

[root@localhost ~]# webbench -c 3 -t 5 http://192.168.0.225/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://192.168.0.225/ 3 clients, running 5 sec. Speed=653388 pages/min, 6162385 bytes/sec. Requests: 54449 susceed, 0 failed.

咱們查看Web服務器的access.log日誌以下：

[root@web03 nginx]# tail logs/access.log 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:16:39:20 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5"

通過測試，能夠看得出，200與503基本出現次數爲1:2，即Nginx已經作了併發鏈接限制，對超過限制的請求返回503.

以上功能的應用場景之一是用於服務器下載，命令以下：

location /download/ { limit_conn addr 11; }

上面的命令限制訪問download下載目錄的鏈接數，該鏈接數1.

13.2 限制虛擬主機總鏈接數

不只能夠限制單IP的併發鏈接數，還能夠限制虛擬主機總鏈接數，甚至能夠對二者同時限制。

Nginx的配置文件以下:

[root@web03 nginx]# cat conf/nginx.conf worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; limit_conn_zone $binary_remote_addr zone=addr:10m; limit_conn_zone $server_name zone=perserver:10m; server { listen 80; server_name www.yunjisuan.com; location / { root html; index index.html index.htm; #limit_conn addr 1; limit_conn perserver 2; #設置虛擬主機鏈接數爲2 } } }

測試：

#重啓Nginx服務後進行測試 root@localhost ~]# webbench -c 5 -t 5 http://192.168.0.225/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://192.168.0.225/ 5 clients, running 5 sec. Speed=682128 pages/min, 7674820 bytes/sec. Requests: 56844 susceed, 0 failed.

咱們查看Web服務器的access.log日誌以下：

[root@web03 nginx]# tail -20 logs/access.log 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 503 213 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" 192.168.0.240 - - [30/Aug/2017:17:11:14 -0400] "GET / HTTP/1.0" 200 612 "-" "WebBench 1.5" [root@web03 nginx]# grep -c 200 logs/access.log 35850 [root@web03 nginx]# grep -c 503 logs/access.log 20998 [root@web03 nginx]# cat logs/access.log | wc -l 56848

結論：200和503出現的次數近似2：1
至此，Nginx限制鏈接數的應用實踐就講解完畢了。
更多資料可參考：http：//nginx.org/en/docs/http/ngx_http_limit_conn_module.html

十四，控制客戶端請求Nginx的速率

ngx_http_limit_req_module模塊用於限制每一個IP訪問每一個定義key的請求速率。

語法：limit\_req\_zone key zone=name: size rate=rate; 上下文1：http #用於設置共享內存區域，key能夠是1字符串，Nginx自帶變量或前兩個組合，如$binary_remote_addr。name爲內存區域的名稱，size爲內存區域的大小，rate爲速率，單位爲r/s，每秒一個請求。 limit_req參數說明以下： 語法：limit_req zone=name [burst=number][nodelay]; 上下文：http,server,location
  • 這裏運用了令牌桶原理，burst=num,一共有num塊令牌，令牌發完後，多出來的那些請求就會返回503。
  • 換句話說，一個銀行，只有一個營業員，銀行很小，等候室只有5我的的位置。所以，營業員一個時刻只能爲一我的提供服務，剩下的不超過5我的能夠在銀行內等待，超出的人不提供服務，直接返回503。
  • nodelay默認在不超過burst值的前提下會排隊等待處理，若是使用此參數，就會處理完num + 1次請求，剩餘的請求都視爲超時，返回503。

用於測試的Nginx配置文件以下：

[root@web03 nginx-1.10.2]# cat /usr/local/nginx/conf/nginx.conf worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; #以請求的客戶端IP做爲key值，內存區域命令爲one，分配10m內存空間，訪問速率限制爲1秒1次請求（request） # limit_conn_zone $binary_remote_addr zone=addr:10m; # limit_conn_zone $server_name zone=perserver:10m; server { listen 80; server_name www.yunjisuan.com; location / { root html; index index.html index.htm; limit_req zone=one burst=5; #使用前面定義的名爲one的內存空間，隊列值爲5，便可以有5個請求排隊等待 # limit_conn addr 1; # limit_conn addr 1; } } } [root@web03 nginx-1.10.2]# /usr/local/nginx/sbin/nginx -s reload #重啓服務

利用Webbench進行測試

[root@localhost ~]# webbench -c 100 -t 10 http://192.168.0.225/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software. Benchmarking: GET http://192.168.0.225/ 100 clients, running 10 sec. Speed=749706 pages/min, 4811119 bytes/sec. Requests: 124951 susceed, 0 failed.

咱們查看Web服務器的access.log日誌以下:

[root@web03 nginx]# > logs/access.log [root@web03 nginx]# grep -c 200 logs/access.log 11 [root@web03 nginx]# grep -c 503 logs/access.log 124978 [root@web03 nginx]# cat logs/access.log | wc -l 124994 #說明：本次測試只成功響應了11個請求，近視1秒處理1個請求。多餘的請求一概用503進行響應。

QQ截圖20170903121844.png-153.6kB

  • 經過過濾排重日誌，能夠看到第一個請求返回200，爲正常處理，剩餘2582次+9858次超過了限制的在1秒內執行完成，可是都返回了503
  • 具體過程原理爲：Nginx在第1秒先處理第一個請求，同時接下來的5個請求等待排隊，剩下的（2582+9858）請求返回503。接着第2秒到第6秒處理等待的5個請求。
    更多內容可參考：http://nginx.org/en/docs/http/ngx_http_limit_req_module.html。

十五，本章重點回顧

  1. 安全優化：隱藏Nginx軟件名及版本號。
  2. 性能加安全優化：鏈接超時參數及FastCGI相關參數調優
  3. 性能優化：expires緩存功能及調試查看方法。
  4. 性能優化：gzip壓縮功能及調試查看方法。
  5. 安全優化：集羣中各角色服務站點目錄權限控制策略。
  6. 安全優化：站點目錄下全部的文件和目錄訪問控制。
  7. 性能加安全優化：靜態資源防盜鏈解決方案
  8. 性能加安全優化：robots.txt協議及防爬蟲優化解決方案
  9. 用戶體驗優化：錯誤頁面優雅顯示方法
  10. 安全優化：限制http請求方法
  11. 性能加安全優化：CDN加速知識
  12. 安全優化：監牢模式運行Nginx方案策略
  13. 性能加安全優化：Nginx併發鏈接數及請求速率控制
金牌IT職業再教育培訓機構，歡迎來校資源。QQ：215379068
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程