從一份配置清單詳解Nginx服務器配置

概述

在前面《Nginx服務器開箱體驗》 一文中我們從開箱到體驗,感受了一下Nginx服務器的魅力。Nginx是輕量級的高性能Web服務器,提供了諸如HTTP代理和反向代理、負載均衡、緩存等一系列重要特性,因而在實踐之中使用廣泛,筆者也在學習和實踐之中。

在本文中,我們繼續延續前文,從前文給出的一份示例配置清單開始,詳解一下Nginx服務器的各種配置指令的作用和用法。

看到了下文中的包含了**“小豬佩琪色”** 的配圖了嗎,嘿嘿,我們開始吧!



Nginx配置文件的整體結構

從一份配置清單詳解Nginx服務器配置

從圖中可以看出主要包含以下幾大部分內容:

1. 全局塊

該部分配置主要影響Nginx全局,通常包括下面幾個部分:

  • 配置運行Nginx服務器用戶(組)
  • worker process數
  • Nginx進程PID存放路徑
  • 錯誤日誌的存放路徑
  • 配置文件的引入

2. events塊

該部分配置主要影響Nginx服務器與用戶的網絡連接,主要包括:

  • 設置網絡連接的序列化
  • 是否允許同時接收多個網絡連接
  • 事件驅動模型的選擇
  • 最大連接數的配置

3. http塊

  • 定義MIMI-Type
  • 自定義服務日誌
  • 允許sendfile方式傳輸文件
  • 連接超時時間
  • 單連接請求數上限

4. server塊

  • 配置網絡監聽
  • 基於名稱的虛擬主機配置
  • 基於IP的虛擬主機配置

5. location塊

  • location配置
  • 請求根目錄配置
  • 更改location的URI
  • 網站默認首頁配置

一份配置清單例析

筆者按照文章:《Nginx服務器開箱體驗》 中的實驗,給出了一份簡要的清單配置舉例:

從一份配置清單詳解Nginx服務器配置

配置代碼如下:

user nobody nobody;worker_processes 3;error_log logs/error.log;pid logs/nginx.pid;events {use epoll; worker_connections 1024;}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"'; access_log logs/access.log main; sendfile on; keepalive_timeout 65; server { listen 8088; server_name codesheep; access_log /codesheep/webserver/server1/log/access.log; error_page 404 /404.html; location /server1/location1 { root /codesheep/webserver; index index.server2-location1.htm; } location /server1/location2 { root /codesheep/webserver; index index.server2-location2.htm; } } server { listen 8089; server_name 192.168.31.177; access_log /codesheep/webserver/server2/log/access.log; error_page 404 /404.html; location /server2/location1 { root /codesheep/webserver; index index.server2-location1.htm; } location /srv2/loc2 { alias /codesheep/webserver/server2/location2/; index index.server2-location2.htm; } location = /404.html { root /codesheep/webserver/; index 404.html; } }}

接下來就來詳細剖析以下配置文件中各個指令的含義⬇️


配置運行Nginx服務器用戶(組)

指令格式:user user [group];

  • user:指定可以運行Nginx服務器的用戶
  • group:可選項,可以運行Nginx服務器的用戶組

如果user指令不配置或者配置為 user nobody nobody ,則默認所有用戶都可以啟動Nginx進程


worker process數配置

Nginx服務器實現併發處理服務的關鍵,指令格式:worker_processes number | auto;

  • number:Nginx進程最多可以產生的worker process數
  • auto:Nginx進程將自動檢測

按照上文中的配置清單的實驗,我們給worker_processes配置的數目是:3,啟動Nginx服務器後,我們可以後臺看一下主機上的Nginx進程情況:

ps -aux | grep nginx

很明顯,理解 worker_processes 這個指令的含義就很容易了

從一份配置清單詳解Nginx服務器配置


Nginx進程PID存放路徑

Nginx進程是作為系統守護進程在運行,需要在某文件中保存當前運行程序的主進程號,Nginx支持該保存文件路徑的自定義

指令格式:pid file;

  • file:指定存放路徑和文件名稱
  • 如果不指定默認置於路徑 logs/nginx.pid

錯誤日誌的存放路徑

指定格式:error_log file | stderr;

  • file:日誌輸出到某個文件file
  • stderr:日誌輸出到標準錯誤輸出

配置文件的引入

指令格式:include file;

  • 該指令主要用於將其他的Nginx配置或者第三方模塊的配置引用到當前的主配置文件中

設置網絡連接的序列化

指令格式:accept_mutex on | off;

  • 該指令默認為on狀態,表示會對多個Nginx進程接收連接進行序列化,防止多個進程對連接的爭搶。

