一. 負載均衡的作用有哪些？

1、轉(zhuǎn)發(fā)功能
按照一定的算法【權(quán)重、輪詢】，將客戶端請求轉(zhuǎn)發(fā)到不同應(yīng)用服務(wù)器上，減輕單個服務(wù)器壓力，提高
系統(tǒng)并發(fā)量。
2、故障移除
通過心跳檢測的方式，判斷應(yīng)用服務(wù)器當(dāng)前是否可以正常工作，如果服務(wù)器期宕掉，自動將請求發(fā)送到
其他應(yīng)用服務(wù)器。
3、恢復(fù)添加
如檢測到發(fā)生故障的應(yīng)用服務(wù)器恢復(fù)工作，自動將其添加到處理用戶請求隊伍中。

二. nginx實現(xiàn)負載均衡的分發(fā)策略

Nginx 的 upstream目前支持的分配算法：
1)、輪詢 ——1：1 輪流處理請求（默認）
每個請求按時間順序逐一分配到不同的應(yīng)用服務(wù)器，如果應(yīng)用服務(wù)器down掉，自動剔除，剩下的繼續(xù)輪詢。
2)、權(quán)重 ——you can you up通過配置權(quán)重，指定輪詢幾率，權(quán)重和訪問比率成正比，用于應(yīng)用服務(wù)器性能不均的情況。
3)、ip_哈希算法每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個應(yīng)用服務(wù)器，可以解決session共享
的問題

nginx做負載均衡實現(xiàn)的策略有哪些

