nginx之查漏補缺

nginx工做原理

nginx由核心和模塊組成，核心負責查找配置文件將客戶端請求映射到一個location中，location中所配置的每一個指令會啓動不一樣的模塊去完成相應的工做。

nginx模塊按功能區分有

    Handler（處理器模塊）：直接處理請求，而後輸出

    Filters（過濾器模塊）：對處理器模塊輸出的內容進行修改

    Proxies（代理器模塊）：與後端一些服務進行交互，實現服務代理和負載均衡等功能。

請求--->nginx內核--->handler模塊--->filters模塊--->http相應

nginx工做方式：有單工做進程和多工做進程

    單工做進程：除主進程外，還有工做進程，工做進程是單線程的。nginx默認是單進程模式

          主進程做用： 一、接收外界請求，並將請求交給工做進程處理

                 二、監控工做進程的運行狀態

    多工做進程：工做進程包含多個線程

nginx如何實現高併發和輕量級？

   nginx採用異步非阻塞的事件處理機制，由進程循環處理多個準備好的事件。以epoll爲例，未準備好的事件都會放入epoll中，只要有事件準備好，就會進行處理。而apache，每一個請求都會獨佔一個工做線程，當併發數到達幾千時，就同時有幾千的線程在處理請求了，佔用的內存很是大，線程的上下文切換帶來的cpu開銷也很大，性能就難以上去，同時這些開銷是徹底沒有意義的。 

nginx實現負載均衡

    nginx支持的調度算法：

        一、輪詢（默認）：根據配置文件中的順序，把請求依次分配到不一樣的後端服務器上

        二、weight：加權輪詢，weight值越大，分配到的訪問機率越高

upstream lzs.com {
    server 192.168.1.1 weight=2;
    server 192.168.1.2 weight=1;
    }

        三、ip_hash:同一個ip的訪客固定訪問同一個後端服務器，解決session共享問題

upstream lzs.com {
    ip_hash;
    server 192.168.1.1 ;
    server 192.168.1.2 ;
    }

  四、url_hash:同一個url的訪問定向到同一個後端服務器上，提升後端緩存服務器的效率，使用這種調度算法須要下載nginx的hash軟件包

  五、fair：根據後端服務器的相應時間來分配，相應時間短的優先分配，使用這種調度算法須要下載nginx的upstream_fair模塊

  六、least_conn：最少鏈接，Web請求會被轉發到鏈接數最少的服務器上。

 server指令除了指定後端服務器的ip和端口外，還能夠指定每一個服務器在負載均衡調度中的狀態，經常使用的狀態有：

    down：該server不參與負載均衡

    backup：當其餘server沒法相應請求時纔會使用這個server

upstream lzs.com {
    server 192.168.1.1;
    server 192.168.1.2 backup;
    }

    *當調度算法爲ip_hash時，狀態不能是backup

location匹配規則

    一、匹配分爲普通匹配和正則匹配，普通匹配又分爲精確匹配和最大前綴匹配。

    二、先匹配普通匹配，再匹配正則匹配

   三、正則匹配會覆蓋最大前綴匹配

    四、當普通 location 前面指定了「 ^~ 」時，該條匹配上時再也不須要繼續匹配

    五、當匹配上精確匹配時，再也不須要繼續匹配

  總結：匹配優先級：精確匹配>指定「^~」的普通匹配>正則匹配>最大前綴匹配

 例：

location / {......}    #最大前綴匹配，匹配以/開頭的url，但會被正則匹配覆蓋
location = / {......}    #精確匹配url=/，再也不繼續匹配
location ^~/img/ {……}    #匹配以/img/開頭的url，再也不繼續匹配
location ~ .*\.(gif|jpg|png)$ {……}    #匹配圖像文件

  此外，~：區分大小寫

    ~*：不區分大小寫

nginx代理部分中X-Real-IP和X-Forwarded-For的區別：

通常來講，X-Forwarded-For是用於記錄代理信息的，每通過一級代理(匿名代理除外)，代理服務器都會把此次請求的來源IP追加在X-Forwarded-For中

來自4.4.4.4的一個請求，header包含這樣一行

X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3

表明 請求由1.1.1.1發出，通過三層代理，第一層是2.2.2.2，第二層是3.3.3.3，而本次請求的來源IP4.4.4.4是第三層代理

而X-Real-IP，沒有相關標準，上面的例子，若是配置了X-Read-IP，可能會有兩種狀況

// 最後一跳是正向代理，可能會保留真實客戶端IPX-Real-IP: 1.1.1.1
// 最後一跳是反向代理，好比Nginx，通常會是與之直接鏈接的客戶端IPX-Real-IP: 3.3.3.3

通常來講，使用X-Forwarded-For效果更好，能夠記錄完整的代理鏈路

nginx中的proxy_pass後url是否加/的區別

一、location /test1/ { 
                proxy_pass http://test2; 
     }

二、location /test1/ { 
                proxy_pass http://test2/; 
     }

上面兩種配置，區別只在於proxy_pass轉發的路徑後是否帶 「/」 
狀況1：若是訪問url = http://test1/test/test.html，則被nginx代理後，請求路徑會便問http://test2/test/test.html，將test/ 做爲根路徑，請求test/路徑下的資源 

狀況2：若是訪問url = http://test1/test/test.html，則被nginx代理後，請求路徑會變爲 http://test2/test.html，直接訪問server的根資源 

nginx中proxy_pass和rewrite的區別

proxy_pass通常用於將請求重定向到定義好的後端服務器上，不支持正則表達式匹配

rewrite通常用於修改請求中域名後邊的除去傳遞的參數外的字符串，支持正則表達式匹配http://seanlook.com/a/we/index.php?id=1&u=str 只對/a/we/index.php重寫

詳細可參考博文http://blog.csdn.net/mchdba/article/details/50042387。

防盜鏈

盜鏈是指一個網站將其餘大網站的資源（如音樂、下載、圖片等）的地址放在本身的網站上，這樣沒有任何資源的網站利用了別的網站的資源來展現給瀏覽者，從而提升本身網站的訪問量，對於原網站，一方面損失了一大部分流量，另外一方面，還會加劇服務器的負擔。

防盜鏈原理：利用HTTP協議中的referer表頭字段，referer會記錄請求從哪裏連接過來的，經過referer跟蹤連接來源，一旦檢測到來源不是本站即進行阻止或者返回指定的頁面。

nginx中防盜鏈設置可參考博文http://blog.csdn.net/yuwenruli/article/details/8541952。