前端開發者必備的 Nginx 知識

前端開發者必備的 Nginx 知識

做者：code祕密花園 公號 / ConardLi （本文來自做者投稿）

nginx在應用程序中的做用

• 解決跨域

• 請求過濾

• 配置gzip

• 負載均衡

• 靜態資源服務器

nginx是一個高性能的HTTP和反向代理服務器，也是一個通用的TCP/UDP代理服務器，最初由俄羅斯人Igor Sysoev編寫。

nginx如今幾乎是衆多大型網站的必用技術，大多數狀況下，咱們不須要親自去配置它，可是瞭解它在應用程序中所擔任的角色，以及如何解決這些問題是很是必要的。

下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的做用。

爲了便於理解，首先先來了解一下一些基礎知識， nginx是一個高性能的反向代理服務器那麼什麼是反向代理呢？

正向代理與反向代理

代理是在服務器和客戶端之間假設的一層服務器，代理將接收客戶端的請求並將它轉發給服務器，而後將服務端的響應轉發給客戶端。

不論是正向代理仍是反向代理，實現的都是上面的功能。

 

正向代理

正向代理，意思是一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，而後代理向原始服務器轉交請求並將得到的內容返回給客戶端。

正向代理是爲咱們服務的，即爲客戶端服務的，客戶端能夠根據正向代理訪問到它自己沒法訪問到的服務器資源。

正向代理對咱們是透明的，對服務端是非透明的，即服務端並不知道本身收到的是來自代理的訪問仍是來自真實客戶端的訪問。

反向代理

* 反向代理*（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器。

反向代理是爲服務端服務的，反向代理能夠幫助服務器接收來自客戶端的請求，幫助服務器作請求轉發，負載均衡等。

反向代理對服務端是透明的，對咱們是非透明的，即咱們並不知道本身訪問的是代理服務器，而服務器知道反向代理在爲他服務。

基本配置

配置結構

下面是一個nginx配置文件的基本結構：

events {

}

http

{

server

{

location path

{

...

}

location path

{

...

}

}

 

server

{

...

}

 

}

 

• main:nginx的全局配置，對全局生效。

• events:配置影響nginx服務器或與用戶的網絡鏈接。

• http：能夠嵌套多個server，配置代理，緩存，日誌定義等絕大多數功能和第三方模塊的配置。

• server：配置虛擬主機的相關參數，一個http中能夠有多個server。

• location：配置請求的路由，以及各類頁面的處理狀況。

• upstream：配置後端服務器具體地址，負載均衡配置不可或缺的部分。

內置變量

下面是 nginx一些配置中經常使用的內置全局變量，你能夠在配置的任何位置使用它們。

