NGINX_簡明教程

NGINX 是一款來自俄羅斯的HTTP 和反向代理(reverse proxy)服務器、郵件服務器,以及通用的 TCP/UDP 代理服務器,以其高性能被業界普遍採用。本文經過最簡潔的方式,將 NGINX 核心應用作下介紹。html

什麼是 NGINX

NGINX是一個免費的、開源的、高性能的 HTTP 服務器和反向代理,以及一個 IMAP/POP3 代理服務器。 NGINX以其高性能、穩定性、豐富的功能集、簡單的配置和低資源消耗而聞名。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;

在這種狀況下,這個證書文件的訪問權限也應受到限制。雖然證書和密鑰存儲在一個文件中,但只有證書被髮送到客戶端。app

指令 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構建中。

原文地址:http://click.aliyun.com/m/21632/  

相關文章
相關標籤/搜索