Nginx 壓縮傳輸

開(kāi)啟Gzip
gzip on;      

不壓縮臨界值，大于1K的才壓縮，一般不用改
gzip_min_length 1k;   

設(shè)置系統(tǒng)獲取幾個(gè)單位的緩存用于存儲(chǔ)gzip的壓縮結(jié)果數(shù)據(jù)流。4 16k 代表以 16k 為單位，按照原始數(shù)據(jù)大小以 16k 為單位的4倍申請(qǐng)內(nèi)存。
gzip_buffers 4 16k;

gzip_http_version 1.1;

范圍為1~9。1 壓縮比最小處理速度最快，9 壓縮比最大但處理最慢。壓縮越快越消耗cpu。
gzip_comp_level 2;

匹配MIME類型進(jìn)行壓縮，默認(rèn)"text/html" 類型是會(huì)被壓縮的。 此外，Nginx下的gzip默認(rèn)不壓縮javascript、圖片等靜態(tài)資源文件，可以通過(guò)gzip_types指定需要壓縮的MIME類型,非設(shè)置值則不進(jìn)行壓縮 
text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;

和http頭有關(guān)系，加個(gè)vary頭，給代理服務(wù)器用的，有的瀏覽器支持壓縮，有的不支持。因此，為避免浪費(fèi)不支持的也壓縮，需要根據(jù)客戶端的HTTP頭來(lái)判斷，是否需要壓縮。
gzip_vary on; 

使用curl命令測(cè)試gzip是否成功開(kāi)啟
curl -I -H "Accept-Encoding: gzip, deflate" "http://www.qcloud.com/example/"

fastCGI管理器配置

為FastCGI緩存指定一個(gè)文件路徑、目錄結(jié)構(gòu)等級(jí)、關(guān)鍵字區(qū)域存儲(chǔ)時(shí)間和非活動(dòng)刪除時(shí)間。levels參數(shù)設(shè)置緩存目錄的目錄分級(jí)以及子目錄的數(shù)量。fastcgi_cache緩存目錄，可以設(shè)置目錄哈希層級(jí)，比如2:2會(huì)生成256*256個(gè)字目錄，keys_zone是這個(gè)緩存空間的名字，cache是用多少內(nèi)存（這樣熱門(mén)的內(nèi)容nginx直接放內(nèi)存，提高訪問(wèn)速度），inactive表示默認(rèn)失效時(shí)間，max_size表示最多用多少硬盤(pán)空間，需要注意的是fastcgi_cache緩存是先寫(xiě)在fastcgi_temp_path再移到fastcgi_cache_path，所以這兩個(gè)目錄最好在同一個(gè)分區(qū)，從0.8.9之后可以在不同的分區(qū)，不過(guò)還是建議放同一分區(qū)。
fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m; 
fastcgi_temp_path /usr/local/nginx/fastcgi_temp_path

指定連接到后端FastCGI的超時(shí)時(shí)間
 fastcgi_connect_timeout 300;

向FastCGI傳送請(qǐng)求的超時(shí)時(shí)間，這個(gè)值是指已經(jīng)完成兩次握手后向FastCGI傳送請(qǐng)求的超時(shí)時(shí)間。
fastcgi_send_timeout 300;

接收FastCGI應(yīng)答的超時(shí)時(shí)間，這個(gè)值是指已經(jīng)完成兩次握手后接收FastCGI應(yīng)答的超時(shí)時(shí)間。
fastcgi_read_timeout 300;

指定讀取FastCGI應(yīng)答第一部分 需要用多大的緩沖區(qū)，這里可以設(shè)置為fastcgi_buffers指令指定的緩沖區(qū)大小，上面的指令指定它將使用1個(gè) 16k的緩沖區(qū)去讀取應(yīng)答的第一部分，即應(yīng)答頭，其實(shí)這個(gè)應(yīng)答頭一般情況下都很?。ú粫?huì)超過(guò)1k），但是你如果在fastcgi_buffers指令中指 定了緩沖區(qū)的大小，那么它也會(huì)分配一個(gè)fastcgi_buffers指定的緩沖區(qū)大小去緩存
fastcgi_buffer_size 16k;

指定本地需要用多少和多大的緩沖區(qū)來(lái) 緩沖FastCGI的應(yīng)答，如上所示，如果一個(gè)php腳本所產(chǎn)生的頁(yè)面大小為256k，則會(huì)為其分配16個(gè)16k的緩沖區(qū)來(lái)緩存，如果大于256k，增大 于256k的部分會(huì)緩存到fastcgi_temp指定的路徑中， 當(dāng)然這對(duì)服務(wù)器負(fù)載來(lái)說(shuō)是不明智的方案，因?yàn)閮?nèi)存中處理數(shù)據(jù)速度要快于硬盤(pán)，通常這個(gè)值 的設(shè)置應(yīng)該選擇一個(gè)你的站點(diǎn)中的php腳本所產(chǎn)生的頁(yè)面大小的中間值，比如你的站點(diǎn)大部分腳本所產(chǎn)生的頁(yè)面大小為 256k就可以把這個(gè)值設(shè)置為16 16k，或者4 64k 或者64 4k，但很顯然，后兩種并不是好的設(shè)置方法，因?yàn)槿绻a(chǎn)生的頁(yè)面只有32k，如果用4 64k它會(huì)分配1個(gè)64k的緩沖區(qū)去緩存，而如果使用64 4k它會(huì)分配8個(gè)4k的緩沖區(qū)去緩存，而如果使用16 16k則它會(huì)分配2個(gè)16k去緩存頁(yè)面，這樣看起來(lái)似乎更加合理。
fastcgi_buffers 16 16k;

默認(rèn)值是fastcgi_buffers的兩倍。
fastcgi_busy_buffers_size 16k;

在寫(xiě)入fastcgi_temp_path時(shí)將用多大的數(shù)據(jù)塊，默認(rèn)值是fastcgi_buffers的兩倍。
fastcgi_temp_file_write_size 16k;

開(kāi)啟FastCGI緩存并且為其制定一個(gè)名稱。個(gè)人感覺(jué)開(kāi)啟緩存非常有用，可以有效降低CPU負(fù)載，并且防止502錯(cuò)誤。但是這個(gè)緩存會(huì)引起很多問(wèn)題，因?yàn)樗彺娴氖莿?dòng)態(tài)頁(yè)面。具體使用還需根據(jù)自己的需求
fastcgi_cache TEST;

指定的應(yīng)答代碼指定緩存時(shí)間，如上例中將200，302應(yīng)答緩存一小時(shí)，301應(yīng)答緩存1天，其他為1分鐘。
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;

緩存在fastcgi_cache_path指令inactive參數(shù)值時(shí)間內(nèi)的最少使用次數(shù)，如上例，如果在5分鐘內(nèi)某文件1次也沒(méi)有被使用，那么這個(gè)文件將被移除。
fastcgi_cache_min_uses 1;

哪些類型的緩存失效。
fastcgi_cache_use_stale error timeout invalid_header http_500;

nginx緩沖區(qū)優(yōu)化(反向代理使用)
關(guān)于緩沖, 主要是合理設(shè)置緩沖區(qū)大小, 盡量避免緩沖到硬盤(pán)時(shí)的情況如果proxy_buffering關(guān)閉，那么nginx會(huì)立即把從后端收到的響應(yīng)內(nèi)容傳送給客戶端，每
次取的大小為proxy_buffer_size的大小，這樣效率肯定會(huì)比較低。 proxy_buffering啟用時(shí)，要提防使用的代理緩沖區(qū)太大。這可能會(huì)吃掉你的內(nèi)存，限制代理能夠支持的最大并發(fā)連接數(shù)。

后端服務(wù)器連接的超時(shí)時(shí)間_發(fā)起握手等候響應(yīng)超時(shí)時(shí)間
proxy_connect_timeout 20s; 

#連接成功后，后端服務(wù)器響應(yīng)時(shí)間(代理接收超時(shí))
proxy_read_timeout 20s;  

后端服務(wù)器數(shù)據(jù)回傳時(shí)間_就是在規(guī)定時(shí)間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù)
proxy_send_timeout 20s;

一次訪問(wèn)能寫(xiě)入的臨時(shí)文件的大小，默認(rèn)是 proxy_buffer_size 和 proxy_buffers 中設(shè)置的緩沖區(qū)大小的2倍，Linux下一般是8k。
proxy_temp_file_write_size 64k;