變量名	功能
$host	請求信息中的 Host，若是請求中沒有 Host行，則等於設置的服務器名
$request_method	客戶端請求類型，如 GET、 POST
$remote_addr	客戶端的 IP地址
$args	請求中的參數
$content_length	請求頭中的 Content-length字段
$http_user_agent	客戶端agent信息
$http_cookie	客戶端cookie信息
$remote_addr	客戶端的IP地址
$remote_port	客戶端的端口
$server_protocol	請求使用的協議，如 HTTP/1.0、·HTTP/1.1`
$server_addr	服務器地址
$server_name	服務器名稱
$server_port	服務器的端口號

解決跨域

先追本溯源如下，跨域到底是怎麼回事。

跨域的定義

同源策略限制了從同一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。一般不容許不一樣源間的讀操做。

同源的定義

若是兩個頁面的協議，端口（若是有指定）和域名都相同，則兩個頁面具備相同的源。

 

nginx解決跨域的原理

例如：

• 前端server的域名爲：fe.server.com

• 後端服務的域名爲：dev.server.com

如今我在 fe.server.com對 dev.server.com發起請求必定會出現跨域。

如今咱們只須要啓動一個nginx服務器，將 server_name設置爲 fe.server.com,而後設置相應的location以攔截前端須要跨域的請求，最後將請求代理回 dev.server.com。以下面的配置：

server {

listen 80;

server_name fe.server.com;

location / {

proxy_pass dev.server.com;

}

}

 

這樣能夠完美繞過瀏覽器的同源策略： fe.server.com訪問 nginx的 fe.server.com屬於同源訪問，而 nginx對服務端轉發的請求不會觸發瀏覽器的同源策略。

請求過濾

 

根據狀態碼過濾

1. error_page 500 501 502 503 504 506 /50x.html;

2. location = /50x.html {

3. #將跟路徑改編爲存放html的路徑。

4. root /root/static/html;

5. }

根據URL名稱過濾，精準匹配URL，不匹配的URL所有重定向到主頁。

1. location / {

2. rewrite ^.*$ /index.html redirect;

3. }

根據請求類型過濾。

1. if ( $request_method !~ ^(GET|POST|HEAD)$ ) {

2. return 403;

3. }

配置gzip

 

GZIP是規定的三種標準HTTP壓縮格式之一。目前絕大多數的網站都在使用 GZIP傳輸 HTML、 CSS、 JavaScript 等資源文件。

對於文本文件， GZip 的效果很是明顯，開啓後傳輸所需流量大約會降至 1/4~1/3。

並非每一個瀏覽器都支持 gzip的，如何知道客戶端是否支持 gzip呢，請求頭中的 Accept-Encoding來標識對壓縮的支持。

 

啓用 gzip同時須要客戶端和服務端的支持，若是客戶端支持 gzip的解析，那麼只要服務端可以返回 gzip的文件就能夠啓用 gzip了,咱們能夠經過 nginx的配置來讓服務端支持 gzip。下面的 respone中 content-encoding:gzip，指服務端開啓了 gzip的壓縮方式。

 

1. gzip on;

2. gzip_http_version 1.1;

3. gzip_comp_level 5;

4. gzip_min_length 1000;

5. gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;

gzip

• 開啓或者關閉 gzip模塊

• 默認值爲 off

• 可配置爲 on/off

gziphttpversion

• 啓用 GZip 所需的 HTTP 最低版本

• 默認值爲 HTTP/1.1

這裏爲何默認版本不是 1.0呢？

HTTP 運行在 TCP 鏈接之上，天然也有着跟 TCP 同樣的三次握手、慢啓動等特性。

啓用持久鏈接狀況下，服務器發出響應後讓 TCP鏈接繼續打開着。同一對客戶/服務器之間的後續請求和響應能夠經過這個鏈接發送。

 

爲了儘量的提升 HTTP 性能，使用持久鏈接就顯得尤其重要了。

HTTP/1.1默認支持 TCP持久鏈接， HTTP/1.0 也能夠經過顯式指定 Connection:keep-alive來啓用持久鏈接。對於 TCP持久鏈接上的 HTTP 報文，客戶端須要一種機制來準確判斷結束位置，而在 HTTP/1.0中，這種機制只有 Content-Length。而在 HTTP/1.1中新增的 Transfer-Encoding:chunked 所對應的分塊傳輸機制能夠完美解決這類問題。

nginx一樣有着配置 chunked的屬性 chunked_transfer_encoding，這個屬性是默認開啓的。

Nginx在啓用了 GZip的狀況下，不會等文件 GZip 完成再返回響應，而是邊壓縮邊響應，這樣能夠顯著提升 TTFB( TimeToFirstByte，首字節時間，WEB 性能優化重要指標)。這樣惟一的問題是， Nginx 開始返回響應時，它沒法知道將要傳輸的文件最終有多大，也就是沒法給出 Content-Length這個響應頭部。

因此，在 HTTP1.0中若是利用 Nginx啓用了 GZip，是沒法得到 Content-Length的，這致使HTTP1.0中開啓持久連接和使用 GZip只能二選一，因此在這裏 gzip_http_version默認設置爲 1.1。

gzipcomplevel

• 壓縮級別，級別越高壓縮率越大，固然壓縮時間也就越長（傳輸快但比較消耗cpu）。

• 默認值爲 1

• 壓縮級別取值爲 1-9

gzipminlength

• 設置容許壓縮的頁面最小字節數， Content-Length小於該值的請求將不會被壓縮

• 默認值: 0

• 當設置的值較小時，壓縮後的長度可能比原文件大，建議設置 1000以上

gzip_types

• 要採用gzip壓縮的文件類型( MIME類型)

• 默認值: text/html(默認不壓縮 js/ css)

負載均衡

什麼是負載均衡

如上面的圖，前面是衆多的服務窗口，下面有不少用戶須要服務，咱們須要一個工具或策略來幫助咱們將如此多的用戶分配到每一個窗口，來達到資源的充分利用以及更少的排隊時間。

把前面的服務窗口想像成咱們的後端服務器，然後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助咱們將衆多的客戶端請求合理的分配到各個服務器，以達到服務端資源的充分利用和更少的請求時間。

nginx如何實現負載均衡

Upstream指定後端服務器地址列表

1. upstream balanceServer {

2. server 10.1.22.33:12345;

3. server 10.1.22.34:12345;

4. server 10.1.22.35:12345;

5. }

在server中攔截響應請求，並將請求轉發到Upstream中配置的服務器列表。

1. server {

2. server_name fe.server.com;

3. listen 80;

4. location /api {

5.             proxy_pass http://balanceServer;

6. }

7. }

上面的配置只是指定了nginx須要轉發的服務端列表，並無指定分配策略。

nginx實現負載均衡的策略

輪詢策略

默認狀況下采用的策略，將全部客戶端請求輪詢分配給服務端。這種策略是能夠正常工做的，可是若是其中某一臺服務器壓力太大，出現延遲，會影響全部分配在這臺服務器下的用戶。

1. upstream balanceServer {

2. server 10.1.22.33:12345;

3. server 10.1.22.34:12345;

4. server 10.1.22.35:12345;

5. }

最小鏈接數策略

將請求優先分配給壓力較小的服務器，它能夠平衡每一個隊列的長度，並避免向壓力大的服務器添加更多的請求。

1. upstream balanceServer {

2. least_conn;

3. server 10.1.22.33:12345;

4. server 10.1.22.34:12345;

5. server 10.1.22.35:12345;

6. }

最快響應時間策略

依賴於NGINX Plus，優先分配給響應時間最短的服務器。

1. upstream balanceServer {

2. fair;

3. server 10.1.22.33:12345;

4. server 10.1.22.34:12345;

5. server 10.1.22.35:12345;

6. }

客戶端ip綁定

來自同一個ip的請求永遠只分配一臺服務器，有效解決了動態網頁存在的session共享問題。

1. upstream balanceServer {

2. ip_hash;

3. server 10.1.22.33:12345;

4. server 10.1.22.34:12345;

5. server 10.1.22.35:12345;

6. }

靜態資源服務器

1. location ~* \.(png|gif|jpg|jpeg)$ {

2. root /root/static/;

3. autoindex on;

4. access_log off;

5. expires 10h;# 設置過時時間爲10小時

6. }

匹配以 png|gif|jpg|jpeg爲結尾的請求，並將請求轉發到本地路徑， root中指定的路徑即nginx本地路徑。同時也能夠進行一些緩存的設置。