說到該指令,首先得闡述一下什麼是所謂的 “驚群問題”,可以參考 WIKI百科的解釋。就Nginx的場景來解釋的話大致的意思就是:當一個新網絡連接來到時,多個worker進程會被同時喚醒,但僅僅只有一個進程可以真正獲得連接並處理之。如果每次喚醒的進程數目過多的話,其實是會影響一部分性能的。

所以在這裡,如果accept_mutex on,那麼多個worker將是以串行方式來處理,其中有一個worker會被喚醒;反之若accept_mutex off,那麼所有的worker都會被喚醒,不過只有一個worker能獲取新連接,其它的worker會重新進入休眠狀態

這個值的開關與否其實是要和具體場景掛鉤的。


是否允許同時接收多個網絡連接

指令格式:multi_accept on | off;

  • 該指令默認為off狀態,意指每個worker process 一次只能接收一個新到達的網絡連接。若想讓每個Nginx的worker process都有能力同時接收多個網絡連接,則需要開啟此配置

事件驅動模型的選擇

指令格式:use model;

  • model模型可選擇項包括:select、poll、kqueue、epoll、rtsig等......

最大連接數的配置

指令格式:worker_connections number;

  • number默認值為512,表示允許每一個worker process可以同時開啟的最大連接數

定義MIME-Type

指令格式:

include mime.types;default_type mime-type;
  • MIME-Type指的是網絡資源的媒體類型,也即前端請求的資源類型
  • include指令將mime.types文件包含進來

cat mime.types 來查看mime.types文件內容,我們發現其就是一個types結構,裡面包含了各種瀏覽器能夠識別的MIME類型以及對應類型的文件後綴名字,如下所示:

從一份配置清單詳解Nginx服務器配置


自定義服務日誌

指令格式:

access_log path [format];
  • path:自定義服務日誌的路徑 + 名稱
  • format:可選項,自定義服務日誌的字符串格式。其也可以使用 log_format 定義的格式

允許sendfile方式傳輸文件

指令格式:

sendfile on | off;sendfile_max_chunk size;
  • 前者用於開啟或關閉使用sendfile()傳輸文件,默認off
  • 後者指令若size>0,則Nginx進程的每個worker process每次調用sendfile()傳輸的數據了最大不能超出此值;若size=0則表示不限制。默認值為0

連接超時時間配置

指令格式:keepalive_timeout timeout [header_timeout];

  • timeout 表示server端對連接的保持時間,默認75秒
  • header_timeout 為可選項,表示在應答報文頭部的 Keep-Alive 域設置超時時間:“Keep-Alive : timeout = header_timeout”

單連接請求數上限

指令格式:keepalive_requests number;

  • 該指令用於限制用戶通過某一個連接向Nginx服務器發起請求的次數

配置網絡監聽

指令格式:

  • 第一種:配置監聽的IP地址:listen IP[:PORT];
  • 第二種:配置監聽的端口:listen PORT;

實際舉例:

listen 192.168.31.177:8080; # 監聽具體IP和具體端口上的連接listen 192.168.31.177; # 監聽IP上所有端口上的連接listen 8080; # 監聽具體端口上的所有IP的連接

基於名稱和IP的虛擬主機配置

指令格式:server_name name1 name2 ...

  • name可以有多個並列名稱,而且此處的name支持正則表達式書寫

實際舉例:

server_name ~^www\d+\.myserver\.com$

此時表示該虛擬主機可以接收類似域名 www1.myserver.com 等的請求而拒絕 www.myserver.com 的域名請求,所以說用正則表達式可以實現更精準的控制

至於基於IP的虛擬主機配置比較簡單,不再太贅述:

指令格式:server_name IP地址


location配置

指令格式為:location [ = | ~ | ~* | ^~ ] uri {...}

  • 這裡的uri分為標準uri和正則uri,兩者的唯一區別是uri中是否包含正則表達式

uri前面的方括號中的內容是可選項,解釋如下:

  • “=”:用於標準uri前,要求請求字符串與uri嚴格匹配,一旦匹配成功則停止
  • “~”:用於正則uri前,並且區分大小寫
  • “~*”:用於正則uri前,但不區分大小寫
  • “^~”:用於標準uri前,要求Nginx找到標識uri和請求字符串匹配度最高的location後,立即使用此location處理請求,而不再使用location塊中的正則uri和請求字符串做匹配

請求根目錄配置

指令格式:root path;

  • path:Nginx接收到請求以後查找資源的根目錄路徑

當然,還可以通過alias指令來更改location接收到的URI請求路徑,指令為:

alias path; # path為修改後的根路徑 

設置網站的默認首頁

指令格式:index file ......

  • file可以包含多個用空格隔開的文件名,首先找到哪個頁面,就使用哪個頁面響應請求


分享到:


相關文章: