NGINX簡明教程

waylau發表於2017-05-21
Nginx

原文同步至 https://waylau.com/nginx-concise-tutorial/

NGINX 是一款來自俄羅斯的HTTP 和反向代理（reverse proxy）伺服器、郵件伺服器，以及通用的 TCP/UDP 代理伺服器，以其高效能被業界廣泛採用。本文通過最簡潔的方式，將 NGINX 核心應用做下介紹。

什麼是 NGINX

NGINX是一個免費的、開源的、高效能的 HTTP 伺服器和反向代理，以及一個 IMAP/POP3 代理伺服器。 NGINX以其高效能、穩定性、豐富的功能集、簡單的配置和低資源消耗而聞名。

NGINX 是為解決C10K 問題而編寫的少數伺服器之一。與傳統伺服器不同，NGINX 不依賴於執行緒來處理請求。相反，它使用更加可擴充套件的事件驅動（非同步）架構。這種架構在負載下使用小的但更重要的是可預測的記憶體量。即使您不希望處理數千個併發請求，您仍然可以從 NGINX 的高效能和小記憶體中獲益。 NGINX 在各個方向擴充套件：從最小的 VPS 一直到大型伺服器叢集。

控制語句

NGINX 啟動後，有一個主程式（master process）和一個或多個工作程式（worker process），主程式的作用主要是讀入和檢查NGINX的配置資訊，以及維護工作程式；工作程式才是真正處理客戶端請求的程式。具體要啟動多少個工作程式，可以在 NGINX 的配置檔案nginx.conf中通過worker_processes指令指定。
可以通過以下這些命令來控制 NGINX：

nginx -s [ stop | quit | reopen | reload ]

其中：

  • nginx -s stop： 強制停止NGINX，不管工作程式當前是否正在處理使用者請求，都會立即退出。
  • nginx -s quit：“優雅地”退出NGINX，執行這個命令後，工作程式會將當前正在處理的請求處理完畢後，再退出。
  • nginx -s reload：過載配置資訊。當NGINX的配置檔案改變之後，同過執行這個命令，使更改的配置資訊生效，而無需重新啟動nginx.
  • nginx -s reopen：重新開啟日誌檔案。

配置伺服器名稱

伺服器名稱是用server_name指令來定義的，並且它決定了哪一個server塊將用來處理給定的請求。可以使用精確名稱、萬用字元、正規表示式來定義伺服器名稱。

server {
    listen       80;
    server_name  example.org  www.example.org;
    ...
}

server {
    listen       80;
    server_name  *.example.org;
    ...
}

server {
    listen       80;
    server_name  mail.*;
    ...
}

server {
    listen       80;
    server_name  ~^(?<user>.+).example.net$;
    ...
}

當尋找一個虛擬伺服器的名字，如果指定的名稱匹配多個變體，例如，萬用字元和正規表示式都匹配，將會按照以下的順序選擇第一個匹配的變體：

  • 精確名稱
  • 以星號（）開頭的最長的萬用字元，例如“.example.org”
  • 以星號（）結尾的最長的萬用字元，例如“mail.”
  • 第一個匹配的正規表示式（根據在配置檔案中出現的順序）

配置 HTTPS 伺服器

修改 conf/nginx.conf 檔案，必須在配置檔案 server 塊中的監聽指令 listen 後啟用 ssl 引數，並且指定伺服器證書 ssl_certificate 和私鑰 ssl_certificate_key 的位置：

server {
    listen              443 ssl;
    server_name         www.example.com;
    ssl_certificate     www.example.com.crt;
    ssl_certificate_key www.example.com.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...
}

伺服器證書是一個公共實體，它被髮送給連線到伺服器的每一個客戶機。私鑰是一個安全實體，應該儲存在具有受限訪問的檔案中，但它必須可被nginx主程式讀取。私鑰也可以儲存在與伺服器證書相同的檔案中：

    ssl_certificate     www.example.com.cert;
    ssl_certificate_key www.example.com.cert;

在這種情況下，這個證書檔案的訪問許可權也應受到限制。雖然證書和金鑰儲存在一個檔案中，但只有證書被髮送到客戶端。

指令 ssl_protocols 和 ssl_ciphers 可用於限制僅包括強版本和密碼的 SSL/TLS 連線。 預設情況下，NGINX 使 用ssl_protocols TLSv1 TLSv1.1 TLSv1.2版本和ssl_ciphers HIGH:!aNULL:!MD5密碼，因此通常不需要顯式地配置它們。需要注意的是，這些指令的預設值在不同的版本里面已經變更好幾次了。

作為 HTTP 負載均衡器

跨多個應用程式例項的負載均衡是優化資源利用率，最大限度地提高吞吐量，降低延遲，並確保容錯配置一個常用的技術。

NGINX 支援如下負載均衡的機制（或方法）：

1. 輪詢

如果沒有指定負載均衡的方法，那麼 NGINX 預設採用的是輪詢的方式。最簡單的負載均衡配置如下：

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

3個同樣例項的應用（srv1-srv3）是採用輪詢方式。所有請求被代理到一組服務myapp1，同時，NGINX 運用 HTTP 負載均衡來分發請求。

反向代理被應用在 NGINX 內，包括負載均衡針對 HTTP、HTTPS、FASTCGI、uwsgi、SCGI 以及 memcached。

配置負載均衡針對 HTTPS 替代 HTTP 的話，僅僅使用 https 協議即可（proxy_pass https://myapp1）。

在為 FASTCGI、uwsgi、SCGI 或 memcached 設定負載均衡時，分別使用 fastcgi_pass、uwsgi_pass、scgi_pass 和 memcached_pass 指令。

2. 最少連線

在一些請求需要更長時間才能完成的情況下，最少連線可以更公正地控制應用程式例項的負載。

使用最少連線的負載平衡，NGINX 將不會加重一個有過多請求的應用服務負擔，而是將它分發新的請求給最不繁忙的伺服器。

在 NGINX 中需要通過設定least_conn來啟用最少連線的負載均衡策略配置：