proxy_temp_path和proxy_cache_path指定的路徑必須在同一分區(qū)
proxy_cache_path 緩存文件路徑
levels 設(shè)置緩存文件目錄層次；levels=1:2 表示兩級(jí)目錄
keys_zone 設(shè)置緩存名字和共享內(nèi)存大小
inactive 在指定時(shí)間內(nèi)沒(méi)人訪問(wèn)則被刪除
max_size 最大緩存空間，如果緩存空間滿，默認(rèn)覆蓋掉緩存時(shí)間最長(zhǎng)的資源。
proxy_temp_path /xxx/proxy_temp_path;   緩存目錄
proxy_cache_path 
  /xxx/proxy_cache_path 
  levels=1:2 
  keys_zone=cache_one:2000m
  inactive=1d
  max_size=5m;

proxy_buffering開(kāi)啟的情況下，nignx會(huì)把后端返回的內(nèi)容先放到緩沖區(qū)當(dāng)中，然后再返回給客戶端(邊收邊傳，不是全部接收完再傳給客戶端)?？刂剖欠翊蜷_(kāi)后端響應(yīng)內(nèi)容的緩沖區(qū)，如果這個(gè)設(shè)置為off，那么proxy_buffers和proxy_busy_buffers_size這兩個(gè)指令將會(huì)失效。 但是無(wú)論proxy_buffering是否開(kāi)啟，對(duì)proxy_buffer_size都是生效的。
proxy_buffering on;

響應(yīng)頭的緩沖區(qū)，沒(méi)有必要也跟著設(shè)置太大。最好單獨(dú)設(shè)置，一般設(shè)置個(gè)4k就夠了。
proxy_buffer_size 4k; 

proxy_buffers的緩沖區(qū)大小一般會(huì)設(shè)置的比較大，以應(yīng)付大網(wǎng)頁(yè)。當(dāng)中單個(gè)緩沖區(qū)的大小是由系統(tǒng)的內(nèi)存頁(yè)面大小決定的，Linux系統(tǒng)中一般為4k。 proxy_buffers由緩沖區(qū)數(shù)量和緩沖區(qū)大小組成的?？偟拇笮閚umber*size。
proxy_buffers 8 1M;  // 高速傳輸
proxy_buffer 4 32k;  //  一般情況

proxy_busy_buffers_size不是獨(dú)立的空間，它是proxy_buffers和proxy_buffer_size的一部分。nginx會(huì)在沒(méi)有完全讀完后端響應(yīng)的時(shí)候就開(kāi)始向客戶端傳送數(shù)據(jù)，
所以它會(huì)劃出一部分緩沖區(qū)來(lái)專門(mén)向客戶端傳送數(shù)據(jù)(這部分的大小是由proxy_busy_buffers_size來(lái)控制的，建議為proxy_buffers中單個(gè)緩沖區(qū)大小的2倍)，
然后它繼續(xù)從后端取數(shù)據(jù)，緩沖區(qū)滿了之后就寫(xiě)到磁盤(pán)的臨時(shí)文件中。
proxy_busy_buffers_size 2M;  // 高速傳輸
proxy_busy_buffers_size 64k; //  一般情況

proxy_max_temp_file_size指定當(dāng)響應(yīng)內(nèi)容大于proxy_buffers指定的緩沖區(qū)時(shí), 寫(xiě)入硬盤(pán)的臨時(shí)文件的大小. 如果超過(guò)了這個(gè)值, Nginx將與Proxy服務(wù)器同步的傳遞內(nèi)容, 而不再緩沖到硬盤(pán)。某些請(qǐng)求的響應(yīng)過(guò)大,則超過(guò)buffers的部分將被緩沖到硬盤(pán)(緩沖目錄由_temp_path指令指定), 當(dāng)然這將會(huì)使讀取響應(yīng)的速度減慢, 影響用戶體驗(yàn). 可以使用proxy_max_temp_file_size指令關(guān)閉磁盤(pán)緩沖.
proxy_max_temp_file_size 0;

Nginx配置詳解

使用的用戶和組
user  www www;

指定工作衍生進(jìn)程數(shù)（一般等于CPU的總核數(shù)或總核數(shù)的兩倍）
worker_processes 8;

