Nginx安裝配置防盜鏈及深度優化

1、編譯安裝前的優化
編譯安裝前的優化主要是用來修改程序名等等,經過更改源碼以便隱藏軟件名稱和版本號。javascript

下載我提供的所需源碼包:https://pan.baidu.com/s/1tyS3GL0W2kcQGsdfwc3B1w
提取碼:cs23
一、開始安裝:php

[root@nginx ~]# yum -y erase httpd        #卸載系統默認的httpd服務,防止端口衝突
[root@nginx ~]# yum -y install openssl-devel pcre-devel    #安裝所需依賴
[root@nginx src]# rz          #rz命令上傳所需源碼包
[root@nginx src]# ls          #確認上傳的源碼包
nginx-sticky-module.zip    nginx-1.14.0.tar.gz    ngx_cache_purge-2.3.tar.gz
#將上傳的源碼包進行解壓
[root@nginx src]# tar zxf nginx-1.14.0.tar.gz  
[root@nginx src]# unzip nginx-sticky-module.zip 
[root@nginx src]# tar zxf ngx_cache_purge-2.3.tar.gz 
[root@nginx src]# cd nginx-1.14.0/        #切換至nginx目錄
[root@nginx nginx-1.14.0]# vim src/core/nginx.h    #修改如下兩行配置
#define NGINX_VERSION      "6.6"       #這裏是修改nginx的版本號
#define NGINX_VER          "IIS/" NGINX_VERSION    #這裏修改的是軟件名稱,我將原有的nginx改成了IIS。
#修改後,保存退出便可
[root@nginx nginx-1.14.0]# vim src/http/ngx_http_header_filter_module.c   #編輯該文件
#修改前以下:
static u_char ngx_http_server_string[] = "Server: nginx" CRLF;     #第49行
#修改後以下:
static u_char ngx_http_server_string[] = "Server: IIS" CRLF;   #該IIS和前一個文件更改的最好一致。
#更改完成後,保存退出便可。
[root@nginx nginx-1.14.0]# vim src/http/ngx_http_special_response.c   #修改此配置文件,防止頁面出現錯誤時,回顯時帶着nginx和版本號
#修改前以下:
static u_char ngx_http_error_tail[] =     #在此以前有一行與此很是類似,注意區分,這行的error後面沒有build字樣。
"<hr><center>nginx</center>" CRLF           #第36行
"</body>" CRLF
"</html>" CRLF
#更改後以下:
static u_char ngx_http_error_tail[] =
"<hr><center>IIS</center>" CRLF       #將原有的nginx改成IIS
"</body>" CRLF
"</html>" CRLF
#更改完成後,保存退出便可
[root@nginx nginx-1.14.0]# useradd -M -s /sbin/nologin www   #建立nginx運行用戶
[root@nginx nginx-1.14.0]# ./configure --prefix=/usr/local/nginx1.14 --user=www --group=www --with-http_stub_status_module  --with-http_realip_module  --with-http_ssl_module --with-http_gzip_static_module  --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy  --http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre  --add-module=/usr/src/ngx_cache_purge-2.3  --with-http_flv_module --add-module=/usr/src/nginx-sticky-module --with-http_dav_module --with-http_addition_module --with-http_sub_module --with-http_mp4_module && make && make install
#編譯安裝
[root@nginx nginx-1.14.0]# ln -sf /usr/local/nginx1.14/sbin/nginx /usr/local/sbin/  #建立nginx命令軟鏈接
[root@nginx nginx-1.14.0]# mkdir -p /var/tmp/nginx/client      #建立存放臨時文件目錄
[root@nginx nginx-1.14.0]# nginx -t       #檢查配置文件
[root@nginx nginx-1.14.0]# nginx       #沒有錯誤後,啓動nginx
[root@nginx nginx-1.14.0]# netstat -anput | grep 80      #肯定80端口處於監聽狀態

命令行驗證http頭部的軟件名稱及版本號是否更改:css