輪詢（默認）
權(quán)重
ip_hash
fair(第三方插件）
url_hash（第三方插件）

nginx做負載均衡用到哪些模塊

• upstream 定義負載節(jié)點池。
• location 模塊 進行URL匹配。
• proxy模塊 發(fā)送請求給upstream定義的節(jié)點池。

負載均衡有那些實現(xiàn)方式

• 硬件負載
• HTTP重定向負載均衡
• DNS負載均衡
• 反向代理負載均衡
• IP層負載均衡
• 數(shù)據(jù)鏈路層負載均衡
  

nginx如何實現(xiàn)四層負載？

四層負載分為動態(tài)和靜態(tài)負載
Nginx的四層靜態(tài)負載均衡需要啟用ngx_stream_core_module模塊
默認情況下，ngx_stream_core_module是沒有啟用的，需要在安裝Nginx時，添加–with-stream配置

• 參數(shù)啟用
  配置HTTP負載均衡時，都是配置在http指令下，配置四層負載均衡，則是在stream指令下，結(jié)構(gòu)如下所示

stream {
upstream mysql_backend {
server 192.168.175.100:3306 max_fails=2 fail_timeout=10s weight=1;
least_conn;
}
server { #監(jiān)聽端口，默認使用的是tcp協(xié)議，如果需要UDP協(xié)議，則配置成listen 3307 udp;
listen 3307; #失敗重試 proxy_next_upstream on;
proxy_next_upstream_timeout 0;
proxy_next_upstream_tries 0; #超時配置 #配置與上游服務(wù)器連接超時時間，默認60s
proxy_connect_timeout 1s; #配置與客戶端上游服務(wù)器連接的兩次成功讀/寫操作的超時時間，如果超
時，將自動斷開連接 #即連接存活時間，通過它可以釋放不活躍的連接，默認10分鐘 proxy_timeout 1m;
#限速配置 #從客戶端讀數(shù)據(jù)的速率，單位為每秒字節(jié)數(shù)，默認為0，不限速 proxy_upload_rate 0; #從
上游服務(wù)器讀數(shù)據(jù)的速率，單位為每秒字節(jié)數(shù)，默認為0，不限速 proxy_download_rate 0; #上游服務(wù)器
proxy_pass mysql_backend;
}
}

使用Nginx的四層動態(tài)負載均衡有兩種方案：使用商業(yè)版的Nginx和使用開源的nginx-stream-upsyncmodule模塊。注意：四層動態(tài)負載均衡可以使用nginx-stream-upsync-module模塊，七層動態(tài)負載均
衡可以使用nginx-upsync-module模塊。

你知道的web服務(wù)有哪些？

• apache
• nginx
• IIS
• tomcat
• lighttpd
• weblogic

為什么要用nginx

• 跨平臺、配置簡單，非阻塞、高并發(fā)連接：處理2-3萬并發(fā)連接數(shù)，官方監(jiān)測能支持5萬并發(fā)，
• 內(nèi)存消耗小：開啟10個nginx才占150M內(nèi)存 ，nginx處理靜態(tài)文件好,耗費內(nèi)存少,
• 內(nèi)置的健康檢查功能：如果有一個服務(wù)器宕機，會做一個健康檢查，再發(fā)送的請求就不會發(fā)送到宕機的服務(wù)器了。重新將請求提交到其他的節(jié)點上。
• 節(jié)省寬帶：支持GZIP壓縮，可以添加瀏覽器本地緩存
• 穩(wěn)定性高：宕機的概率非常小
• 接收用戶請求是異步的

nginx的性能為什么比apache高？

nginx采用的是epoll模型和kqueue網(wǎng)絡(luò)模型，而apache采用的是select模型
舉一個例子來解釋兩種模型的區(qū)別：
菜鳥驛站放著很多快件，以前去拿快件都是短信通知你有快件，然后你去了之后，負責(zé)菜鳥驛站的人在
一堆快遞里幫你找，直到找到為止。
但現(xiàn)在菜鳥驛站的方式變了，他會發(fā)你一個地址，比如 3-3-5009. 這個就是第三個貨架的第三排，從做
往右第九個。
如果有幾百個人同時去找快遞，這兩種方式哪個更有效率，不言而喻。
之前還看到這個例子也比較形象：

假設(shè)你在大學(xué)讀書，住的宿舍樓有很多間房間，你的朋友要來找你。
select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。
而epoll版宿管大媽會先記下每位同學(xué)的房間號，
你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。
如果來了10000個人，都要找自己住這棟樓的同學(xué)時，select版和epoll版宿管大媽，誰的效率更高，不言自
明。
同理，在高并發(fā)服務(wù)器中，輪詢I/O是最耗時間的操作之一，select和epoll的性能誰的性能更高，同樣十分
明了

select 采用的是輪詢的方式來處理請求，輪詢的次數(shù)越多，耗時也就越多

epoll的組成

epoll的接口非常簡單，一共就三個函數(shù)：
1. int epoll_create(int size);
創(chuàng)建一個epoll的句柄，size用來告訴內(nèi)核這個監(jiān)聽的數(shù)目一共有多大。
這個參數(shù)不同于select()中的第一個參數(shù)，給出最大監(jiān)聽的fd+1的值。
需要注意的是，當(dāng)創(chuàng)建好epoll句柄后，它就是會占用一個fd值，在linux下如果查看/proc/進程id/fd/，
是能夠看到這個fd的，所以在使用完epoll后，必須調(diào)用close()關(guān)閉，否則可能導(dǎo)致fd被耗盡。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件注冊函數(shù)，它不同與select()是在監(jiān)聽事件時告訴內(nèi)核要監(jiān)聽什么類型的事件，
而是在這里先注冊要監(jiān)聽的事件類型。第一個參數(shù)是epoll_create()的返回值，
第二個參數(shù)表示動作，用三個宏來表示：
EPOLL_CTL_ADD：注冊新的fd到epfd中；
EPOLL_CTL_MOD：修改已經(jīng)注冊的fd的監(jiān)聽事件；
EPOLL_CTL_DEL：從epfd中刪除一個fd；
第三個參數(shù)是需要監(jiān)聽的fd，第四個參數(shù)是告訴內(nèi)核需要監(jiān)聽什么事
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int
timeout);
等待事件的產(chǎn)生，類似于select()調(diào)用。
參數(shù)events用來從內(nèi)核得到事件的集合，maxevents告之內(nèi)核這個events有多大，這個 maxevents的值不
能大于創(chuàng)建epoll_create()時的size，參數(shù)timeout是超時時間（毫秒，0會立即返回，-1將不確定，也
有說法說是永久阻塞）。
該函數(shù)返回需要處理的事件數(shù)目，如返回0表示已超時

nginx和apache的區(qū)別