前方高能，請(qǐng)注意！下面分別是開(kāi)啟了8個(gè)內(nèi)核，8個(gè)進(jìn)程(如果需要開(kāi)啟16進(jìn)程，00000001 修改成00000001 00000010 代表第一個(gè)CPU內(nèi)核處理第一個(gè)和第二個(gè)進(jìn)程,有多少個(gè)進(jìn)程就寫(xiě)多少個(gè)數(shù)，每個(gè)數(shù)的第幾位代表對(duì)應(yīng)的第幾核）
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000;

下面這個(gè)指令是指當(dāng)一個(gè)nginx進(jìn)程打開(kāi)的最多文件描述符數(shù)目，理論值應(yīng)該是系統(tǒng)的最多打開(kāi)文件數(shù)（ulimit -n）與nginx進(jìn)程數(shù)相除，但是nginx分配請(qǐng)求并不是那么均勻，所以最好與ulimit -n（需要在Linux上調(diào)整這個(gè)數(shù)）的值保持一致。
worker_rlimit_nofile 204800;

使用epoll的I/O模型，用這個(gè)模型來(lái)高效處理異步事件
use epoll;

每個(gè)進(jìn)程允許的最多連接數(shù)，理論上每臺(tái)nginx服務(wù)器的最大連接數(shù)為worker_processes * worker_connections。
worker_connections 204800;

限制用戶上傳文件的大小
client_max_body_size 300m;

客戶端緩存文件的大小
client_body_buffer_size 128k;

客戶端請(qǐng)求內(nèi)容超時(shí)時(shí)間,1分鐘
client_body_timeout  600;

客戶端請(qǐng)求header頭信息的超時(shí)時(shí)間,1分鐘
client_header_timeout  600;

這個(gè)將為打開(kāi)文件指定緩存，默認(rèn)是沒(méi)有啟用的，max 指定緩存數(shù)量，建議和打開(kāi)文件數(shù)一致，inactive 是指經(jīng)過(guò)多長(zhǎng)時(shí)間文件沒(méi)被請(qǐng)求后刪除緩存。
open_file_cache max=65535 inactive=60s;

這個(gè)是指多長(zhǎng)時(shí)間檢查一次緩存的有效信息。
open_file_cache_valid 80s;

指令中的inactive參數(shù)時(shí)間內(nèi)文件的最少使用次數(shù)，如果超過(guò)這個(gè)數(shù)字，文件更改信息一直是在緩存中打開(kāi)的
open_file_cache_min_uses 1;

URI過(guò)長(zhǎng)或request header過(guò)大導(dǎo)致400錯(cuò)誤
#start
servername的哈希表大小 -- 客戶端請(qǐng)求頭緩沖區(qū)大小
server_names_hash_bucket_size 128k;

請(qǐng)求頭總長(zhǎng)度大于128k時(shí)使用large_client_header_buffers設(shè)置的緩存區(qū)。指令參數(shù)4為個(gè)數(shù)，128k為大小，申請(qǐng)4個(gè)128k。默認(rèn)是8k。,
large_client_header_buffers 4 128k;
#end
   
客戶端請(qǐng)求頭部的緩沖區(qū)大小，這個(gè)可以根據(jù)你的系統(tǒng)分頁(yè)大小來(lái)設(shè)置，一般一個(gè)請(qǐng)求的頭部大小不會(huì)超過(guò)1k，不過(guò)由于一般系統(tǒng)分頁(yè)都要大于1k，所以這里設(shè)置為分頁(yè)大小。分頁(yè)大小可以用命令getconf PAGESIZE取得
client_header_buffer_size 2k;
 
可以讓sendfile()發(fā)揮作用。sendfile()可以在磁盤(pán)和TCP socket之間互相拷貝數(shù)據(jù)(或任意兩個(gè)文件描述符)。Pre-sendfile是傳送數(shù)據(jù)之前在用戶空間申請(qǐng)數(shù)據(jù)緩沖區(qū)。之后用read()將數(shù)據(jù)從文件拷貝到這個(gè)緩沖區(qū)，write()將緩沖區(qū)數(shù)據(jù)寫(xiě)入網(wǎng)絡(luò)。sendfile()是立即將數(shù)據(jù)從磁盤(pán)讀到OS緩存。因?yàn)檫@種拷貝是在內(nèi)核完成的，sendfile()要比組合read()和write()以及打開(kāi)關(guān)閉丟棄緩沖更加有效。
sendfile on;

告訴nginx在一個(gè)數(shù)據(jù)包里發(fā)送所有頭文件，而不一個(gè)接一個(gè)的發(fā)送。就是說(shuō)數(shù)據(jù)包不會(huì)馬上傳送出去，等到數(shù)據(jù)包最大時(shí)，一次性的傳輸出去，這樣有助于解決網(wǎng)絡(luò)堵塞。tcp_nopush 這個(gè)參數(shù)只有 sendfile on 的時(shí)候才有用。
tcp_nopush on;

告訴nginx不要緩存數(shù)據(jù)，而是一段一段的發(fā)送--當(dāng)需要及時(shí)發(fā)送數(shù)據(jù)時(shí)，
就應(yīng)該給應(yīng)用設(shè)置這個(gè)屬性，這樣發(fā)送一小塊數(shù)據(jù)信息時(shí)就不能立即得到返回值。
tcp_nodelay 只在 keepalive 連接狀態(tài)中使用。
tcp_nodelay on;

http連接超時(shí)時(shí)間，默認(rèn)是60s，功能是使客戶端到服務(wù)器端的連接在設(shè)定的時(shí)間內(nèi)持續(xù)有效，當(dāng)出現(xiàn)對(duì)服務(wù)器的后繼請(qǐng)求時(shí)，該功能避免了建立或者重新建立連接。切記這個(gè)參數(shù)也不能設(shè)置過(guò)大！否則會(huì)導(dǎo)致許多無(wú)效的http連接占據(jù)著nginx的連接數(shù)，終nginx崩潰！在一般情況下，這個(gè)配置會(huì)減少網(wǎng)絡(luò)流量的消耗，減少請(qǐng)求連接數(shù)，例如用戶在瀏覽網(wǎng)頁(yè)的時(shí)候保持連接，減少連接數(shù)的開(kāi)銷。但是在高并發(fā)下，這個(gè)配置會(huì)直接影響NGINX的性能。相反，這個(gè)數(shù)調(diào)小可以提高并發(fā)數(shù)。
keepalive_timeout 60;

下面這個(gè)參數(shù)將為打開(kāi)文件指定緩存，默認(rèn)是沒(méi)有啟用的，max指定緩存數(shù)量，建議和打開(kāi)文件數(shù)一致，inactive是指經(jīng)過(guò)多長(zhǎng)時(shí)間文件沒(méi)被請(qǐng)求后刪除緩存。
open_file_cache max=204800 inactive=20s;

open_file_cache指令中的inactive參數(shù)時(shí)間內(nèi)文件的最少使用次數(shù)，如果超過(guò)這個(gè)數(shù)字，
文件描述符一直是在緩存中打開(kāi)的，如上例，如果有一個(gè)文件在inactive時(shí)間內(nèi)一次沒(méi)被使用，它將被移除
open_file_cache_min_uses 1;
  
下面這個(gè)是指多長(zhǎng)時(shí)間檢查一次緩存的有效信息。
open_file_cache_valid 30s;
  
隱藏響應(yīng)頭中的有關(guān)操作系統(tǒng)和web server（Nginx）版本號(hào)的信息，這樣對(duì)于安全性是有好處的。
server_tokens off;



另外，F(xiàn)astCGI自身也有一些配置需要進(jìn)行優(yōu)化，如果你使用php-fpm來(lái)管理FastCGI，可以修改配置文件中的以下值：
同時(shí)處理的并發(fā)請(qǐng)求數(shù)，即它將開(kāi)啟最多60個(gè)子線程來(lái)處理并發(fā)連接。
<value name="max_children">60</value>

最多打開(kāi)文件數(shù)。
<value name="rlimit_files">65535</value>

每個(gè)進(jìn)程在重置之前能夠執(zhí)行的最多請(qǐng)求數(shù)。
<value name="max_requests">65535</value>

參考文章
http://blog.csdn.net/mary881225/article/details/70173907
http://www.vpsee.com/2009/06/64mb-vps-optimize-nginx/