《老男孩Linux運維》筆記
隱藏Nginx軟件版本號
一般來說，軟件的漏洞都和版本有關。因此要盡量隱藏對訪問用戶顯示各類敏感信息，這樣惡意的用戶就很難猜到他攻擊的服務器所用的是否有特定漏洞的軟件，從而加強Web服務安全。
編輯nginx.conf配置文件，增加參數：
http {
? ? server_tokens off | on；
}
server_tokens默認是開啟的，且可放置于 http，server，location。
更改Nginx服務的默認用戶
1，直接修改配置文件nginx.conf：
user nginx；
2，直接在編譯Nginx軟件時指定編譯的用戶和組：
./configure --user=nginx --group-nginx
優化Nginx進程對應的配置
修改nginx.conf配置文件：
worker_process 4；
#建議設置為CPU核數，高并發場合可以考慮設置成 核數*2
上述參數調整的是Nginx服務的worker進程數，Nginx有Master進程和worker進程。Master為管理進程，真正處理用戶的是worker進程。
cat /proc/cpuinfo | grep processor | wc -l ? ?#查看CPU總核數；
cat /proc/cpuinfo | grep "physical id" | sort | uniq | wc -l ? ?#查看CPU個數；
也可使用 top 命令，按 1 即可顯示所有CPU核數；
優化綁定不同的Nginx進程到不同的CPU上
默認情況下，Nginx的多個進程有可能跑在某一個CPU或CPU的某一核上，導致Nginx進程使用硬件的資源不均。所以，盡可能地分配不同的Nginx進程給不同的CPU處理，達到充分有效利用硬件的多CPU多核資源的目的。
四核CPU配置參考：
vi /etc/nginx/nginx.conf
worker_processes 4；
worker_cpu_affinity 0001 0010 0100 1000； ? ?#CPU親和力參數
Nginx事件處理模型優化
Nginx的連接處理機制在不同的操作系統會采用不同的I/O模型，在Linux下，Nginx使用epoll的I/O多路復用模型，在FreeBSD中使用kqueue的I/O多路復用模型，在solaris中使用/dev/poll方式的I/O多路復用模型，在Windows中使用的是icop。
具體配置：
events {
? ? use epoll； ? ?#use是一個時間模塊指令，用來指定Nginx的工作模式，對于Linux內核，推薦使用epoll工作模式
}
#對于使用連接進程的方法，通常不需要進行任何設置，Nginx會自動選擇最有效的方法。
調整Nginx單個進程允許的客戶端最大連接數
這個控制連接的參數為worker_connections，它的值要根據服務器性能和程序的內存使用量來制定。
events {
? ? worker_connections 1024； ? ?#定義每個進程(process)的最大連接數，這個連接包括了所有連接，如代理服務器連接、客戶端的連接、實際的并發連接
}
#Nginx總并發連接 == worker * worker_connections
配置Nginx Worker進程最大打開文件數
events {
worker_rlimit_nofile ?65535； ? ?#最大打開文件數，可設置為系統優化后的ulimit -HSn的結果
}
開啟高效文件傳輸模式
設置參數：sendfile
sendfile()是作用與兩個文件描述符之間的數據拷貝，這個拷貝實在內核之中的，被稱為零拷貝。sendfile（）比read和write函數要高效很多，因為write和read函數要把數據拷貝到應用層再進行操作。
sendfile ?on|off
context: http，server，location，if in location
設置參數：tcp_nopush
激活或禁用Linux上的TCP_CORK socket選項，僅當開啟sendfile生效。允許把 http response和文件的開始部分放在一個文件里發布，其積極作用是減少網絡報文段的數量。
tcp_nopush on；
context： http，server，location
優化Nginx連接參數，調整連接超時時間
連接超時參數：Keepalive_timeout?
keep-alive可以使客戶端到服務器端已經建立的連接一致工作不退出，當服務器有持續請求時，keep-alive會使用已經建立的連接提供服務，從而避免服務器充縣建立新連接請求處理。
keepalive_timeout 60；
context：http，server，location
#用于設置客戶端連接保持會話的超時時間為60秒。超過這個時間，服務器會關閉該鏈接。
連接超時的作用：
將無用的連接設置為盡快超時，可保護系統資源（CPU、內存、磁盤）；
連接很多時，及時斷掉那些已經建立好但又長時間不做事的連接，以減少其占用的服務器資源。因為服務器維護連接也是消耗資源的；
黑客和惡意用戶攻擊網站，也會不斷地和服務器建立多個連接，消耗連接數但啥也不干，大量消耗服務器的資源，此時就應該及時斷掉這些惡意占用資源的連接；
LNMP環境中，如果用戶請求了動態服務，則Nginx就會建立連接，請求FastCGI服務以及后端的MySQL服務，此時這個Nginx連接就要設置一個超時時間，在用戶容忍的時間內返回數據，或者再多等一會后端服務返回數據，具體策略根據具體業務進行具體分析；
后端的FastCGI服務及MySQL服務也有對連接的超時控制。
設置參數：tcp_nodelay
默認情況下當數據發送時，內核并不會馬上發送，可能會等待更多的字節組成一個數據包，這樣可以提高I/O性能。但是，在每次只發送很少字節的業務場景中，使用tcp_nodelay功能，等待時間會比較長。
tcp_nodelay on；
context：http，server，location
設置參數：client_header_timeout
讀取客戶端請求頭數據的超時時間，如果超過這個時間，客戶端還沒有發送完整的header數據，服務器端將返回“Request time out（408）”錯誤。
client_header_timeout 20；
context：http，server
設置參數：client_body_timeout
讀取客戶端請求主體的超時時間，如果在這個超時時間內，客戶端沒有發送任何數據，Nginx將返回“Request time out（408）”錯誤。
client_body_timeout 60；
context：http，server，location
設置參數：send_timeout
指定響應客戶端的超時時間，為握手后的一個超時。如果超過這個時間，客戶端沒有任何活動，Nginx將會關閉連接。
send_timeout 60；
context：http，server，location
上傳文件大小的限制（動態應用）
參數：client_max_body_size
設置為 0 表示禁止檢查客戶端請求主體大小
client_max_body_size 8m；
context：http，server，location
FastCGI相關參數調優（配合PHP引擎動態服務）
FastCGI參數是配合Nginx向后請求PHP動態引擎服務的相關參數，這里指的是Nginx中的配置參數。
Nginx FastCGI常見參數：
請參考Module ngx_http_fastcgi_module(https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html)
fastcgi_pass ? ?#給FastCGI服務器設置地址；
fastcgi_index ? ?#設置一個將在 $fastcgi_scripts_name 變量結尾的URI之后添加的文件名；
fastcgi_param ? ?#設置一個應該傳遞給FastCGI服務器的參數，當且僅當fastcgi_param在當前級別上沒有定義指令時，這些指令將從上一級繼承；
fastcgi_next_upsteam ? ?#指定在哪種情況下將請求傳遞給下一個服務器；
fastcgi_connect_timeout ? ?#表示Nginx服務器和后端FastCGI服務器連接的超時時間，默認值為60秒，這個參數通常不要超過75秒；
fastcgi_send_timeout ? ?#設置Nginx允許FastCGI服務器端返回數據的超時時間，即在規定時間之內后端服務器必須傳完所有的數據。否則，Nginx將斷開這個連接；
fastcgi_read_timeout ? ?#設置Nginx從FastCGI服務器端讀取響應信息的超時時間，表示連接建立成功后，Nginx等待后端服務器的響應時間，是Nginx已經進入后端的排隊之中等候處理的時間；
fastcgi_buffer_size ? ?#這是Nginx FastCGI的緩沖區大小參數，設定用來讀取從FastCGI服務器端收到的第一部分響應信息的緩沖區大小，這里的第一部分通常會包含一個小的響應頭部；
fastcgi_buffers ? ?#設定用來讀取從FastCGI服務器端收到的響應信息的緩沖區大小和緩沖區數量；
proxy_busy_buffers_size ? ?#用于設置系統很忙時可以使用的proxy_buffers大小，官方推薦大小為proxy_buffers * 2；
fastcgi_busy_buffers_size ? ?#用于設置系統很忙時可以使用的fastcgi_buffers大小，官方推薦為 fastcgi_buffers * 2；
fastcgi_temp_file_write_size ? ?#FastCGI臨時文件大小；
fastcgi_cache cachename_nginx ? ?#表示開啟FastCGI緩存并為其指定一個名稱；
fastcgi_cache_path ? ?#fastcgi_cache緩存目錄；
fastcgi_cache_valid ? ?#用來指定應答代碼的緩存時間；
fastcgi_cache_min_uses ? ?#設置請求幾次之后響應將被緩存；
fastcgi_cache_use_stale ? ?#定義在哪些情況下使用過期緩存；
fastcgi_cache_key ? ?#定義fastcgi_cache的key；
配置Nginx gzip壓縮實現性能優化
Nginx gzip壓縮模塊提供了壓縮文件內容的功能，用戶請求的內容在發送到用戶客戶端之前，Nginx服務器會根據一些具體的策略實施壓縮，以節約網絡出口帶寬，同時加快數據傳輸效率，提升用戶體驗。
Nginx gzip壓縮的優點：
提升網站用戶體驗；
節約網站帶寬成本；
壓縮對象：
純文本內容壓縮比很高，如 html, js, css, xml等；
本壓縮的純文本文件必須要大于1KB，由于壓縮算法的特殊原因，極小的文件壓縮后可能反而變大；
圖片、媒體等文件盡量不要壓縮，因為這些文件大都經過壓縮，再壓縮很可能不會減小很多，或有可能增大，同時還要消耗系統資源；
參數介紹及配置：
gzip on；#壓縮功能
gzip_min_length ?1K；#允許壓縮的頁面最小字節數
gzip_buffers ?4 16K；#申請4個單位為16K的內存作為壓縮結果流緩存
gzip_http_version ?1.1；#http協議版本
gzip_comp_level ?5；#指定壓縮比，1壓縮比最小，處理速度最快；9壓縮比最大，傳輸速度最快，處理最慢
gzip_types ?text/html text/css；#指定壓縮類型，對應文件類型參考mime.types
gzip_vary on；#vary header支持
gzip效果查看：
Content-Encoding: gzip
Nginx expires緩存
expires 期限，Nginx expires的功能就是為用戶訪問的網站內容設定一個過期時間。
當用戶第一次訪問這些內容時，會把這些內容儲存在用戶瀏覽器本地，這樣用戶第二次及以后繼續訪問該網站時，瀏覽器會檢查加載已經緩存在用戶瀏覽器本地的內容，而不用去服務器下載，直到緩存的內容過期或被清除為止。
Nginx expires功能優點：
expires 可以降低網站的帶寬，節約成本；
加快用戶訪問網站的速度，提升用戶訪問體驗；
服務器請求降低，服務器壓力就減輕了，成本也會降低；
Nginx expires配置
1，根據文件擴展名進行判斷：
location ~ .*\.（gif|jpg|jpeg|png|bmp|swf）$
{
? ? expires ?2y；#當用戶訪問上述擴展名文件時，緩存相應的時間
}
location ~ .*\.（js|css）?$
{
expires 10d；
}
2，根據URI中的路徑（目錄）進行判斷：
location ~ ^/（images|static|media）/ {
? ? expires 50d；
}
Nginx expires效果檢查：
Expires： 緩存過期時間
Cache-Control：緩存總時間
Nginx expires功能缺點及解決方法：
當網站數據更新了，此時用戶端看到的可能還是舊的已經緩存的內容。
對于經常需要變動的文件，可縮短對象緩存時間；如百度首頁圖片根據一些節日換成節日相對應的圖片，所以設置這些圖片緩存期為一天；
當網站改版或更新時，可以在服務器將緩存的對象改名；
網站可能不希望被緩存的內容：
廣告圖片，用于廣告服務，都緩存了就不好控制展示了；
網站流量統計工具（js代碼），緩存了統計就不準了；
Nginx日志相關優化與安全
現在Nginx 日志已經自動輪詢了。
編寫腳本實現Nginx access日志輪詢
配置日志切割腳本：
vim cut_nginx_log.sh
cd /path/log/nginx && mv access.log access_$(date +%F -d -1days).log
tar -czf access_xx.gz access.xx.log
nginx -s reload
crontab -e
00 00 * * * /bin/sh /path/cut_nginx_log.sh
不記錄不需要的訪問日志
日志寫入太頻繁會消耗大量磁盤I/O，降低服務性能。
location ~ .*\.（js|jpg|css|png|gif）$ {
access_log off；
}
訪問日志權限
不需要在日志目錄上給Nginx用戶讀或寫許可，很多人沒注意這個問題，把權限直接給了Nginx用戶，這就成了安全隱患。
chown -R root:root ?/path/log/nginx
chmod -R 700 /path/log/nginx
我以前一直也是認為應該 nginx:nginx ?/path/log/nginx，但今天看到這，去測試了上述方法，可以寫入日志。查看nginx運行，原來nginx master process的UID是root，難怪難怪！
root? ? ? 68300? ? ? 1? 0 16:15 ? ? ? ?00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Nginx站點目錄及文件URL訪問控制
根據擴展名限制程序或文件訪問
利用Nginx配置禁止訪問上傳資源目錄下的PHP、Shell、Perl、Python程序文件，這樣用戶即使上傳了木馬文件也沒法執行，從而加強了網站的安全。
范例1，配置Nginx，禁止解析指定目錄下的指定程序：
location ~ ^/images/.*\.（php|py|sh|pl）$?
{
? deny all；
}
location ~ ^/static/.*\.（php|py|pl|sh）$
{
? deny all；
}
對上述目錄的限制必須放在Nginx處理PHP服務配置的前面：
#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_params;
#}
范例2，Nginx下配置禁止訪問 *.txt 和 *.doc文件：
location ~* \.(txt|doc)$
{
? ?if (-f ?$request_filename) {
? ? ? root /var/www；
? ? ? #rewrite... ?也可以重定向到某個URL
? ? ? break；
? ? }
}
location ~* \.(txt|doc)$
? root /var/www；
? deny all；
}
禁止訪問指定目錄下的所有文件和目錄
范例1，配置禁止訪問指定的單個或多個目錄：
location ~ ?^/(static)/ {
deny all；
}
location ~ ^/static ?{
deny all；
}
禁止訪問多個目錄：
location ~ ^/(static | js ) {
? ?deny all；
}
范例2，禁止訪問目錄并返回指定HTTP狀態碼：
location ?/admin/ {
return 404；
}
location /templates/ {
return 403；
}
限制網站來源IP訪問
范例1，禁止某目錄讓外界訪問，但允許某IP訪問該目錄，并支持PHP解析：
location ~ ^/secret/ {
allow 222.222.222.222；
deny all；
}
location ~ .*\.php$ {
?fastcgi_pass? 127.0.0.1:9000;
fastcgi_index? index.php;
fastcgi_param? SCRIPT_FILENAME? /scripts$fastcgi_script_name;
include? ? ? ? fastcgi_params;
}
范例2，限制指定IP或IP段訪問：
location / {
deny 192.168.10.10；
allow 192.168.1.0/24；
allow 10.1.1.0/16；
deny all;
}
Nginx做反向代理的時候可以限制客戶端IP
1，使用 if 來控制：
if （$remote_addr = 10.0.0.7） {
return 403;
}
if ( $remote_addr = 11.11.11.11 ) {
set $allow_access_root 'true'；
}
2，利用deny和allow只允許IP訪問：
location / {
root /var/www；
index index.php index.html；
allow 22.22.22.22;
deny all；
}
方法3，只拒絕某些IP訪問：
location ?/ {
root /var/www;
index index.html;
deny 11.11.11.11;
allow all;
}
注意：
1，deny一定要加一個IP，否則會直接跳轉403，不在往下執行，如果403默認頁實在同一域名下，會造成死循環訪問；
2，對于allow的IP段，從允許訪問的段位從小到大排列，如 127.0.0.0/24后面才是10.10.0.0/16；
3，以deny all結尾，表示除了上面允許的，其他都禁止；
配置Nginx，禁止非法域名解析訪問網站
Nginx如何防止用戶IP訪問網站，或惡意域名解析？
方法1，讓使用IP訪問網站的用戶，或惡意解析域名的用戶，收到501錯誤：
server {
listen 80 default_server；
server_name _；
return 501；
}
#配置文件里面沒有寫的虛擬主機都調到 default_server。
或重定向：
server {
listen 80 default_server；
server_name _；
rewrite ^(.*) ?http://www.baidu.com permanent；
}
發現域名惡意解析到服務器IP，在server標簽下添加以下代碼即可：
if ($host !~ ^www/\.zhang21/\.com$) {
rewrite ^(.*) http://www.baidu.com permanet;
}
default_server舉例：
利用default_server，將網站所有請求定向到維護頁面。
server {
? ? listen 80 default_server;
? ? server_name _;
? ? root /var/www;
? ? location / {
? ? ? ? rewrite ^(.*) /errot.html break;
? ? }
vim /var/www/errot.html
<html>
<style type="type/css">
h1{
? ? text-align: center;
? ? color: red;
}
</style>
<h1>網站維護中！</h1>
</html>
Nginx圖片及目錄防盜鏈解決方案
什么是資源盜鏈
簡單地說，就是某些不法網站未經許可，通過在其自身網站程序里非法調用其他網站的資源，然后在自己的網站上顯示這些調用的資源，達到填充自身網站的效果。
這一舉動不僅浪費了調用資源網站的網絡流量，還造成其他網站的帶寬及服務壓力吃緊。
網站資源被盜鏈，出現嚴重問題
某公司CDN源站流量沒有變化，但CDN加速那邊流量超了很多。這么大異常流量，全都是錢呀！
如何處理？
1，對IDC及CDN帶寬做監控報警；
2，經常查看網站流量，關注流量變化，關注異常流量；
3，對訪問日志作分析，迅速定位異常流量
常見防盜鏈解決方案的基本原理
根據HTTP referer 實現防盜鏈
在HTTP 協議中，有一個表頭字段叫 referer，使用URL格式來表示是哪里的鏈接用了當前網頁的資源。
通過referer 可以檢測訪問的來源網頁，如果是資源文件，可以跟蹤到顯示它的網頁地址，一旦檢測出來不是本站，馬上進行阻止。
HTTP referer 是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上 referer，高速服務器我是從哪個頁面過來的，服務器借此獲得一些信息用于處理。
根據cookie防盜鏈
通過加密技術變換訪問路徑實現盜鏈
Nginx Web服務實現防盜鏈
利用 referer，針對指定擴展名進行 rewrite或其他操作
location ~* ?\. （.jpg|gif|png|wma|wmv|mp3|zip|rar） {
valid_referers none blocked *.zhang21.com zhang21.com；
if ($invalid_referer) {
? ? rewrite xxxx；
? }
}
要根據實際情況進行域名防盜鏈設置！
利用referer，針對站點目錄過濾并返回錯誤碼
location /images {
? root ?/var/www；
? valid_referers none blocked *.zhang21.com zhang21.com；
? if ($invalid_referer) {
? ? return 403；
? }
}
NginxHttpAccessKeyModule實現防盜鏈介紹
如果download目錄下有一個file.rar文件，那對應的URI就是http://www.abc.com/download/file.rar，而使用了ngx_http_accesskey_module模塊后就變成了http://www.abc.com/download/file.rar?key=xxxxxxxxxxx。只有正確地給定了key的值，才能下載download目錄下的file.rar文件，而且key的值與用戶的IP相關，這樣可以避免被盜連。
在產品設計上解決盜鏈方案
可以為圖片等增加水印。
通過查看Nginx日志格式中的 $http_referer 變量，查看被盜鏈情況。在對應的日志文件中查看該變量的值，可以知曉 http_referer的信息。
Nginx錯誤頁面的優雅顯示
常見HTTP狀態碼此處略過！
為什么要配置錯誤頁面優雅顯示？
我們可以將404、403等錯誤信息重定向到網站首頁或其他指定的頁面，提升網站的用戶訪問體驗！
自定義的錯誤碼優雅頁面：
location / {
xxxxxxx；
error_page 403 /403.html； ? ?#當出現403錯誤時跳轉到優化后的頁面
error_page 500 503 504 /50x.html；
location = /50x.html {
? ? root /xxx/xxx/50x.html； ? ?#將50x頁面放到本地單獨目錄下進行顯示
? ? }
error_page 404 =200 /404200.jpg； ? ?#改變狀態碼并指定顯示內容
error_page 502 http://www.baidu.com； ? ?#錯誤碼重定向；
}
將錯誤狀態碼重定向到一個location：
location / {
? error_page 404 = @zhang；
}
location @zhang {
proxy_pass http://www.baidu.com；
}
Nginx站點目錄文件及目錄權限優化
單機LNMP環境目錄權限嚴格控制措施
為了保證網站不受木馬入侵，所有站點的目錄的用戶和組都為root，所有的目錄權限是是755，所有文件權限是644。
雖然這樣的權限可以防止黑客上傳修改站點文件，但這樣合法用戶便也沒有了上傳權限。
比較好的解決方法是將用戶上傳的文件等服務分離，這樣就可以進行安全授權了。不同的服務所在目錄的權限依據業務功能而不同！
嚴格控制Nginx目錄的訪問才能降低網站被入侵的風險！
Nginx反爬蟲優化
robots.txt機器人協議介紹
Robots協議（也稱為爬蟲協議、機器人協議），全稱是“網絡爬蟲排除標準”（Robots Exclusion Protocol），網站通過Robots協議告訴搜索引擎那些頁面可以抓取，那些頁面不能抓取。
robots.txt（統一小寫）是一種存放于網站根目錄下的ASCII編碼的文本文件，它通常告訴網絡搜索引擎的漫游器（又稱網絡蜘蛛），此網站中的哪些內容是不應被搜索引擎的漫游器獲取的，哪些是可以被漫游器獲取的。
robots.txt協議并不是一個規范，而只是約定俗成的，所以并不能保證網站的隱私。
robots.txt語法
User-Agent：*
Allow：
Disallow：
來看一下簡書的robots.txt：
Nginx反爬蟲優化配置
阻止下載協議代理：
if ($http_user_agent ~* LWP::Simple | BBBike | wget) {
return 403;
}
測試禁止不同的瀏覽器軟件訪問：
if （$http_user_agent ~* “Firefox|MSIE”）{
rewrite ^（.*） http://www.baidu.com；#如果瀏覽器為Firefox或IE，則跳轉
}
利用Nginx限制HTTP的請求方法
可以通過Nginx限制HTTP請求的方法來達到提升服務器安全的目的。
如，讓HTTP只能使用GET、HEAD和POST方法的配置：
if ($request_method ！~ ^(GET|HEAD|POST)$ {
return 501；
}
還可以加一層 location，更具體地限制文件名。
使用CDN做網站內容加速
什么是CDN？
CDN的全稱是 Content Delivery Network，中文意思是內容分發網絡。
簡單地講，通過現有的Internet中增加一層新的網絡架構，將網站的內容發布到最接近用戶的Cache服務器內，通過智能DNS負載均衡技術，判斷用戶的來源，讓用戶就近使用與服務器相同線路的帶寬訪問Cache服務器，取得所需的內容。
例如，北京電信用戶訪問北京電信Cache服務器上的內容，四川網通用戶訪問成都網通Cache服務器上的內容。這樣可以有效減少數據在網絡上傳輸的時間，提高訪問速度。
CDN是一套全國或全球的風不是緩存集群，其實質是通過職能DNS判斷用戶的來源地域及上網線路，為用戶選擇一個最接近用戶地域，以及和用戶上網線路相同的服務器節點。因為低于近，線路相同，所以可以大幅度提升用戶瀏覽網站的體驗。
CDN的價值：
省錢；
提升網站的用戶體驗；
可以阻擋大部分流量攻擊，如DDOS；
CDN的特點
CDN就是一個具備根據用戶區域和線路智能調度的風不是內存緩存集群。特點如下：
通過服務器內存緩存網站數據，提高了企業站點（尤其是含有大量圖片、視頻等的站點）的訪問速度，并大大提高企業站點的穩定性；
用戶根據智能DNS技術自動選擇最適合的Cache服務器，降低不同運營商之間互聯瓶頸造成的影響，實現了跨運營商的網絡加速，保證不同網絡中的用戶都能得到良好的訪問速度；
加快了訪問速度，減少了原站點的帶寬；
用戶訪問時從服務器的內存中讀取數據，分擔了網絡流量，同時減輕了原站點負載壓力；
使用CDN可以分擔源站的網絡流量，同時減輕源站的負載壓力，并降低黑客入侵及各種DDOS攻擊對網站的影響，保證網站有較好的服務質量；
使用CDN的基本要求
首先要說的是，不是所有的網站都可以一上來就能用CDN的。要加速的業務數據應該存在獨立的域名。如 pub.zhang21.com，業務內容圖片、附件、JS、CSS等靜態元素，這樣的靜態網站域名才能使用CDN。
將域名做CNAME（別名）
這個 pub.zhang21.com地址必須事先由CDN公司配置好的CDN公司的域名。
Nginx程序架構優化
“解耦” 是開發人員中流行的一個名詞，簡單地說就是把一堆程序代碼按照業務用途分開，然后提供服務。
例如，注冊登錄、上傳、下載、瀏覽、商品頁信息等都應該是獨立的程序服務，只不過在客戶端看來是一個整體而已。
分離的最佳方式是分別使用獨立的服務器，可以選擇改動程序或者在負載均衡器上配置（如Nginx），過濾請求，然后拋給后面對應的服務器。
如，根據擴展名分發。請求圖片就拋給圖片服務器；
根據URL路徑轉發，請求下載就交給下載服務器；
請求動態PHP處理的就交給動態處理器；
不符合以上要求的就交給默認服務器；
使用普通用戶啟動Nginx
為什么要讓Nginx服務使用普通用戶？
默認情況下，Nginx的Master進程使用的是root用戶，worker進程使用的是Nginx指定的普通用戶。
使用root用戶跑Nginx的Master進程有兩個最大問題：
管理權限必須是root，這就使得最小化分配權限原則遇到困難；
使用root跑Nginx服務，一旦網站出現漏洞，用戶就可以很容易地獲取服務器的root權限
給Nginx服務降權的解決方案
利用普通用戶user跑Nginx服務，給開發及運維設置普通賬號，只要與user同組即可管理Nginx，該方案解決了Nginx管理問題，放置root分配權限過大；
開發人員使用普通賬戶即可管理Nginx服務及站點下的程序和日志；
采取項目負責制度，誰處理誰負責；
給Nginx降權
通過Nginx -c 制定配置文件啟動Nginx
Nginx -c /home/user/nginx.conf
放置于user主目錄，然后新建 www，logs等文件夾，更改所屬組權限。
error_log /home/user/logs/error.log；
pid /home/user/logs/nginx.pid；
access_log /home/user/logs/access.log;
優點如下：
給Nginx服務降權，讓網站更安全；
·按用戶設置站點權限，使站點更獨立（無需虛擬化隔離）；
開發不需要用root即可完整管理服務及站點；
可實現責任劃分；
控制Nginx并發連接數量
ngx_http_limit_conn_module這個模塊用于限制每個定義的Key值的連接數，特別是單IP的連接數。
The ngx_http_limit_conn_module module is used to limit the number of connections per the defined key, in particular, the number of connections from a single IP address.
Not all connections are counted. A connection is counted only if it has a request processed by the server and the whole request header has already been read.
不是所有的連接數都會被計數，一個符合要求的連接是整個請求頭已經被讀取的連接。
limit_conn_zone參數：
limit_conn_zone key zone=name:size；
http
limit_conn參數：指定key最大連接數
limit_conn zone number；
http，server，location
配置文件：
http {
limit_conn_zone $binary_remote_addr zone=addr:10m;
...
server {
...
location /download/ {
limit_conn addr 1; ? ?#限制單IP的并發連接為1
}
控制客戶端請求Nginx的速率
The ngx_http_limit_req_module module (0.7.21) is used to limit the request processing rate per a defined key, in particular, the processing rate of requests coming from a single IP address. The limitation is done using the “leaky bucket” method.
用于限制每個IP訪問每個定義Key的請求速率。
limit_req_zone key zone=name:size rate=rate；
http
limit_req zone=name
http，server，location
舉例：
http {
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
...
server {
...
location /search/ {
limit_req zone=one burst=5;
}
重點
安全優化：隱藏Nginx軟件名及版本號；
性能加安全優化：連接超時參數及FastCGI相關參數調優；
性能優化：gzip壓縮功能即調試查看方法；
性能優化：expires緩存功能及調試查看方法；
安全優化：集群中各角色服務站點目錄權限控制策略；
安全優化：站點目錄下所有的文件和目錄訪問控制；
性能加安全優化：robots.txt協議及防怕從優化解決方案；
性能加安全優化：靜態資源防盜鏈解決方案；
用戶體驗優化：錯誤頁面優雅顯示方法；
安全優化：限制http請求方法；
性能加安全優化：CDN加速知識；
安全優化：普通用戶運行Nginx方案策略；
性能加安全優化：Nginx并發連接及請求速率控制；