Nginx
輕量級，采用 C 進行編寫，同樣的 web 服務(wù)，會占用更少的內(nèi)存及資源
抗并發(fā)，nginx 以 epoll and kqueue 作為開發(fā)模型，處理請求是異步非阻塞的，負載能力比
apache 高很多，而 apache 則是阻塞型的。在高并發(fā)下 nginx 能保持低資源低消耗高性能 ，而
apache 在 PHP 處理慢或者前端壓力很大的情況下，很容易出現(xiàn)進程數(shù)飆升，從而拒絕服務(wù)的現(xiàn)
象。
nginx 處理靜態(tài)文件好，靜態(tài)處理性能比 apache 高三倍以上
nginx 的設(shè)計高度模塊化，編寫模塊相對簡單
nginx 配置簡潔，正則配置讓很多事情變得簡單，而且改完配置能使用 -t 測試配置有沒有問題，
apache 配置復(fù)雜 ，重啟的時候發(fā)現(xiàn)配置出錯了，會很崩潰
nginx 作為負載均衡服務(wù)器，支持 7 層負載均衡
七層負載可以有效的防止ddos攻擊
nginx本身就是一個反向代理服務(wù)器，也可以左右郵件代理服務(wù)器來使用
Apache
apache 的 rewrite 比 nginx 強大，在 rewrite 頻繁的情況下，用 apache
apache 發(fā)展到現(xiàn)在，模塊超多，基本想到的都可以找到
apache 更為成熟，少 bug ，nginx 的 bug 相對較多
apache 對 PHP 支持比較簡單，nginx 需要配合其他后端用
apache 在處理動態(tài)請求有優(yōu)勢，nginx 在這方面是雞肋，一般動態(tài)請求要 apache 去做，nginx 適
合靜態(tài)和反向。
apache 仍然是目前的主流，擁有豐富的特性，成熟的技術(shù)和開發(fā)社區(qū)
兩者最核心的區(qū)別在于 apache 是同步多進程模型，一個連接對應(yīng)一個進程，而 nginx 是異步的，多個
連接（萬級別）可以對應(yīng)一個進程。
需要穩(wěn)定用apache，需要高性能用nginx

nginx常用的命令

啟動 nginx 。
停止 nginx -s stop 或 nginx -s quit 。
重載配置 ./sbin/nginx -s reload(平滑重啟) 或 service nginx reload 。
重載指定配置文件 .nginx -c /usr/local/nginx/conf/nginx.conf 。
查看 nginx 版本 nginx -v 。
檢查配置文件是否正確 nginx -t 。
顯示幫助信息 nginx -h 。

什么是反向代理，什么是正向代理，以及區(qū)別？

正向代理：
所謂的正向代理就是： 需要在用戶端去配置的。配置完再去訪問具體的服務(wù)，這叫正向代理
正向代理，其實是"代理服務(wù)器"代理了"客戶端"，去和"目標(biāo)服務(wù)器"進行交互。
正向代理的用途：

• 提高訪問速度
• 隱藏客戶真實IP
  反向代理：
  反向代理是 在服務(wù)端的，不需要訪問用戶關(guān)心。用戶訪問服務(wù)器A, A服務(wù)器是代理服務(wù)器，將用戶服務(wù)再轉(zhuǎn)發(fā)到服務(wù)器B.這就是反向代理
  反向代理的作用：
  1.緩存，將服務(wù)器的響應(yīng)緩存在自己的內(nèi)存中，減少服務(wù)器的壓力。
  2.負載均衡，將用戶請求分配給多個服務(wù)器。
  3.訪問控制

Squid、Varinsh、Nginx 有什么區(qū)別？

三者都實現(xiàn)緩存服務(wù)器的作用
Nginx本來是反向代理/web服務(wù)器，用了插件可以做做這個副業(yè)(緩存服務(wù)器)。但本身支持的特性
不是很多，只能緩存靜態(tài)文件
varinsh 和squid是專業(yè)的cache服務(wù)，而nginx這些需要使用第三方模塊
varnish本身在技術(shù)上的優(yōu)勢要高于squid，它采用了可視化頁面緩存技術(shù)。

在內(nèi)存的利用上，Varnis h比 Squid 具有優(yōu)勢，性能要比 Squid 高。
還有強大的通過 Varnish 管理端口，可以使用正則表達式快速、批量地清除部分緩存
Varnish 是內(nèi)存緩存，速度一流，但是內(nèi)存緩存也限制了其容量，緩存頁面和圖片一般是挺好的。

要做 cache 服務(wù)的話，我們肯定是要選擇專業(yè)的 cache 服務(wù)，優(yōu)先選擇Squid 或者 Varnish

nginx是如何處理http請求的

四個步驟：
讀取解析請求行；
讀取解析請求頭；
開始最重要的部分，即多階段處理

nginx把請求處理劃分成了11個階段，也就是說當(dāng)nginx讀取了請求行和請求頭之后，將請求封裝了結(jié)構(gòu)體ngx_http_request_t，然后每個階段的handler都會根據(jù)這個ngx_http_request_t，對請求進行處理，例如重寫uri，權(quán)限控制，路徑查找，生成內(nèi)容以及記錄日志等等；