[root@nginx conf]# curl -I 127.0.0.1     #訪問本機
HTTP/1.1 200 OK
Server: IIS/6.6             #OK,使咱們更改的名稱及版本
Date: Fri, 25 Oct 2019 00:10:17 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Fri, 25 Oct 2019 00:03:52 GMT
Connection: keep-alive
ETag: "5db23be8-264"
Accept-Ranges: bytes
[root@nginx conf]# curl -I 127.0.0.1/a.html       #訪問一個不存在的頁面
HTTP/1.1 404 Not Found
Server: IIS/6.6           #錯誤頁面回顯的信息,也是咱們更改的,OK
Date: Fri, 25 Oct 2019 00:11:07 GMT
Content-Type: text/html
Content-Length: 164
Connection: keep-alive

2、Nginx配置項優化
Nginx是master/worker結構:一個master進程,生成一個或多個worker進程。示意圖以下:
Nginx安裝配置防盜鏈及深度優化
master-worker設計模式主要包含兩個主要組件:master和worker,master維護着worker隊列,將請求下發到多個worker並執行,worker主要進行實際邏輯計算,並將結果返回給master。html

Nginx採用這種進程模型的好處在於採用獨立的進程,可讓互相之間不會影響,一個進程退出後,其餘進程還在工做,服務不會中斷,master進程則很快從新啓動新的worker進程。當worker發生異常時,會致使當前worker上的全部請求失敗,而不會影響到其餘worker進程。
接下來的全部配置參數都是在Nginx配置文件的全局中寫入

一、調整Nginx運行工做進程個數前端

[root@nginx ~]# vim /usr/local/nginx1.14/conf/nginx.conf    #編輯主配置文件
 worker_processes  4;    #通常設置爲CPU的核心或者核心數x2
  [root@nginx ~]# nginx -s reload          #重啓Nginx服務
  [root@nginx ~]# ps -ef | grep nginx | grep worker    #查看開啓的worker進程
  www      128282   6761  0 11:41 ?        00:00:00 nginx: worker process
  www      128283   6761  0 11:41 ?        00:00:00 nginx: worker process
  www      128284   6761  0 11:41 ?        00:00:00 nginx: worker process
  www      128285   6761  0 11:41 ?        00:00:00 nginx: worker process

二、Nginx運行CPU親和力java

[root@nginx ~]# vim /usr/local/nginx1.14/conf/nginx.conf   <!--編輯主配置文件-->
<!--若是是四核配置,應配置以下:-->
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
       <!--
上面是每一個核心開啓一個worker,若要每一個核心對應兩個worker,
則須要寫入:worker_cpu_affinity 0001 0010 0100 1000 0001 0010 0100 1000;
                                 -->
<!--  若是是八核配置,則應配置以下:  -->
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000
10000000;
worker_rlimit_nofile 65535;      <!--修改nginx最多能夠打開的文件數-->
         <!--   
        這個配置是指當一個nginx進程打開的最多文件描述數目,理論值應該是系統最多打開文件數(使用ulimit -n命令查看)與nginx進程相除,可是nginx分配請求並非那麼均勻,因此最好與命令ulimit -n獲得的值保持一致。
在上面指定了其值爲「65535」可是系統默認是1024,怎麼辦呢?  
                               -->
[root@docker ~]# ulimit -n       <!--肯定系統最對打開文件數-->
1024
<!--若是此時啓動nginx服務,是會出現異常的。-->
[root@docker ~]# vim /etc/security/limits.conf   <!--編輯此文件,以便修改系統默認的文件數-->
<!--在配置文件末尾增長如下字段 -->
*       soft    nofile  65535
*       hard    nofile  65535
<!--更改完成後,保存退出-->
[root@nginx conf]# su -      <!--從新登陸,以便生效-->
[root@nginx ~]# ulimit -n       <!-- 再次查看確認是否修改爲功-->
65535
[root@nginx ~]# nginx -s reload        <!--重啓nginx服務,以便配置生效-->

worker_processes最多開啓8個,8個以上的話性能不會再提高了,並且穩定性變得更低,因此8個進程足夠用了。
因爲接下來是對配置文件增長一些配置項,就直接寫配置項及解釋了

三、Nginx事件處理模型node

#配置文件修改以下:
events {
    use epoll;
    worker_connections  65535;
    multi_accept on;
}

nginx 採用 epoll 事件模型,處理效率高,work_connections 是單個 worker 進程容許客戶端最大鏈接數,這個數值通常根據服務器性能和內存來制定,Nginx服務器的實際併發量就是 worker 進程數乘以 work_connections,填入一個 65535,則表示其併發量能夠達到了65535 x 4 = 262140的一個併發量,一個網站的併發達到這麼大的數量,也算是一個大站了!
multi_accept 是告訴 nginx 收到一個新鏈接通知後接受盡量多的鏈接。mysql

注:接下來的全部配置都將在http{ }模塊中寫入。
四、開啓高效傳輸模式linux

http {
    include       mime.types;
    default_type  application/octet-stream;
         ........................#省略部份內容
    sendfile        on;        #此行默認開啓
    tcp_nopush     on;     #去掉此行開頭的註釋符號

上述配置的相關解釋以下:nginx

  • Include mime.types:媒體類型, include 只是一個在當前文件中包含另外一個文件內容的指令。
  • default_type application/octet-stream:默認媒體類型足夠。
  • sendfile on:開啓高效文件傳輸模式,sendfile 指令指定 nginx 是否調用 sendfile 函數來
  • 輸出文件,對於普通應用設爲 on,若是用來進行下載等應用磁盤 IO 重負載應用,可設置爲off,以平衡磁盤與網絡 I/O 處理速度,下降系統的負載。注意:若是圖片顯示不正常把這個改爲 off。
  • tcp_nopush on; 必須在 sendfile 開啓模式纔有效,防止網路阻塞,積極的減小網絡報文段的數量(告訴 nginx 在一個數據包裏發送全部頭文件,而不一個接一個的發送。)

五、鏈接超時時間
修改及增長下面的內容主要目的是保護服務器資源,CPU,內存,控制鏈接數,由於創建鏈接也是須要消耗資源的。

#在http{  }字段增長如下內容:
    keepalive_timeout  65;
    tcp_nodelay on;
    client_header_buffer_size 4k;
    open_file_cache max=102400 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 1;
    client_header_timeout 15;
    client_body_timeout 15;
    reset_timedout_connection on;
    send_timeout 15;
    server_tokens off;
    client_max_body_size 10m;
  • keepalived_timeout :客戶端鏈接保持會話超時時間,超過這個時間,服務器斷開這個連接;
  • tcp_nodelay:也是防止網絡阻塞,不過要包涵在 keepalived 參數纔有效;
  • client_header_buffer_size 4k:客戶端請求頭部的緩衝區大小,這個能夠根據你的系統分頁大小來設置,通常一個請求頭的大小不會超過 1k,不過因爲通常系統分頁都要大於 1k,因此這裏設置爲分頁大小。分頁大小能夠用命令 getconf PAGESIZE 取得;
  • open_file_cache max=102400 inactive=20s:這個將爲打開文件指定緩存,默認是沒有啓用的,max 指定緩存數量,建議和打開文件數一致,inactive 是指通過多長時間文件沒被請求後刪除緩存;
  • open_file_cache_valid 30s:這個是指多長時間檢查一次緩存的有效信息;
  • open_file_cache_min_uses 1:open_file_cache 指令中的 inactive 參數時間內文件的最少使用次數,若是超過這個數字,文件描述符一直是在緩存中打開的,如上例,若是有一個文件在 inactive 時間內一次沒被使用,它將被移除;
  • client_header_timeout 設置請求頭的超時時間。咱們也能夠把這個設置低些,若是超過這個時間沒有發送任何數據,nginx 將返回 request time out 的錯誤;
  • client_body_timeout :設置請求體的超時時間。咱們也能夠把這個設置低些,超過這個時間沒有發送任何數據,和上面同樣的錯誤提示;
  • reset_timeout_connection :告訴 nginx 關閉不響應的客戶端鏈接。這將會釋放那個客戶端所佔有的內存空間;
  • send_timeout :響應客戶端超時時間,這個超時時間僅限於兩個活動之間的時間,若是超過這個時間,客戶端沒有任何活動,nginx 關閉鏈接;
  • server_tokens: 並不會讓 nginx 執行的速度更快,但它能夠關閉在錯誤頁面中的 nginx 版本數字,這樣對於安全性是有好處的;
  • client_max_body_size 上傳文件大小限制。

六、fastcgi優化
Fastcgi (快速通用網關接口)是靜態服務和動態服務的一個接口,Cache表示寫入緩存區,Buffer表示讀取緩存區。

在生產環境中,還須要根據本身公司的網站來決定,是否須要開啓動態頁面的緩存功能,畢竟動態頁面變化比較快,大多數狀況下,咱們都不會開啓動態頁面的緩存。

#如下配置寫入在http{  }字段內
    fastcgi_connect_timeout 600;
    fastcgi_send_timeout 600;
    fastcgi_read_timeout 600;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    fastcgi_temp_path /usr/local/nginx1.10/nginx_tmp;
    fastcgi_intercept_errors on;
    fastcgi_cache_path /usr/local/nginx1.10/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128m inactive=1d max_size=10g;

上述配置項解釋以下:

  • fastcgi_connect_timeout 600:指定鏈接到後端 FastCGI 的超時時間;
  • fastcgi_send_timeout 600:向 FastCGI 傳送請求的超時時間;
  • fastcgi_read_timeout 600:指定接收 FastCGI 應答的超時時間;
  • fastcgi_buffer_size 64k:指定讀取 FastCGI 應答第一部分須要用多大的緩衝區,默認的緩衝區大小爲 fastcgi_buffers 指令中的每塊大小,能夠將這個值設置更小;
  • fastcgi_buffers 4 64k:指定本地須要用多少和多大的緩衝區來緩衝 FastCGI 的應答請求,若是一個 php 腳本所產生的頁面大小爲 256KB,那麼會分配 4 個 64KB 的緩衝區來緩存,若是頁面大小大於 256KB,那麼大於 256KB 的部分會緩存到fastcgi_temp_path 指定的路徑中,可是這並非好方法,由於內存中的數據處理速度要快於磁盤。通常這個值應該爲站點中 php腳本所產生的頁面大小的中間值,若是站點大部分腳本所產生的頁面大小爲 256KB,那麼能夠把這個值設置爲「8 32K」、「4 64k」等;
  • fastcgi_busy_buffers_size 128k:建議設置爲 fastcgi_buffers 的兩倍,表明繁忙時候的 buffer;
  • fastcgi_temp_file_write_size 128k:在寫入 fastcgi_temp_path 時將用多大的數據塊,默認值是 fastcgi_buffers 的兩倍,該數值設置小時若負載上來時可能報 502 Bad Gateway;
  • fastcgi_temp_path :緩存臨時目錄;
  • fastcgi_intercept_errors on:這個指令指定是否傳遞 4xx 和 5xx 錯誤信息到客戶端,或者容許nginx 使用 error_page 處理錯誤信息。注:靜態文件不存在會返回 404 頁面,可是 php 頁面則返回空白頁;
  • fastcgi_cache_path /usr/local/nginx1.10/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128m inactive=1d max_size=10g: fastcgi_cache 緩存目錄,能夠設置目錄層級,好比 1:2 會生成16*256 個子目錄,cache_fastcgi 是這個緩存空間的名字,cache 是用多少內存(這樣熱門的內容 nginx 直接放內存,提升訪問速度),inactive 表示默認失效時間,若是緩存數據在失效時間內沒有被訪問,將被刪除,max_size 表示最多用多少硬盤空間;
  • #注:如下配置項並無在上面的配置項寫入,可選:
  • fastcgi_cache cache_fastcgi:表示開啓 FastCGI 緩存併爲其指定一個名稱。開啓緩存能夠有效下降 CPU 的負載,而且防止 502 的錯誤放生。cache_fastcgi 爲 proxy_cache_path指令建立的緩存區名稱;
  • fastcgi_cache_valid 200 302 1h:用來指定應答代碼的緩存時間,實例中的值表示將 200 和302 應答緩存一小時,要和 fastcgi_cache 配合使用;
  • fastcgi_cache_valid 301 1d:將 301 應答緩存一天;
  • fastcgi_cache_valid any 1m:將其餘應答緩存爲 1 分鐘;
  • fastcgi_cache_min_uses 1:該指令用於設置通過多少次請求的相同 URL 將被緩存;
  • fastcgi_cache_key http://$host$request_uri :該指令用來設置web緩存的Key值,nginx根據Key值 md5 哈希存儲.通常根據$host(域名)、$request_uri(請求的路徑)等變量組合成proxy_cache_key ;
  • fastcgi_pass :指定 FastCGI 服務器監聽端口與地址,能夠是本機或者其它。

總結:

  1. nginx 的緩存功能有:proxy_cache / fastcgi_cache
  2. proxy_cache 的做用是緩存後端服務器的內容,多是任何內容,包括靜態的和動態。
  3. fastcgi_cache 的做用是緩存 fastcgi 生成的內容,不少狀況是 php 生成的動態的內容。
  4. proxy_cache 緩存減小了 nginx 與後端通訊的次數,節省了傳輸時間和後端寬帶。
  5. fastcgi_cache緩存減小了nginx與php的通訊的次數,更減輕了php和數據庫(mysql)的壓力。

七、gzip調優

#如下配置項在http{  }字段中寫入:
gzip on;
gzip_min_length 2k;
gzip_buffers 4 32k;
gzip_http_version 1.1;
gzip_comp_level 6;
gzip_types  text/plain  text/css  text/javascript  application/json  application/javascript application/x-javascript application/xml;
gzip_vary on;
gzip_proxied any;

gzip on:開啓壓縮功能;

  • gzip_min_length 1k:設置容許壓縮的頁面最小字節數,頁面字節數從 header 頭的Content-Length 中獲取,默認值是 0,無論頁面多大都進行壓縮,建議設置成大於 1K,若是小與 1K 可能會越壓越大;
  • gzip_buffers 4 32k:壓縮緩衝區大小,表示申請4個單位爲32K的內存做爲壓縮結果流緩存,默認值是申請與原始數據大小相同的內存空間來存儲 gzip 壓縮結果;
  • gzip_http_version 1.1:壓縮版本,用於設置識別 HTTP 協議版本,默認是 1.1,目前大部分瀏覽器已經支持 GZIP 解壓,使用默認便可;
  • gzip_comp_level 6:壓縮比例,用來指定 GZIP 壓縮比,1 壓縮比最小,處理速度最快,9 壓縮比最大,傳輸速度快,可是處理慢,也比較消耗 CPU 資源;
  • gzip_types text/css text/xml application/javascript:用來指定壓縮的類型,‘text/html’類型老是會被壓縮。
  • 默認值: gzip_types text/html (默認不對 js/css 文件進行壓縮)
  • #壓縮類型,匹配 MIME 類型進行壓縮
  • #不能用通配符 text/*
  • #(不管是否指定)text/html 默認已經壓縮
  • #設置哪壓縮種文本文件可參考 conf/mime.types
  • gzip_vary on:vary header 支持,該選項可讓前端的緩存服務器緩存通過 GZIP 壓縮的頁面,例如用 Squid 緩存通過 nginx 壓縮的數據

八、expires緩存調優
緩存,主要針對於圖片,css,js 等元素更改機會比較少的狀況下使用,特別是圖片,佔用帶寬大,咱們徹底能夠設置圖片在瀏覽器本地緩存 365d,css,js,html 能夠緩存個 10 來天,這樣用戶第一次打開加載慢一點,第二次,就很是快了!緩存的時候,咱們須要將須要緩存對象的擴展名列出來,Expires 緩存配置在 server 字段裏面。

server {
        listen       80;
        server_name  localhost;
                ................#省略部份內容
        location ~* \.(ico|jpe?g|gif|png|bmp|swf|flv)$ {
            expires 30d;
            log_not_found off;
            access_log off;
        }
        location ~* \.(js|css)$ {
            expires 7d;
            log_not_found off;
            access_log off;
        }
                ..........#省略部份內容
}
#注:log_not_found off:表示是否在 error_log 中記錄不存在的錯誤,默認on。

expire 功能優勢以下:
(1)expires 能夠下降網站購買的帶寬,節約成本,同時提高用戶訪問體驗;
(2)減輕服務的壓力,節約服務器成本,是 web 服務很是重要的功能。
expire 功能缺點以下:
(1)被緩存的頁面或數據更新了,用戶看到的可能仍是舊的內容,反而影響用戶體驗。 解決辦法: 第一個縮短緩存時間,例如:1 天,但不完全,除非更新頻率大於 1 天;第二個對緩存的對象更名;
(2)網站不但願被緩存的內容 :網站流量統計工具、更新頻繁的文件(網頁的logo)。

九、配置防盜鏈
防盜鏈的做用就是防止別人直接從你網站引用圖片等連接,消耗了咱們的資源和網絡流量,而咱們沒有獲得任何好處,吃力不討好。

解決辦法有如下幾種:
1:水印,品牌宣傳,你的帶寬,服務器足夠 ;
2:防火牆,直接控制,前提是你知道 IP 來源 ;
3:防盜鏈策略。

下面的方法是直接給予 404 的錯誤提示或者跳轉到指定提示頁面。

#如下配置寫在server{  }字段中:
        location ~* ^.+\.(jpg|gif|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
            valid_referers none blocked www.test.com test.com;    #該字段是指定容許跳轉訪問的域名
            if ($invalid_referer) {
            #return 302 http://www.test.com/img/nolink.png;   #該註釋的配置項表示能夠將其重定向到指定文件
            return 404;          #這裏是直接返回給客戶端狀態碼404
            break;
            }
            access_log off;         #關閉訪問日誌
          }
        location / {            #防盜鏈配置必須寫在全部location字段以前
            root   html;
            index  index.html index.htm;
        }
#在重定向到另外一個文件時,須要特別注意其後綴不能匹配防盜鏈規則,不然客戶端會獲得「重定向次數過多的」提示。
#我這裏先選擇返回狀態碼404

以上修改後的完整配置文件以下:

#user  nobody;
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

events {
    use epoll;
    worker_connections  65535;
    multi_accept on;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;

    sendfile        on;
    tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay on;
    client_header_buffer_size 4k;
    open_file_cache max=102400 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 1;
    client_header_timeout 15;
    client_body_timeout 15;
    reset_timedout_connection on;
    send_timeout 15;
    server_tokens off;
    client_max_body_size 10m;

    fastcgi_connect_timeout 600;
    fastcgi_send_timeout 600;
    fastcgi_read_timeout 600;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
    fastcgi_temp_path /usr/local/nginx1.10/nginx_tmp;
    fastcgi_intercept_errors on;
    fastcgi_cache_path /usr/local/nginx1.10/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128m inactive=1d max_size=10g;
    gzip  on;
    gzip_min_length 2k;
    gzip_buffers 4 32k;
    gzip_http_version 1.1;
    gzip_comp_level 6;
    gzip_types  text/plain  text/css  text/javascript  application/json  application/javascript application/x-javascript application/xml;
    gzip_vary on;
    gzip_proxied any;

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;
        location ~* ^.+\.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
            valid_referers none blocked 192.168.20.5 www.test.com;
            if ($invalid_referer) {
            return 302 http://192.168.20.5/img/nolink.png;
            #return 404;
            break;
            }
            access_log off;
          }
        location / {
            root   html;
            index  index.html index.htm;
        }
        location ~* \.(ico|jpe?g|gif|png|bmp|swf|flv)$ {
            expires 30d;
            log_not_found off;
            access_log off;
        }
        location ~* \.(js|css)$ {
            expires 7d;
            log_not_found off;
            access_log off;
        }
        ......................#省略後面的註釋內容

十、內核參數優化

[root@nginx conf]# vim /etc/sysctl.conf       #須要編輯的是此配置文件
#在末尾寫入如下配置項:
fs.file-max = 999999
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 10240 87380 12582912
net.ipv4.tcp_wmem = 10240 87380 12582912
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 40960
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
[root@nginx conf]# sysctl -p       #刷新,使內核修改生效,正常的話,會返回全部配置項
#刷新後,全部配置項都會以文件的形式寫入某個目錄下,能夠指定find命令進行查找驗證
#如要尋找「net.core.netdev_max_backlog」對應的文件,則能夠執行命令「find / -name netdev_max_backlog」進行查找
  • fs.file-max = 999999:這個參數表示進程(好比一個 worker 進程)能夠同時打開的最大句柄數,這個參數直線限制最大併發鏈接數,需根據實際狀況配置。
  • net.ipv4.tcp_max_tw_buckets = 6000 :這個參數表示操做系統容許 TIME_WAIT 套接字數量的最大值,若是超過這個數字,TIME_WAIT 套接字將馬上被清除並打印警告信息。該參數默認爲 180000,過多的 TIME_WAIT 套接字會使 Web 服務器變慢。
  • 注:主動關閉鏈接的服務端會產生 TIME_WAIT 狀態的鏈接
  • net.ipv4.ip_local_port_range = 1024 65000 :容許系統打開的端口範圍。
  • net.ipv4.tcp_tw_recycle = 1:啓用 timewait 快速回收。
  • net.ipv4.tcp_tw_reuse = 1:開啓重用。容許將 TIME-WAIT sockets 從新用於新的 TCP 鏈接。這對於服務器來講頗有意義,由於服務器上總會有大量 TIME-WAIT 狀態的鏈接。
  • net.ipv4.tcp_keepalive_time = 30:這個參數表示當 keepalive 啓用時,TCP 發送 keepalive 消息的頻度。默認是 2 小時,若將其設置的小一些,能夠更快地清理無效的鏈接。
  • net.ipv4.tcp_syncookies = 1 :開啓 SYN Cookies,當出現 SYN 等待隊列溢出時,啓用 cookies 來處理。
  • net.core.somaxconn = 40960 :web 應用中 listen 函數的 backlog 默認會給咱們內核參數的
  • net.core.somaxconn: 限制到 128,而 nginx 定義的 NGX_LISTEN_BACKLOG 默認爲 511,因此有必要調整這個值。
  • 注:對於一個 TCP 鏈接,Server 與 Client 須要經過三次握手來創建網絡鏈接.當三次握手成功後,咱們能夠看到端口的狀態由 LISTEN 轉變爲 ESTABLISHED,接着這條鏈路上就能夠開始傳送數據了.每個處於監聽(Listen)狀態的端口,都有本身的監聽隊列.監聽隊列的長度與如
  • somaxconn 參數和使用該端口的程序中 listen()函數有關;
  • somaxconn參數:定義了系統中每個端口最大的監聽隊列的長度,這是個全局的參數,默認值爲 128,對於一個常常處理新鏈接的高負載 web 服務環境來講,默認的 128 過小了。大多數環境這個值建議增長到 1024 或者更多。大的偵聽隊列對防止拒絕服務 DoS ***也會有
  • 所幫助。
  • net.core.netdev_max_backlog = 262144 :每一個網絡接口接收數據包的速率比內核處理這些包的速率快時,容許送到隊列的數據包的最大數目。
  • net.ipv4.tcp_max_syn_backlog = 262144 :這個參數標示 TCP 三次握手創建階段接受 SYN 請求隊列的最大長度,默認爲 1024,將其設置得大一些可使出現 Nginx 繁忙來不及 accept 新鏈接的狀況時,Linux 不至於丟失客戶端發起的鏈接請求。
  • net.ipv4.tcp_rmem = 10240 87380 12582912:這個參數定義了 TCP 接受緩存(用於 TCP 接受滑動窗口)的最小值、默認值、最大值。
  • net.ipv4.tcp_wmem = 10240 87380 12582912:這個參數定義了 TCP 發送緩存(用於 TCP 發送滑動窗口)的最小值、默認值、最大值。
  • net.core.rmem_default = 6291456:這個參數表示內核套接字接受緩存區默認的大小。
  • net.core.wmem_default = 6291456:這個參數表示內核套接字發送緩存區默認的大小。
  • net.core.rmem_max = 12582912:這個參數表示內核套接字接受緩存區的最大大小。
  • net.core.wmem_max = 12582912:這個參數表示內核套接字發送緩存區的最大大小。
  • net.ipv4.tcp_syncookies = 1:該參數與性能無關,用於解決 TCP 的 SYN 「gong擊」 。

十一、關於系統鏈接數的優化
linux系統中,open files的默認值 爲 1024,說明服務器只容許同時打開 1024 個文件,使用命令 ulimit -a 能夠查看當前系統的全部限制值,使用命令 ulimit -n 能夠查看當前的最大打開文件數。
新裝的 linux 默認只有 1024 ,在負載較大的服務器上,很容易遇到 error: too many open files。所以,須要將其改大。

[root@nginx core]# vim /etc/security/limits.conf     #修改此配置文件
#在文件的末尾增長如下字段:
*       soft    nofile  65535
*       hard    nofile  65535
*       soft    noproc  65535
*       hard    noproc  65535
#添加完成後,用戶需從新登陸,以便更改生效。
[root@nginx ~]# bash
[root@nginx ~]# ulimit -a     #查看是否生效

3、驗證上述優化及Nginx服務器壓力測試
一、測試防盜鏈功能:
準備兩臺服務器,一臺是剛纔優化的Nginx服務器,另外一臺隨意,能夠提供web功能便可。

剛纔優化過的Nginx服務器IP地址爲192.168.20.5,另外一臺服務器的IP地址爲:192.168.20.2。

1)Nginx服務器配置以下:

[root@nginx html]# ls         <!--nginx服務器的網頁根目錄以下-->
50x.html  index.html  test.png
[root@nginx html]# vim ../conf/nginx.conf        <!--其防盜鏈配置以下-->
    ......................#省略部份內容
location ~* ^.+\.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
            valid_referers none blocked 192.168.20.5 www.test.com;
            if ($invalid_referer) {
            #return 302 http://192.168.20.5/img/nolink.png;
            return 404;
            break;
            }
            access_log off;
          }
    ......................#省略部份內容
<!--根據其防盜鏈配置,客戶端若是經過另外一臺服務器提供的連接訪問該服務器的資源,將會獲得404狀態碼--> 
[root@nginx html]# nginx -s reload      #重啓Nginx服務器,使防盜鏈配置生效

2)第二臺服務器的網頁文件以下:

[root@daolian html]# cat index.html      #其超連接地址指向了第一臺Nginx服務器的test.png圖片
<a href="http://192.168.20.5/test.png">lianjie</a>

3)客戶端直接訪問Nginx服務器的話,會看到test.png的頁面以下:

Nginx安裝配置防盜鏈及深度優化
4)客戶端訪問第二臺服務器測試:
Nginx安裝配置防盜鏈及深度優化
點擊超連接後,會看到如下頁面:
Nginx安裝配置防盜鏈及深度優化
5)如今換另外一種防盜鏈規則,再次進行測試:

[root@nginx html]# vim ../conf/nginx.conf        #編輯其配置文件
        location ~* ^.+\.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {
            valid_referers none blocked 192.168.20.5 www.test.com;
            if ($invalid_referer) {
            return 302 http://192.168.20.5/img/nolink.png;     #將其重定向到img目錄下的nolink.png圖片
            #return 404;     #將返回404狀態碼註釋掉
            break;
            }
            access_log off;
          }
[root@nginx html]# nginx -s reload      #重啓使配置生效
[root@nginx img]# ls /usr/local/nginx1.14/html/img     #重定向的目錄下文件以下:
nolink.png

6)客戶端再次點擊超連接進行測試,會看到以下頁面:
Nginx安裝配置防盜鏈及深度優化
二、壓力測試
對網頁的靜態頁面和php動態頁面都進行壓力測試的話,須要安裝部署LNMP架構,這裏採用單臺部署的方式,部署過程請參考文檔:https://blog.51cto.com/14227204/2435795
,若只是用來作壓力測試,MySQL數據庫能夠不安裝。

部署LNMP架構過程略...

部署完成後,須要更改配置文件:

[root@nginx html]# vim ../conf/nginx.conf      #編輯主配置文件
#在server{  }字段中添加如下內容
location ~ \.php$ {
            root           html;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi.conf;
        }
[root@nginx html]# pwd
/usr/local/nginx1.14/html
[root@nginx html]# cat test.php      #網頁根目錄下test.php文件內容以下:
<?php
phpinfo();
?>

完成後,須要確保訪問192.168.20.5/test.php時能夠看到如下頁面:
Nginx安裝配置防盜鏈及深度優化
1)開始測試:

[root@nginx ~]# ab -c 500 -n 50000 127.0.0.1/index.html
#測試靜態頁面性能,一次請求500個數,共請求50000個數。
Requests per second:    2407.58 [#/sec] (mean)     #Nginx服務器的吞吐量
#咱們主要關注的是上述的返回信息,也就是Nginx服務器的吞吐量
#服務器性能越好,吞吐量越高
[root@nginx html]# ab -c 100 -n 1000 127.0.0.1/test.php    #根據服務器性能選擇相應的數值
相關文章
相關標籤/搜索