nginx心得

時間  2020-07-21
標籤 nginx 心得 欄目 Nginx 简体版
原文   原文鏈接

nginx簡介(參考百度)

Nginx (engine x) 是一個高性能的 HTTP和 反向代理web服務器，同時也提供了IMAP/POP3/SMTP服務。Nginx是由伊戈爾·賽索耶夫爲 俄羅斯訪問量第二的Rambler.ru站點（俄文：Рамблер）開發的，第一個公開版本0.1.0發佈於2004年10月4日。

其將源代碼以類BSD許可證的形式發佈，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。2011年6月1日，nginx 1.0.4發佈。javascript

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like 協議下發行。其特色是佔有內存少，併發能力強，事實上nginx的併發能力在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶
等。php

nginx安裝

  • 1.安裝編譯工具及庫文件
yum -y install make zlib zlib-devel gcc-c++ libtool  openssl openssl-devel
  • 2.安裝 PCRE
cd /usr/local/src/
wget http://downloads.sourceforge.net/project/pcre/pcre/8.35/pcre-8.35.tar.gz
  • 3.安裝Nginx
cd /usr/local/src/
wget http://nginx.org/download/nginx-1.6.2.tar.gz

參考（https://www.runoob.com/linux/...）css

nginx基本結構

高度模塊化的設計是 Nginx 的架構基礎。Nginx 服務器被分解爲多個模塊，每一個模塊就是一個功能模塊，只負責自身的功能，模塊之間嚴格遵循「高內聚，低耦合」的原則

  • 核心模塊

核心模塊是 Nginx 服務器正常運行必不可少的模塊，提供錯誤日誌記錄、配置文件解析、事件驅動機制、進程管理等核心功能。html

  • 標準 HTTP 模塊

標準 HTTP 模塊提供 HTTP 協議解析相關的功能，如：端口配置、網頁編碼設置、HTTP 響應頭設置等。前端

  • 可選 HTTP 模塊

可選 HTTP 模塊主要用於擴展標準的 HTTP 功能，讓 Nginx 能處理一些特殊的服務，如：Flash 多媒體傳輸、解析 GeoIP 請求、SSL 支持等。java

  • 郵件服務模塊

郵件服務模塊主要用於支持 Nginx 的郵件服務，包括對 POP3 協議、IMAP 協議和 SMTP 協議的支持。node

  • 第三方模塊

第三方模塊是爲了擴展 Nginx 服務器應用，完成開發者自定義功能，如：Json 支持、Lua 支持等。
參考（https://www.sohu.com/a/230364...）linux

nginx基本功能

  • web服務器、反向代理服務器
  • 負載均衡
  • 動靜分離

nginx優勢

  • 1.能夠高併發鏈接

官方測試Nginx可以支撐5萬併發鏈接，實際生產環境中能夠支撐2~4萬併發鏈接數。nginx

緣由，主要是Nginx使用了最新的epoll（Linux2.6內核）和kqueue（freeBSD）網路I/O模型，而Apache使用的是傳統的Select模型，其比較穩定的Prefork模式爲多進程模式，須要常常派生子進程，因此消耗的CPU等服務器資源，要比Nginx高不少。
  • 2.內存消耗少

Nginx+PHP（FastCGI）服務器，在3萬併發鏈接下，開啓10個Nginx進程消耗150MB內存，15MB*10=150MB，開啓的64個PHP-CGI進程消耗1280內存，20MB*64=1280MB，加上系統自身消耗的內存，總共消耗不到2GB的內存。c++

若是服務器的內存比較小，徹底能夠只開啓25個PHP-CGI進程，這樣PHP-CGI消耗的總內存數才500MB。
  • 3.成本低廉

購買F5BIG-IP、NetScaler等硬件負載均衡交換機，須要十多萬到幾十萬人民幣，而Nginx爲開源軟件，採用的是2-clause BSD-like協議，能夠免費試用，而且可用於商業用途。

BSD開源協議是一個給使用者很大自由的協議，協議指出能夠自由使用、修改源代碼、也能夠將修改後的代碼做爲開源或專用軟件再發布。
  • 4.配置文件很是簡單

網絡和程序同樣通俗易懂，即便，非專用系統管理員也能看懂。

  • 5.支持Rewrite重寫

可以根據域名、URL的不一樣，將http請求分到不一樣的後端服務器羣組。

  • 6.內置的健康檢查功能

若是NginxProxy後端的某臺Web服務器宕機了，不會影響前端的訪問。

  • 7.節省帶寬

支持GZIP壓縮，能夠添加瀏覽器本地緩存的Header頭。

  • 8.穩定性高

用於反向代理，宕機的機率微乎其微。

  • 9.支持熱部署

Nginx支持熱部署，它的自動特別容易，而且，幾乎能夠7天*24小時不間斷的運行，即便，運行數個月也不須要從新啓動，還可以在不間斷服務的狀況下，對軟件版本進行升級。

nginx缺點

  • 1.動態處理差：nginx處理靜態文件好,耗費內存少，可是處理動態頁面則很雞肋，如今通常前端用nginx做爲反向代理抗住壓力，apache做爲後端處理動態請求。
  • 2.rewrite弱：雖然nginx支持rewrite功能，可是相比於Apache來講，Apache比nginx 的rewrite 強大。
  • 3.Nginx僅能支持http、https和Email協議，這樣就在適用範圍上面小些，這個是它的缺點
  • 4.對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測不支持Session的直接保持，但能經過ip_hash來解決

nginx配置

  • 全局
#Nginx的worker進程運行用戶以及用戶組
#user  nobody nobody;
#Nginx開啓的進程數
worker_processes  1;
#worker_processes auto;
#如下參數指定了哪一個cpu分配給哪一個進程，通常來講不用特殊指定。若是必定要設的話，用0和1指定分配方式.
#這樣設就是給1-4個進程分配單獨的核來運行，出現第5個進程是就是隨機分配了。eg:
#worker_processes 4     #4核CPU 
#worker_cpu_affinity 0001 0010 0100 1000;
nets    
#定義全局錯誤日誌定義類型，[debug|info|notice|warn|crit]
#error_log  logs/error.log  info;
#指定進程ID存儲文件位置
#pid        logs/nginx.pid;
#一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（ulimit -n）與nginx進程數相除，可是nginx分配請求並非那麼均勻，因此最好與ulimit -n的值保持一致。
#vim /etc/security/limits.conf
#  *                soft    nproc          65535
#  *                hard    nproc          65535
#  *                soft    nofile         65535
#  *                hard    nofile         65535
worker_rlimit_nofile 65535;
  • events 事件配置
events {
    #use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內核中的高性能網絡I/O模型，若是跑在FreeBSD上面，就用kqueue模型。
    use epoll;
    #每一個進程能夠處理的最大鏈接數，理論上每臺nginx服務器的最大鏈接數爲worker_processes*worker_connections。理論值：worker_rlimit_nofile/worker_processes
    #注意：最大客戶數也由系統的可用socket鏈接數限制（~ 64K），因此設置不切實際的高沒什麼好處
    worker_connections  65535;    
    #worker工做方式：串行（必定程度下降負載，但服務器吞吐量大時，關閉使用並行方式）
    #multi_accept on; 
}
  • http參數
#文件擴展名與文件類型映射表
    include mime.types;
    #默認文件類型
    default_type application/octet-stream;
 
#日誌相關定義
    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';
    #定義日誌的格式。後面定義要輸出的內容。
    #1.$remote_addr 與$http_x_forwarded_for 用以記錄客戶端的ip地址；
    #2.$remote_user ：用來記錄客戶端用戶名稱；
    #3.$time_local ：用來記錄訪問時間與時區；
    #4.$request  ：用來記錄請求的url與http協議；
    #5.$status ：用來記錄請求狀態； 
    #6.$body_bytes_sent ：記錄發送給客戶端文件主體內容大小；
    #7.$http_referer ：用來記錄從那個頁面連接訪問過來的；
    #8.$http_user_agent ：記錄客戶端瀏覽器的相關信息
    #鏈接日誌的路徑，指定的日誌格式放在最後。
    #access_log  logs/access.log  main;
    #只記錄更爲嚴重的錯誤日誌，減小IO壓力
    error_log logs/error.log crit;
    #關閉日誌
    #access_log  off;
 
    #默認編碼
    #charset utf-8;
    #服務器名字的hash表大小
    server_names_hash_bucket_size 128;
    #客戶端請求單個文件的最大字節數
    client_max_body_size 8m;
    #指定來自客戶端請求頭的hearerbuffer大小
    client_header_buffer_size 32k;
    #指定客戶端請求中較大的消息頭的緩存最大數量和大小。
    large_client_header_buffers 4 64k;
    #開啓高效傳輸模式。
    sendfile on;
    #防止網絡阻塞
    tcp_nopush on;
    tcp_nodelay on;    
    #客戶端鏈接超時時間，單位是秒
    keepalive_timeout 60;
    #客戶端請求頭讀取超時時間
    client_header_timeout 10;
    #設置客戶端請求主體讀取超時時間
    client_body_timeout 10;
    #響應客戶端超時時間
    send_timeout 10;
 
#FastCGI相關參數是爲了改善網站的性能：減小資源佔用，提升訪問速度。
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers 4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;
 
#gzip模塊設置
    #開啓gzip壓縮輸出
    gzip on; 
    #最小壓縮文件大小
    gzip_min_length 1k; 
    #壓縮緩衝區
    gzip_buffers 4 16k;
    #壓縮版本（默認1.1，前端若是是squid2.5請使用1.0）
    gzip_http_version 1.0;
    #壓縮等級 1-9 等級越高，壓縮效果越好，節約寬帶，但CPU消耗大
    gzip_comp_level 2;
    #壓縮類型，默認就已經包含text/html，因此下面就不用再寫了，寫上去也不會有問題，可是會有一個warn。
    gzip_types text/plain application/x-javascript text/css application/xml;
    #前端緩存服務器緩存通過壓縮的頁面
    gzip_vary on;
  • server（虛擬主機基礎設置）
#虛擬主機定義
    server {
        #監聽端口
        listen       80;
        #訪問域名
        server_name  localhost;
        #編碼格式，若網頁格式與此不一樣，將被自動轉碼
        #charset koi8-r;
        #虛擬主機訪問日誌定義
        #access_log  logs/host.access.log  main;
        #對URL進行匹配
        location / {
            #訪問路徑，可相對也可絕對路徑
            root   html;
            #首頁文件。如下按順序匹配
            index  index.html index.htm;
        }
  • 負載均衡
#負載均衡服務器池
upstream my_server_pool {
    #調度算法
    #1.輪循（默認）（weight輪循權值）
    #2.ip_hash：根據每一個請求訪問IP的hash結果分配。（會話保持）
    #3.fair:根據後端服務器響應時間最短請求。（upstream_fair模塊）
    #4.url_hash:根據訪問的url的hash結果分配。（需hash軟件包）
    #參數：
    #down：表示不參與負載均衡
    #backup:備份服務器
    #max_fails:容許最大請求錯誤次數
    #fail_timeout:請求失敗後暫停服務時間。
    server 192.168.1.109:80 weight=1 max_fails=2 fail_timeout=30;
    server 192.168.1.108:80 weight=2 max_fails=2 fail_timeout=30;
}
#負載均衡調用
server {
    ...
    location / {
    proxy_pass http://my_server_pool;
    }
}
  • location定位
#根據不一樣的瀏覽器URL重寫
if($http_user_agent ~ Firefox){
rewrite ^(.*)$  /firefox/$1 break; 
}
if($http_user_agent ~ MSIE){
rewrite ^(.*)$  /msie/$1 break; 
}
 
#實現域名跳轉
location / {
    rewrite ^/(.*)$ https://web8.example.com$1 permanent;
}
  • IP限制
#限制IP訪問
location / {
    deny 192.168.0.2；
    allow 192.168.0.0/24;
    allow 192.168.1.1;
    deny all;
}

nginx高可用

1. http keepalive

在http早期 ，每一個http請求都要求打開一個tpc socket鏈接，而且使用一次以後就斷開這個tcp鏈接。使用keep-alive能夠改善這種狀態，即在一次TCP鏈接中能夠持續發送多份數據而不會 斷開鏈接。經過使用keep-alive機制，能夠減小tcp鏈接創建次數，也意味着能夠減小TIME_WAIT狀態鏈接，以此提升性能和提升httpd 服務器的吞吐率(更少的tcp鏈接意味着更少的系統內核調用,socket的accept()和close()調用)。可是，keep-alive並非 免費的午飯,長時間的tcp鏈接容易致使系統資源無效佔用。配置不當的keep-alive，有時比重複利用鏈接帶來的損失還更大。因此，正確地設置 keep-alive timeout時間很是重要。

2. keepalvie timeout

Httpd守護進程，通常都提供了keep-alive timeout時間設置參數。好比nginx的keepalive_timeout，和Apache的KeepAliveTimeout。這個 keepalive_timout時間值意味着：一個http產生的tcp鏈接在傳送完最後一個響應後，還須要hold住 keepalive_timeout秒後，纔開始關閉這個鏈接。當httpd守護進程發送完一個響應後，理應立刻主動關閉相應的tcp鏈接，設置 keepalive_timeout後，httpd守護進程會想說：」再等等吧，看看瀏覽器還有沒有請求過來」，這一等，即是 keepalive_timeout時間。若是守護進程在這個等待的時間裏，一直沒有收到瀏覽發過來http請求，則關閉這個http鏈接。
參考（https://www.cnblogs.com/ExMan...）

nginx內置變量

image.png
image.png

nginx經常使用命令

  • 啓動進入sbin ./nginx
  • 查看ngix語法測試是否經過 ./nginx -t
  • 重啓 ./nginx -s reload
  • 查看nginx是否啓動 ps -ef | grep nginx
  • 關閉nginx ./nginx -s stop
  • 關聯配置 ./nginx -c xx.conf

nginx注意事項

1. Nginx在上傳文件時出現413 Request Entity Too Large 
由於Nginx默認支持上傳1MB的文件，因此超過1MB則會報錯。

#nginx上傳文件大小限制配置語法  
Syntax: client\_max\_body\_size size;  
Default: client\_max\_body\_size 1m;  
Context: http, server, location  
容許該server能支持上傳200m的文件，也能夠其配置放入http層，全部server都生效。  
server {  
...  
 client\_max\_body\_size 200m;  
...  
}
2. Nginx指定路徑時，root與alias區別在哪？

root與alias路徑匹配主要區別在於nginx如何解釋location後面的uri，這會使二者分別以不一樣的方式將請求映射到服務器文件上，alias是一個目錄別名的定義，root則是最上層目錄的定義。

root的處理結果是：root路徑＋location路徑
alias的處理結果是：使用alias路徑替換location路徑

1.root路徑配置實例: 用戶訪問www.xuliangwei.com/image/test.gif，實際上Nginx會上/code/image/目錄下找去找test.gif文件

server {  
 listen 80;  
 server\_name www.xuliangwei.com;  
 location /image/ {  
 root /code;  
 }  
}
3. 400 bad request

通常緣由:請求的Header過大。 解決方法：配置nginx.conf相關設置

`client_header_buffer_size 16k;`
`large_client_header_buffers 4 64k;`
4. 403 forbiden
通常是訪問文件權限不夠

5.413 Request Entity Too Large

通常緣由:通常出如今上傳文件。 解決方法：配置nginx.conf相關設置，配置php.ini以下(必須和nginx.conf配置一致)

client_max_body_size 10m;

post_max_size=10M

upload_max_filesize=2M

 499 Client Closed Request

通常緣由:客戶端在爲等到服務器相應返回前就關閉了客戶端描述符。通常出如今客戶端設置超時後，主動關閉socket.

解決方法：根據實際Nginx後端服務器的處理時間修改客戶端超時時間。

 > 6.500 Internal Server Rrror

通常緣由：腳本錯誤，（php語法錯誤、lua語法錯誤）

訪問量過大，系統資源限制，不能打開過多文件
磁盤空間不足。（access log開啓可能致使磁盤滿溢 關閉）

 > 7.502 Bad Gateway、503 Serveice Unavailable

通常緣由:後端服務沒法處理，業務中斷。
解決方法：從後端日誌獲取錯誤緣由，解決後端服務器問題。

 > 8.504 Gateway Timeout

通常緣由:後端服務器在超時時間內，未響應Nginx代理請求
解決方法：根據後端服務器實際處理狀況，調正後端請求超時時間。
proxy_read_timeout 90;
proxy_send_timeout 90;

參考（https://www.cnblogs.com/johnn...）
參考（https://blog.csdn.net/lzghxjt...）

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程