最后將結(jié)果放回給客戶單。
也可以這么回答：

• 首先，Nginx 在啟動時，會解析配置文件，得到需要監(jiān)聽的端口與 IP 地址，然后在 Nginx 的Master 進程里面先初始化好這個監(jiān)控的Socket(創(chuàng)建 S ocket，設(shè)置 addr、reuse 等選項，綁定到
  指定的 ip 地址端口，再 listen 監(jiān)聽)。
• 然后，再 fork(一個現(xiàn)有進程可以調(diào)用 fork 函數(shù)創(chuàng)建一個新進程。由 fork 創(chuàng)建的新進程被稱為子進
  程 )出多個子進程出來。
• 之后，子進程會競爭 accept 新的連接。此時，客戶端就可以向 nginx 發(fā)起連接了。當(dāng)客戶端與
  nginx進行三次握手，與 nginx 建立好一個連接后。此時，某一個子進程會 accept 成功，得到這個
  建立好的連接的 Socket ，然后創(chuàng)建 nginx 對連接的封裝，即 ngx_connection_t 結(jié)構(gòu)體。
• 接著，設(shè)置讀寫事件處理函數(shù)，并添加讀寫事件來與客戶端進行數(shù)據(jù)的交換。
  最后，Nginx 或客戶端來主動關(guān)掉連接，到此，一個連接就壽終正寢了。

nginx虛擬主機有哪些？

基于域名的虛擬主機
基于端口的虛擬主機
基于IP的虛擬主機

Nginx 怎么實現(xiàn)后端服務(wù)的健康檢查

• 利用 nginx 自帶模塊 ngx_http_proxy_module 和 ngx_http_upstream_module 對后端節(jié)點做健康檢查
• 利用 nginx_upstream_check_module 模塊對后端節(jié)點做健康檢查。（推薦此方法）

nginx的優(yōu)化你都做過哪些？

.  gzip壓縮優(yōu)化
． expires緩存有還
． 網(wǎng)絡(luò)IO事件模型優(yōu)化
． 隱藏軟件名稱和版本號
． 防盜鏈優(yōu)化
． 禁止惡意域名解析
． 禁止通過IP地址訪問網(wǎng)站
． HTTP請求方法優(yōu)化
． 防DOS攻擊單IP并發(fā)連接的控制，與連接速率控制
. 嚴格設(shè)置web站點目錄的權(quán)限
. 將nginx進程以及站點運行于監(jiān)牢模式
. 通過robot協(xié)議以及HTTP_USER_AGENT防爬蟲優(yōu)化
. 配置錯誤頁面根據(jù)錯誤碼指定網(wǎng)頁反饋給用戶
. nginx日志相關(guān)優(yōu)化訪問日志切割輪詢，不記錄指定元素日志、最小化日志目錄權(quán)限
. 限制上傳到資源目錄的程序被訪問，防止木馬入侵系統(tǒng)破壞文件
. FastCGI參數(shù)buffer和cache配置文件的優(yōu)化
. php.ini和php-fpm.conf配置文件的優(yōu)化
. 有關(guān)web服務(wù)的Linux內(nèi)核方面深度優(yōu)化（網(wǎng)絡(luò)連接、IO、內(nèi)存等）
. nginx加密傳輸優(yōu)化（SSL）
. web服務(wù)器磁盤掛載及網(wǎng)絡(luò)文件系統(tǒng)的優(yōu)化
. 使用nginx cache

一： 配置文件中對優(yōu)化有明顯效果的：