upstream myapp1 {
    least_conn;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

3. IP 雜湊（會話持久）

注意，採用輪詢或者最少連線的負載均衡策略，每個客戶端的後續請求可能被分配帶不同的伺服器，不能保證同一個客戶端總是指向同一個服務。如果需要告訴客戶端分配到一個特定的應用服務，換句話，就是保持客戶端的會話粘性（sticky）或者會話永續性（persitent），即總是嘗試選著同一個特定的伺服器，IP 雜湊 負載均衡機制可以被使用。

採用 IP 雜湊的策略，客戶端的 IP 地址被用作一個雜湊 key，決定哪個服務應該被選中來服務客戶端的請求。這種方式，確保了同一個客戶端來的請求將總是被指向同一個服務，除非這個服務不可用了。

配置IP 雜湊負載均衡，只需要通過設定ip_hash來啟用：

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

權重（weight）

可以通過使用伺服器的權重來影響 NGINX 的負載均衡演算法，在上述輪詢、最少請求、基於IP 雜湊負載均衡配置中，伺服器的權重沒有配置，意味著所有伺服器的權重都是一樣的。特別是輪詢，它意味著或多或少平等的分發請求到伺服器（請求夠多，並且請求以均勻方式進行處理，並完成夠快）

當配置了一個 weight 變數到一個指定的服務後，權重被作為一個 NGINX 的負載均衡的決定的一部分：

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

採用上面的配置，如果來了5個請求，3個到srv1，1個到srv2,1個到srv3。在最近的NGINX版本中，同樣可以使用權重針對最少連線和IP 雜湊的負載均衡策略。

健康監測

反向代理在 NGINX 中實現了被動的健康監測，如果響應從一個特定的伺服器失敗，攜帶著錯誤，NGINX 將標記這個伺服器是失敗的，並將嘗試一段時間避免選擇這個伺服器作為後續請求的伺服器。

fail_timeout 和 max_fails 用於設定指定時間內，應該發生連續不成功的數目。預設max_fail等於1，如果設定成0，相當於關閉這個伺服器的健康監測。fail_timeout引數，定義多久伺服器被標識失敗。過了伺服器fail_timeout失敗超時間隔後，NGINX 將開始探測存活的客戶端的請求，如果探測成功，服務被標識成存活狀態。

壓縮與解壓

壓縮響應通常會顯著減少傳輸資料的大小。 然而，由於壓縮在執行時發生，所以會增加處理開銷，這可能會對效能產生負面影響。

在向客戶端傳送響應之前，NGINX 會執行壓縮，但不會“重複壓縮”已經壓縮過的響應。

啟用壓縮

要啟用壓縮，在 gzip 指令上請使用on引數:

gzip on;

預設情況下，NGINX 僅壓縮使用MIME 型別 為 text/html的響應。要壓縮其他 MIME 型別的響應，請包含gzip_types指令並列出相應的型別。

gzip_types text/plain application/xml;

要指定要壓縮的響應的最小長度，請使用gzip_min_length指令。預設值為20位元組，下面示例調整為1000：

gzip_min_length 1000;

預設情況下，NGINX 不會壓縮對代理請求的響應（來自代理伺服器的請求）。請求是否來自代理伺服器是由請求中Via頭欄位的是否存來確定的。要配置這些響應的壓縮，請使用gzip_proxied指令。該指令具有多個引數來指定 NGINX 應壓縮哪種代理請求。例如，僅對不會在代理伺服器上快取的請求進行壓縮響應，為此，gzip_proxied指令具有指示 NGINX 在響應中檢查Cache-Control頭欄位的引數，如果值是 no-cache、no-store 或 private，則壓縮響應。另外，您必須包括 expired 的引數來檢查Expires頭欄位的值。這些引數在以下示例中與 auth 引數一起設定，該引數檢查Authorization頭欄位的存在（授權響應特定於終端使用者，並且通常不被快取）：

gzip_proxied no-cache no-store private expired auth;

與大多數其他指令一樣，配置壓縮的指令可以包含在http上下文中，也可以包含在 server 或 location 塊中。

gzip 壓縮的整體配置可能如下所示。

server {
    gzip on;
    gzip_types      text/plain application/xml;
    gzip_proxied    no-cache no-store private expired auth;
    gzip_min_length 1000;
    ...
}

啟用解壓

某些客戶端不支援使用 gzip 編碼方法的響應。同時，可能需要儲存壓縮資料，或者即時壓縮響應並將它們儲存在快取中。為了都能成功地服務於接受或者不接受壓縮資料的客戶端，針對後一種型別的客戶端時，NGINX 可以在將資料傳送時即時解壓縮資料。

要啟用執行時解壓縮，請使用gunzip指令。

location /storage/ {
    gunzip on;
    ...
}

gunzip指令可以在與gzip指令相同的上下文中指定：

server {
    gzip on;
    gzip_min_length 1000;
    gunzip on;
    ...
}

請注意，此指令在單獨的模組中定義（見ngx_http_gunzip_modulehttp://nginx.org/en/docs/http/ngx_http_gunzip_module.html），預設情況下可能不包含在開源 NGINX 構建中。

傳送壓縮檔案

要將檔案的壓縮版本傳送到客戶端而不是常規檔案，請在適當的上下文中將gzip_static指令設定為 on。

location / {
    gzip_static on;
}

在這種情況下，為了服務/path/to/file的請求，NGINX 嘗試查詢併傳送檔案/path/to/file.gz。如果檔案不存在，或客戶端不支援 gzip，則 NGINX 將傳送未壓縮版本的檔案。

請注意，gzip_static指令不啟用即時壓縮。它只是使用壓縮工具預先壓縮的檔案。要在執行時壓縮內容（而不僅僅是靜態內容），請使用gzip指令。

該指令在單獨的模組中定義（見ngx_http_gzip_static_modulehttp://nginx.org/en/docs/http/ngx_http_gzip_static_module.html），預設情況下可能不包含在開源NGINX構建中。

參考文獻


相關文章