https://www.jianshu.com/p/65892355cad5javascript
nginx配置多個服務器很簡單,複製 server, 修改ip,端口,和項目部署路徑便可php
nginx 配置文件安裝的 軟件庫
gcc、 openssl-devel、 pcre-devel和zlib-devel
1 安裝命令,注意 –with-http_stub_status_module 啓動了
Nginx 的 NginxStatus,用來監控狀態css
wget http://nginx.org/download/nginx-1.0.14.tar.gz
tar zxvf nginx-1.0.14.tar.gz
./configure --with-http_stub_status_module --prefix=/opt/nginx
cd nginx-1.0.14
make
2 配置的結構
main,主配置影響全部
event
http
server 指定主機端口
location 位置
upstream 負載均衡
3 模塊
Nginx的主模塊指令、
事件模塊指令、
HTTP核心模塊指令,
Http SSL模塊、
HttpGzip Static模塊
Http Addition模塊
4 真實配置html
user nobody nobody;
worker_processes 2;
error_log logs/error.log notice;
pid logs/nginx.pid;
worker_rlimit_nofile 65535;
events{
use epoll;
worker_connections 65536;前端
不用說都是主模塊指令
user 主模塊指令, 用戶和用戶組, nobody用戶
worker_processes , 進程數消耗10m內次
和cup數量相同
nobody linux 建立時自帶的 用戶名,沒有特權,誰都能用
error_log 錯誤日誌,就不重複了,6大級別,debug最多
debug、info、notice、warn、error、crit
worker_rlimit_nofile 綁定workder進程和cpu???,沒用處???
pid 指定pid存放的位置,解釋下pid,只記錄主進程號,
剛建立nginx沒有,啓動後自動保存,目錄是默認,可用修改就在這裏java
他的用處除了 用kill -9殺死nginx,還能夠經過pid
殺死進程
/data/logs/nginx.pid kill –QUIT `cat /data/logs/nginx.pid`,沒試過node
剩下的events 工做模式和 一個進程鏈接上限
use 事件模型指令, linux首選是epoll(這個最重要),標準的是select poll,
kqueue用在bsd上 ,共有 select、poll、kqueue、epoll、rtsig和/dev/polllinux
worker_connections 默認1024,可設置65536,
實際鏈接數 max_client最大是 =進程數乘以 單進程鏈接數,如反向代理則除以四
這個參數受到 liuxn 最大打開file的限制,執行ulimit -n65536就行了nginx
好博客地址:web
https://blog.csdn.net/wangbin_0729/article/details/82109693
BSD 系統伯克利系統,說白了就是unix 5 http的屬性說明 http{ include conf/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$gzip_ratio"'; log_format download '$remote_addr - $remote_user [$time_local] ' '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$http_range" "$sent_http_content_range"'; client_max_body_size 20m; client_header_buffer_size 32K; large_client_header_buffers 4 32k; Sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 60; client_header_timeout 10; client_body_timeout 10; 解釋一下 一堆超時和 文件大小的設置,都不用改 include 引入其餘文件,難道能夠是其餘 .conf??,的確如此例如是 * include /usr/local/nginx/conf/vhost/*;,裏面配置了 server{xxxx} default_type 默認二進制流 下面兩個超長的 是日誌的配置和解釋 log_format是Nginx的HttpLog模塊指令,用於指定Nginx日誌的輸出格式。main爲此日誌輸出格式的名稱,能夠在下面的access_log指令中引用。 client_max_body_size 一我的訪問 body大小 client_header_buffer_size 指定header大小 用於指定來自客戶端請求頭的headerbuffer大小。對於大多數請求,1K的緩衝區大小已經足夠,若是自定義了消息頭或有更大的Cookie,能夠增長緩衝區大小。這裏設置爲32K; large_client_header_buffers 用來指定客戶端請求中較大的消息頭的緩存最大數量和大小, 「4」爲個數,「128K」爲大小,最大緩存量爲4個128K; sendfile 參數用於開啓高效文件傳輸模式。將tcp_nopush和tcp_nodelay兩個指令設置爲on用於防止網絡阻塞; keepalive_timeout 設置客戶端鏈接保持活動的超時時間。在超過這個時間以後,服務器會關閉該鏈接; client_header_timeout 設置客戶端請求頭讀取超時時間。若是超過這個時間,客戶端尚未發送任何數據,Nginx將返回「Request time out(408)」錯誤; client_body_timeout 設置客戶端請求主體讀取超時時間。若是超過這個時間,客戶端尚未發送任何數據,Nginx將返回「Request time out(408)」錯誤,默認值是60; send_timeout 指定響應客戶端的超時時間。這個超時僅限於兩個鏈接活動之間的時間,若是超過這個時間,客戶端沒有任何活動,Nginx將會關閉鏈接。 7 gzip說的太好不用再解釋了,先查裝了模塊沒,用力在線實時壓縮流 HttpGzip模塊配置 下面配置Nginx的HttpGzip模塊。這個模塊支持在線實時壓縮輸出數據流。 看是否安裝了HttpGzip模塊: [root@vps ~]# /opt/nginx/sbin/nginx -V nginx version: nginx/1.0.14 built by gcc 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) configure arguments: --with-http_stub_status_module --with-http_gzip_static_module --prefix=/opt/nginx 經過/opt/nginx/sbin/nginx -V命令能夠查看安裝Nginx時的編譯選項,由輸出可知,咱們已經安裝了HttpGzip模塊。 下面是HttpGzip模塊在Nginx配置中的相關屬性設置: gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_http_version 1.1; gzip_comp_level 2; gzip_types text/plain application/x-javascript text/css application/xml; gzip_vary on; gzip用於設置開啓或者關閉gzip模塊,「gzip on」表示開啓GZIP壓縮,實時壓縮輸出數據流; gzip_min_length設置容許壓縮的頁面最小字節數,頁面字節數從header頭的Content-Length中獲取。默認值是0,無論頁面多大都進行壓縮。建議設置成大於1K的字節數,小於1K可能會越壓越大; gzip_buffers表示申請4個單位爲16K的內存做爲壓縮結果流緩存,默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果; gzip_http_version用於設置識別HTTP協議版本,默認是1.1,目前大部分瀏覽器已經支持GZIP解壓,使用默認便可; gzip_comp_level用來指定GZIP壓縮比,1 壓縮比最小,處理速度最快;9 壓縮比最大,傳輸速度快,但處理最慢,也比較消耗cpu資源; gzip_types用來指定壓縮的類型,不管是否指定,「text/html」類型老是會被壓縮的; gzip_vary選項可讓前端的緩存服務器緩存通過GZIP壓縮的頁面,例如用Squid緩存通過Nginx壓縮的數據。 而後負載均衡,虛擬主機和location的配置說明 負載均衡配置 下面設定負載均衡的服務器列表: 1 2 3 4 5 6 7 upstream cszhi.com{ ip_hash; server 192.168.8.11:80; server 192.168.8.12:80 down; server 192.168.8.13:8009 max_fails=3 fail_timeout=20s; server 192.168.8.146:8080; } upstream是Nginx的HTTP Upstream模塊,這個模塊經過一個簡單的調度算法來實現客戶端IP到後端服務器的負載均衡。 在上面的設定中,經過upstream指令指定了一個負載均衡器的名稱cszhi.com。這個名稱能夠任意指定,在後面須要的地方直接調用便可。 Nginx的負載均衡模塊目前支持4種調度算法,下面進行分別介紹,其中後兩項屬於第三方的調度方法。 輪詢(默認):每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端某臺服務器宕機,故障系統被自動剔除,使用戶訪問不受影響; Weight:指定輪詢權值,Weight值越大,分配到的訪問機率越高,主要用於後端每一個服務器性能不均的狀況下; ip_hash:每一個請求按訪問IP的hash結果分配,這樣來自同一個IP的訪客固定訪問一個後端服務器,有效解決了動態網頁存在的session共享問題; fair:比上面兩個更加智能的負載均衡算法。此種算法能夠依據頁面大小和加載時間長短智能地進行負載均衡,也就是根據後端服務器的響應時間來分配請求,響應時間短的優先分配。Nginx自己是不支持fair的,若是須要使用這種調度算法,必須下載Nginx的upstream_fair模塊; url_hash:按訪問url的hash結果來分配請求,使每一個url定向到同一個後端服務器,能夠進一步提升後端緩存服務器的效率。Nginx自己是不支持url_hash的,若是須要使用這種調度算法,必須安裝Nginx 的hash軟件包。 在HTTP Upstream模塊中,能夠經過server指令指定後端服務器的IP地址和端口,同時還能夠設定每一個後端服務器在負載均衡調度中的狀態。經常使用的狀態有: down:表示當前的server暫時不參與負載均衡; backup:預留的備份機器。當其餘全部的非backup機器出現故障或者忙的時候,纔會請求backup機器,所以這臺機器的壓力最輕; max_fails:容許請求失敗的次數,默認爲1。當超過最大次數時,返回proxy_next_upstream 模塊定義的錯誤; fail_timeout:在經歷了max_fails次失敗後,暫停服務的時間。max_fails能夠和fail_timeout一塊兒使用。 注意,當負載調度算法爲ip_hash時,後端服務器在負載均衡調度中的狀態不能是weight和backup。 2.5 server虛擬主機配置 下面介紹對虛擬主機的配置。 建議將對虛擬主機進行配置的內容寫進另一個文件,而後經過include指令包含進來,這樣更便於維護和管理。 1 2 3 4 5 6 7 server{ listen 80; server_name 192.168.8.18 cszhi.com; index index.html index.htm index.php; root /wwwroot/www.cszhi.com charset gb2312; access_log logs/www.ixdba.net.access.log main; server標誌定義虛擬主機開始,listen用於指定虛擬主機的服務端口,server_name用來指定IP地址或者域名,多個域名之間用空格分 開。index用於設定訪問的默認首頁地址,root指令用於指定虛擬主機的網頁根目錄,這個目錄能夠是相對路徑,也能夠是絕對路徑。Charset用於 設置網頁的默認編碼格式。access_log用來指定此虛擬主機的訪問日誌存放路徑,最後的main用於指定訪問日誌的輸出格式。 2.6 location URL匹配配置 URL地址匹配是進行Nginx配置中最靈活的部分。 location支持正則表達式匹配,也支持條件判斷匹配,用戶能夠經過location指令實現Nginx對動、靜態網頁進行過濾處理。使用location URL匹配配置還能夠實現反向代理,用於實現PHP動態解析或者負載負載均衡。 如下這段設置是經過location指令來對網頁URL進行分析處理,全部擴展名以.gif、.jpg、.jpeg、.png、.bmp、.swf結尾的靜態文件都交給nginx處理,而expires用來指定靜態文件的過時時間,這裏是30天。 1 2 3 4 location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ { root /wwwroot/www.cszhi.com; expires 30d; } 如下這段設置是將upload和html下的全部文件都交給nginx來處理,固然,upload和html目錄包含在/web/wwwroot/www.cszhi.com目錄中。 1 2 3 4 location ~ ^/(upload|html)/ { root /web/wwwroot/www.cszhi.com; expires 30d; } 在最後這段設置中,location是對此虛擬主機下動態網頁的過濾處理,也就是將全部以.jsp爲後綴的文件都交給本機的8080端口處理。 1 2 3 4 location ~ .*.php$ { index index.php; proxy_pass http://localhost:8080; } 2.7 StubStatus模塊配置 StubStatus模塊可以獲取Nginx自上次啓動以來的工做狀態,此模塊非核心模塊,須要在Nginx編譯安裝時手工指定才能使用此功能。 如下指令實指定啓用獲取Nginx工做狀態的功能。 1 2 3 4 5 6 location /NginxStatus { stub_status on; access_log logs/NginxStatus.log; auth_basic "NginxStatus"; auth_basic_user_file ../htpasswd; } stub_status設置爲「on」表示啓用StubStatus的工做狀態統計功能。access_log 用來指定StubStatus模塊的訪問日誌文件。auth_basic是Nginx的一種認證機制。auth_basic_user_file用來指定認證的密碼文件,因爲Nginx的auth_basic認證採用的是與Apache兼容的密碼文件,所以須要用Apache的htpasswd命令來生成密碼文件,例如要添加一個test用戶,可使用下面方式生成密碼文件: /usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd test 而後輸入兩次密碼後確認以後添加用戶成功。 要查看Nginx的運行狀態,能夠輸入http://ip/NginxStatus,輸入建立的用戶名和密碼就能夠看到Nginx的運行狀態: Active connections: 1 server accepts handled requests 34561 35731 354399 Reading: 0 Writing: 3 Waiting: 0 Active connections表示當前活躍的鏈接數,第三行的三個數字表示 Nginx當前總共處理了34561個鏈接, 成功建立次握手, 總共處理了354399個請求。最後一行的Reading表示Nginx讀取到客戶端Header信息數, Writing表示Nginx返回給客戶端的Header信息數 ,「Waiting」表示Nginx已經處理完,正在等候下一次請求指令時的駐留鏈接數。 在最後這段設置中,設置了虛擬主機的錯誤信息返回頁面,經過error_page指令能夠定製各類錯誤信息的返回頁面。在默認狀況下,Nginx會在主目錄的html目錄中查找指定的返回頁面,特別須要注意的是,這些錯誤信息的返回頁面大小必定要超過512K,否者會被ie瀏覽器替換爲ie默認的錯誤頁面。 1 2 3 4 5 6 7 error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
gzip 牛逼的地方在於壓縮後html,js,css變爲原來的1/3
Nginx開啓Gzip壓縮功能, 可使網站的css、js 、xml、html 文件在傳輸時進行壓縮,提升訪問速度, 進而優化Nginx性能! Web網站上的圖片,視頻等其它多媒體文件以及大文件,由於壓縮效果很差,因此對於圖片沒有必要支壓縮,若是想要優化,能夠圖片的生命週期設置長一點,讓客戶端來緩存。 開啓Gzip功能後,Nginx服務器會根據配置的策略對發送的內容, 如css、js、xml、html等靜態資源進行壓縮, 使得這些內容大小減小,在用戶接收到返回內容以前對其進行處理,以壓縮後的數據展示給客戶。這樣不只能夠節約大量的出口帶寬,提升傳輸效率,還能提高用戶快的感知體驗, 一箭雙鵰; 儘管會消耗必定的cpu資源,可是爲了給用戶更好的體驗仍是值得的。
通過Gzip壓縮後頁面大小能夠變爲原來的30%甚至更小,這樣,用戶瀏覽頁面的時候速度會快得多。Gzip 的壓縮頁面須要瀏覽器和服務器雙方都支持,實際上就是服務器端壓縮,傳到瀏覽器後瀏覽器解壓並解析。瀏覽器那裏不須要咱們擔憂,由於目前的巨大多數瀏覽器 都支持解析Gzip過的頁面。
這裏有nginx配置公鑰私鑰 https的 說明
http://www.javashuo.com/article/p-mthdykog-gx.html
其中
server 就是虛擬主機的意思
root 是指定項目的根目錄,適用與server和location。能夠指定多個,若是locaiton沒有指定,會往其外層的server或http中尋找繼承,
nginx中root指令的地址,實際上是替換了匹配後的url中的host。
nginx https
12.1. SSL工做流程
- 瀏覽器發送一個https的請求給服務器;
- 服務器要有一套數字證書,能夠本身製做(後面的操做會具體介紹),也能夠向組織申請,區別就是本身頒發的證書須要客戶端驗證經過,才能夠繼續訪問,而使用受信任的公司申請的證書,則不會彈出>提示頁面,這套證書其實就是一對公鑰和私鑰;
- 服務器會把公鑰傳輸給客戶端;
- 客戶端(瀏覽器)收到公鑰後,會驗證其是否合法有效,無效會有警告提醒,有效則會生成一串隨機數,並用收到的公鑰加密;
- 客戶端把加密後的隨機字符串傳輸給服務器;
- 服務器收到加密隨機字符串後,先用私鑰解密(公鑰加密,私鑰解密),獲取到這一串隨機數後,再用這串隨機字符串加密傳輸的數據(該加密爲對稱加密,所謂對稱加密,就是將數據和私鑰也就是這個隨機字符串>經過某種算法混合在一塊兒,這樣除非知道私鑰,不然沒法獲取數據內容);
- 服務器把加密後的數據傳輸給客戶端;
- 客戶端收到數據後,再用本身的私鑰也就是那個隨機字符串解密;
12.2 SSL 工做示意圖
12.3. 生成SSL密鑰對
cd /usr/local/nginx/conf
openssl genrsa -des3 -out tmp.key 2048
//key文件爲私鑰openssl rsa -in tmp.key -out admin.key
//轉換key,取消密碼rm -f tmp.key
openssl req -new -key admin.key -out admin.csr
//生成證書請求文件,須要拿這個文件和私鑰一塊兒生產公鑰文件openssl x509 -req -days 365 -in admin.csr -signkey admin.key -out admin.crt
// 這裏的admin.crt爲公鑰12.4. Nginx配置 SSL
vim /usr/local/nginx/conf/vhost/ssl.conf
//加入以下內容server { listen 443; server_name admin.com; index index.html index.php; root /data/wwwroot/admin.com; ssl on; ssl_certificate admin.crt; ssl_certificate_key admin.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; }
-t && -s reload
//若報錯unknown directive 「ssl」 ,須要從新編譯nginx,加上「--with-http_ssl_module」mkdir /data/wwwroot/aming.com
echo 「ssl test page.」>/data/wwwroot/admin.com/index.html