1. worker_processes 8;
nginx 進程數(shù)，建議按照cpu 數(shù)目來指定，一般為它的倍數(shù) (如,2個四核的cpu計為8)。
2. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000
01000000 10000000;
為每個進程分配cpu，上例中將8 個進程分配到8 個cpu，當(dāng)然可以寫多個，或者將一個進程分配到多
個cpu。
3. worker_rlimit_nofile 65535;
這個指令是指當(dāng)一個nginx 進程打開的最多文件描述符數(shù)目，理論值應(yīng)該是最多打開文件數(shù)（ulimit
-n）與nginx 進程數(shù)相除，但是nginx 分配請求并不是那么均勻，所以最好與ulimit -n 的值保持一致。
現(xiàn)在在linux 2.6內(nèi)核下開啟文件打開數(shù)為65535，worker_rlimit_nofile就相應(yīng)應(yīng)該填寫
65535。這是因為nginx調(diào)度時分配請求到進程并不是那么的均衡，所以假如填寫10240，總并發(fā)量達到3-4萬
時就有進程可能超過10240了，這時會返回502錯誤。
4. use epoll
5. worker_connections 65535
每個進程允許的最多連接數(shù)， 理論上每臺nginx 服務(wù)器的最大連接數(shù)為
worker_processes*worker_connections。
6. keepalive_timeout 60;
7. client_header_buffer_size 4k;
客戶端請求頭部的緩沖區(qū)大小，這個可以根據(jù)你的系統(tǒng)分頁大小來設(shè)置，一般一個請求頭的大小不會超過1k
8. open_file_cache max=65535 inactive=60s;
這個將為打開文件指定緩存，默認是沒有啟用的，max 指定緩存數(shù)量，建議和打開文件數(shù)一致，
inactive 是指經(jīng)過多長時間文件沒被請求后刪除緩存。
9. open_file_cache_valid 80s;
這個是指多長時間檢查一次緩存的有效信息。
10. open_file_cache_min_uses 1;
open_file_cache 指令中的inactive 參數(shù)時間內(nèi)文件的最少使用次數(shù)，如果超過這個數(shù)字，文件
描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive 時間內(nèi)一次沒被使用，它將被移除。

nginx的session不同步怎么辦

我們可以采用ip_hash指令解決這個問題，如果客戶已經(jīng)訪問了某個服務(wù)器，當(dāng)用戶再次訪問時，會將該
請求通過哈希算法，自動定位到該服務(wù)器。即每個訪客固定訪問一個后端服務(wù)器，可以解決session的問
題。
其他辦法：那就是用spring_session+redis，把session放到緩存中實現(xiàn)session共享

nginx的常用模塊有哪些？

1、ngx_http_core_module #包括一些核心的http參數(shù)配置，對應(yīng)Nginx的配置為HTTP區(qū)塊部分
2、ngx_http_access_module #訪問控制模塊，用來控制網(wǎng)站用戶對Nginx的訪問
3、ngx_http_gzip_module #壓縮模塊，對Nginx返回的數(shù)據(jù)壓縮，屬于性能優(yōu)化模塊
4、ngx_http_fastcgi_module #FastCGI模塊，和 動態(tài)應(yīng)用相關(guān)的模塊，例如PHP5、ngx_http_proxy_module #Proxy代理模塊
6、ngx_http_upstream_module #負載均衡模塊，可以實現(xiàn)網(wǎng)站的負載均衡功能及節(jié)點的健康檢查
7、ngx_http_rewrite_module #URL地址重寫模塊
8、ngx_http_limit_conn_module #限制用戶并發(fā)連接數(shù)及請求數(shù)模塊（防止ddos）
9、ngx_http_limit_req_module #根據(jù)定義的key限制Nginx請求過程的速率
10、ngx_http_log_module #訪問日志模塊，以指定的格式記錄Nginx客戶訪問日志等信息
11、ngx_http_auth_basic_module #Web認證模塊，設(shè)置Web用戶通過賬號、密碼訪問Nginx
12、ngx_http_ssl_module #ssl模塊，用于加密的http連接，如https
13、ngx_http_stub_status_module #記錄Nginx基本訪問狀態(tài)信息等模塊

nginx各個版本的區(qū)別

Nginx官網(wǎng)提供了三個類型的版本
Mainline version：Mainline 是 Nginx 目前主力在做的版本，可以說是開發(fā)版
Stable version：最新穩(wěn)定版，生產(chǎn)環(huán)境上建議使用的版本
Legacy versions：遺留的老版本的穩(wěn)定版

nginx默認配置文件

在 nginx 的配置文件中，大概分為幾個區(qū)域：events {}、http {}、和沒有被 {}包裹的區(qū)域。而 http {} 中還有 server {}，以及 server {} 中的 location {}。結(jié)構(gòu)如下：

worker_processes 1;
events {
worker_connections 1024;
}
http {
...
server {
...
location {
...
}
}server {
...
}
}

沒有被 {} 包裹的部分為全局配置，如 worker_processes 1; 設(shè)置工作進程（子進程）數(shù)為 1
events {} 為 nginx 連接配置的模塊，如 worker_connections 1024; 設(shè)置每一個子進程最大允許連
接 1024 個連接
http {} 為 nginx http 核心配置模塊
server {} 為虛擬主機配置模塊，包括監(jiān)聽端口、監(jiān)聽域名等
location {} URI 匹配

location的規(guī)則

在 Nginx 的配置文件中，通常會用兩個常用的區(qū)塊(Block)來進行設(shè)置：
1.Server 區(qū)塊
2.Localtion 區(qū)塊
sever 區(qū)塊主要是真的主機的配置，比如配置主機的域名，IP，端口等內(nèi)容。當(dāng)然，在一個 Nginx 的配
置文件里面，我們是可以指定多個 Sever 區(qū)塊的配置的。
而 Location 區(qū)塊則是在 Sever 區(qū)塊里面，細分到針對不同的路徑和請求而進行的配置。因為一個站點中
的 URI 通常會非常多，所以在 Location 區(qū)塊設(shè)置這部分，你也是可以寫多個 Location 的配置的。

location optional_modifier location_match {
# 這個 {} 里面的配置內(nèi)容就是一個區(qū)塊 Block
}

上面的 optional_modifier 配置項是可以使用正則表達式的。常用的幾種如下:

留空。在留空的情況下，配置表示請求路徑由 location_match 開始。
= ，等于號還是非常容易理解的：就是請求路徑正好等于后面的 location_match 的值；跟第一項留空還
是有區(qū)別的。
~，飄號（注意是英文輸入的飄號）表示大小寫敏感的正則匹配。
~*表示大小寫不敏感的正則匹配。
^~ 表示這里不希望有正則匹配發(fā)生。

nginx 處理localtion區(qū)塊的順序

每一個請求進來 Nginx 之后，Nginx 就會選擇一個 Location 的最佳匹配項進行響應(yīng)，處理的具體流程
是逐一跟 location 的配置進行比對，這個步驟可以分為以下幾步：
先進行前綴式的匹配（也就是 location 的 optional_modifier 為空的配置）。

Nginx 其次會根據(jù) URI 尋找完全匹配的 location 配置（也就是 location 的 optional_modifier
為 = 的配置）.
如果還是沒有匹配到，那就先匹配 ^~ 配置，如果找到一個配置的話，則會停止尋找過程，直接返回響應(yīng)內(nèi)
容。
如果還是沒有找到匹配項的話，則會先進行大小寫敏感的正則匹配，然后再是大小不寫敏感的正則匹配

舉例子：

location = / {# = 等號配置符，只匹配 / 這個路由
}
location /data {
# 留空配置，會匹配有 /data 開始的路由，后續(xù)有匹配會往下匹配。
}
location ^~ /img/ {
# 注意 ^~ 配置，這里匹配到 /img/ 開始的話，直接就返回了。
}
location ~* .(png|gif|ico|jpg|jpeg)$ {
# 匹配以 png, gif, ico, jpg or jpeg 結(jié)尾的請求；這個通常用來設(shè)置圖片的請求響應(yīng)。
}

配置nginx防盜鏈

Nginx的防盜鏈原理是加入location項，用正則表達式過渡圖片類型文件，對于信任的網(wǎng)址可以正常使用，
對于不信任的網(wǎng)址則返回相應(yīng)的錯誤圖片，在源主機（bt.com）的配置文件中加入以下代碼：
vi /usr/local/nginx/conf/nginx.conf
location ~*\.(jpg|gif|swf)$ {
valid_referers none blocked *.test.com test.com;
if ($invalid_referer) {
rewrite ^/http://www.bt.com/error.png;
}
}
下面分析一下這段代碼：
~*\.(jpg|gif|swf)$：這段正則表達式表示匹配不區(qū)分大小寫，以.jpg或.gif或.swf結(jié)尾的文件。
valid_referers：設(shè)置信任的網(wǎng)站，可以正常使用圖片。
none：瀏覽器中referer為空的情況，這就是直接在瀏覽器訪問圖片。
blocked：瀏覽器中referer不可空的情況，但是值被代理或防火墻刪除了，這些值不以http://或
https://開頭。
后面的網(wǎng)站或者域名：referer中包含相關(guān)字符串的網(wǎng)址。
if語句：如果鏈接的來源域名不在valid_referers所列出的列表中，$invalid_referer為1，則執(zhí)行后
面的操作，即進行重寫或返回403頁面。
把圖片error.png放到源主機（bt.com）的工作目錄下。
ls /usr/local/nginx/html
50x.html index.html logo.jpg error.png
這是重啟服務(wù)器，重新訪問http://www.test.com/index.html，顯示的是被重寫的圖片。