靜態(tài)資源

靜態(tài)資源即非服務(wù)器動態(tài)生成的文件。
常見靜態(tài)資源類型：

• 瀏覽器端渲染：HTML、CSS、JS
• 圖片：JPEG、GIF、PNG
• 視頻：FLV、MPEG
• 文件：TXT 等任意下載文件

基本配置

Web 服務(wù)器一個重要的功能是服務(wù)靜態(tài)文件（圖像或靜態(tài) HTML 頁面）。例如，Nginx 可以很方便的讓服務(wù)器從 /data/www 獲取 html 文件，從 /data/images 獲取圖片來返回給客戶端，這只需要在 http 塊指令中的 server 塊指令中設(shè)置兩個 location 塊指令。

首先，創(chuàng)建 /data/www 目錄，并放入 index.html，創(chuàng)建 /data/images 目錄并在其中放置一些圖片。

接下來，打開配置文件。 創(chuàng)建一個 server 塊：

http {
    server {
    }
}

通常，配置文件可以包括多個 server 塊，它們以 端口 和 服務(wù)器名稱 來區(qū)分。當(dāng) Nginx 決定某一個 server 處理請求后，它將請求頭中的 URI 和 server 塊中的 location 塊進行對比。

加入 location 塊指令到 server 中：

將以下 location 塊添加到 server 塊：

location / {
  root /data/www;
}

上面的 location 塊指定 / 前綴與請求中的 URI 對比。對于匹配的請求，URI 將被添加到 root 指令中指定的路徑，即 /data/www，以此形成本地文件系統(tǒng)的路徑，如訪問 http://localhost/bog/welcome.html，對應(yīng)服務(wù)器文件路徑為 /data/www/bog/welcome.html。 如果 URI 匹配多個 location 塊，Nginx 采用 最長前綴匹配原則（類似計算機網(wǎng)絡(luò)里面的 IP 匹配）， 上面的 location 塊前綴長度為 1，因此只有當(dāng)所有其他 location 塊匹配時，才使用該塊。

接下來，添加第二個位置塊：

location /images/ {
  root /data;
}

它將匹配以 /images/（/ 也匹配這樣的請求，但具有較短的前綴）開始的請求。

server 塊的最終配置如下：

server {
  location / {
    root /data/www;
  }

  location /images/ {
      root /data;
  }
}

到目前為止，這已經(jīng)是一個可以正常運行的服務(wù)器，它監(jiān)聽端口 80，并且可以在本地計算機上訪問 http://localhost/。 對于 /images/ 開頭的請求，服務(wù)器將從 /data/images 目錄發(fā)送文件。 如，對于 http://localhost/images/example.png 請求，nginx 將響應(yīng) /data/images/example.png 文件。 如果不存在，Nginx 將返回 404。URI 不以 /images/ 開頭的請求將映射到 /data/www 目錄。 例如，對于 http://localhost/some/example.html 請求，Nginx 將響應(yīng) /data/www/some/example.html 文件。

簡易配置

# 虛擬主機server塊
server {
    # 端口
    listen   8080;
    # 匹配請求中的host值
    server_name  localhost;

    # 監(jiān)聽請求路徑
    location / {
        # 查找目錄
        root /source;
        # 默認查找
        index index.html index.htm;
    }
}

說明相關(guān)配置字段：

• server：配置虛擬主機的相關(guān)參數(shù)，可以有多個
• server_name：通過請求中的 host 值，找到對應(yīng)的虛擬主機的配置
• location：配置請求路由，處理相關(guān)頁面情況
• root：查找資源的路徑

配置完成后執(zhí)行 nginx -t 看是否有錯誤，如果看到的是下面這種就是成功：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

然后執(zhí)行 nginx -s reload 更新 Nginx 配置文件

文件讀取配置

http {
  # 調(diào)用 sendfile 系統(tǒng)傳輸文件，開啟高效傳輸模式
  # sendfile 開啟的情況下，提高網(wǎng)絡(luò)包的傳輸效率（等待，一次傳輸）
  sendfile      on;

  # 減少網(wǎng)絡(luò)報文段的數(shù)量
  tcp_nopush    on;

  # 與 tcp_nopush 相反
  # tcp_nodelay off;
}

在 Keep-Alive 連接下，提高網(wǎng)絡(luò)包的傳輸實時性。

文件壓縮配置

開發(fā)過程中難免用到一些成熟的框架，或者插件，這些外部的依賴，有時候體積比較大，導(dǎo)致頁面響應(yīng)緩慢，我們可以用打包工具（Webpack、rollup），將代碼進行壓縮，以縮小代碼體積。 開啟 Nginx Gzip 壓縮功能。需要注意的是 Gzip 壓縮功能需要瀏覽器跟服務(wù)器都支持，即服務(wù)器壓縮，瀏覽器解析。

Nginx 配置 gzip

server {
    # 開啟 gzip 壓縮(默認 off)
    gzip on;

    # 設(shè)置壓縮文件的類型（text/html)
    gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/json application/xml;

    # 設(shè)置 gzip 所需的 HTTP 協(xié)議最低版本（HTTP/1.1, HTTP/1.0）
    gzip_http_version 1.1;

    # 設(shè)置壓縮級別，壓縮級別越高壓縮時間越長  （1-9）
    gzip_comp_level 4;

    # 設(shè)置壓縮的最小字節(jié)數(shù)， 頁面 Content-Length 獲取
    gzip_min_length 1000;
}

• gzip_types：要采用 gzip 壓縮的 MIME 文件類型，其中 text/html 被系統(tǒng)強制啟用；
• gzip_static：默認 off，該模塊啟用后，Nginx 首先檢查是否存在請求靜態(tài)文件的 gz 結(jié)尾的文件，如果有則直接返回該 .gz 文件內(nèi)容；
• gzip_proxied：默認 off，Nginx 做為反向代理時啟用，用于設(shè)置啟用或禁用從代理服務(wù)器上收到相應(yīng)內(nèi)容 gzip 壓縮；
• gzip_vary：用于在響應(yīng)消息頭中添加 Vary：Accept-Encoding，使代理服務(wù)器根據(jù)請求頭中的 Accept-Encoding 識別是否啟用 gzip 壓縮；
• gzip_comp_level：gzip 壓縮比，壓縮級別是 1-9，1 壓縮級別最低，9 最高，級別越高壓縮率越大，壓縮時間越長，建議 4-6；
• gzip_buffers：獲取多少內(nèi)存用于緩存壓縮結(jié)果，16 8k 表示以 8k*16 為單位獲得；
• gzip_min_length：允許壓縮的頁面最小字節(jié)數(shù)，頁面字節(jié)數(shù)從 header 頭中的 Content-Length 中進行獲取。默認值是 0，不管頁面多大都壓縮。建議設(shè)置成大于 1k 的字節(jié)數(shù)，小于 1k 可能會越壓越大；
• gzip_http_version：默認 1.1，啟用 gzip 所需的 HTTP 最低版本；

查看配置是否生效，查看響應(yīng)頭中的 Content-Encoding 字段，值為 gzip。

注意：一般 gzip 的配置建議加上 gzip_min_length 1k，否則會因為文件太小，壓縮后體積還比壓縮之前體積還大，所以最好設(shè)置 1kb 的文件就不要 gzip 壓縮了。

Webpack 的 gzip 配置

當(dāng)前端項目使用 Webpack 進行打包的時候，也可以開啟 gzip 壓縮：

// vue-cli3 的 vue.config.js 文件
const CompressionWebpackPlugin = require('compression-webpack-plugin')

module.exports = {
  // gzip 配置
  configureWebpack: config => {
    if (process.env.NODE_ENV === 'production') {
      // 生產(chǎn)環(huán)境
      return {
        plugins: [new CompressionWebpackPlugin({
          test: /\.js$|\.html$|\.css/,    // 匹配文件名
          threshold: 10240,               // 文件壓縮閾值，對超過10k的進行壓縮
          deleteOriginalAssets: false     // 是否刪除源文件
        })]
      }
    }
  },
  ...
}

既然已經(jīng)有 Nginx 的 gzip 壓縮了，為什么還需要 Webpack 進行 gzip 壓縮？

因為如果全都是使用 Nginx 來壓縮文件，會耗費服務(wù)器的計算資源，如果服務(wù)器的 gzip_comp_level 配置的比較高，就更增加服務(wù)器的開銷，相應(yīng)增加客戶端的請求時間，得不償失。如果壓縮的動作在前端打包的時候就做了，把打包之后的高壓縮等級文件作為靜態(tài)資源放在服務(wù)器上，Nginx 會優(yōu)先查找這些壓縮之后的文件返回給客戶端，相當(dāng)于把壓縮文件的動作從 Nginx 提前給 Webpack 打包的時候完成，節(jié)約了服務(wù)器資源，所以一般推介在生產(chǎn)環(huán)境應(yīng)用 Webpack 配置 gzip 壓縮。

瀏覽器緩存

瀏覽器緩存是為了加速瀏覽，瀏覽器在用戶磁盤上，對最近請求過的文檔進行存儲。當(dāng)訪問者再次請求這個頁面時，瀏覽器就可以從本地磁盤顯示文檔，這樣，就可以加速頁面的閱覽，緩存的方式節(jié)約了網(wǎng)絡(luò)的資源，提高了網(wǎng)絡(luò)的效率。

瀏覽器緩存可以通過添加 expires 和 cache-control 頭來實現(xiàn)。

HTTP 協(xié)議的 Cache -Control 指定請求和響應(yīng)遵循的緩存機制。在請求消息或響應(yīng)消息中設(shè)置 Cache-Control 并不會影響另一個消息處理過程中的緩存處理過程。

• 請求時的緩存指令：no-cache、no-store、max-age、max-stale、min-fresh、only-if-cache 等
• 響應(yīng)消息中的指令：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

設(shè)置絕對過期時間

設(shè)置以分鐘為單位的絕對過期時間, 優(yōu)先級比 Cache-Control 低, 同時設(shè)置 Expires 和 Cache-Control 則后者生效。也就是說要注意一點: Cache-Control 的優(yōu)先級高于 Expires。

expires 起到控制頁面緩存的作用，合理配置 expires 可以減少很多服務(wù)器的請求，expires 的配置可以在 HTTP 段中或者 server 段中或者 location 段中。比如控制圖片等過期時間為 30 天, 可以配置如下:

# 對 html 文件緩存 24 小時
location ~ .*\.(htm|html)$ {
  expires 24h;

  root /var/www/html;
}

# 對常見格式的圖片在瀏覽器本地緩存 30 天
location ~ .*\.(gif|jpg|jpeg|png|bmp|ico)$ {
  expires 30d;

  root /var/www/img/
}

# 設(shè)置無限的緩存時間
location ~ \.(wma|wmv|asf|mp3|mmf|zip|rar|swf|flv)$ {
  expires max;

  root /var/www/upload/;
}

設(shè)置相對過期時間

Cache-Control 通用消息頭字段被用于在 HTTP 請求和響應(yīng)中通過指定指令來實現(xiàn)緩存機制。緩存指令是單向的, 這意味著在請求設(shè)置的指令，在響應(yīng)中不一定包含相同的指令。

指令不區(qū)分大小寫，并且具有可選參數(shù)，可以用令牌或者帶引號的字符串語法。多個指令以逗號分隔。

• 可緩存性
  • public： 表明響應(yīng)可以被任何對象（包括：發(fā)送請求的客戶端，代理服務(wù)器，等等）緩存。表示相應(yīng)會被緩存，并且在多用戶間共享。默認是 public
  • private：表明響應(yīng)只能被單個用戶緩存，不能作為共享緩存（即代理服務(wù)器不能緩存它）,可以緩存響應(yīng)內(nèi)容。響應(yīng)只作為私有的緩存，不能在用戶間共享。如果要求 HTTP 認證，響應(yīng)會自動設(shè)置為 private
  • no-cache： 在釋放緩存副本之前，強制高速緩存將請求提交給原始服務(wù)器進行驗證。指定不緩存響應(yīng)，表明資源不進行緩存。但是設(shè)置了 no-cache 之后并不代表瀏覽器不緩存，而是在緩存前要向服務(wù)器確認資源是否被更改。因此有的時候只設(shè)置 no-cache 防止緩存還是不夠保險，還可以加上 private 指令，將過期時間設(shè)為過去的時間
  • only-if-cached：表明客戶端只接受已緩存的響應(yīng)，并且不要向原始服務(wù)器檢查是否有更新的拷貝
• 到期
  • max-age=<seconds>：設(shè)置緩存存儲的最大周期，超過這個時間緩存被認為過期（單位秒）。與 Expires 相反，時間是相對于請求的時間。max-age 會覆蓋掉 Expires
  • s-maxage=<seconds>：覆蓋 max-age 或者 Expires 頭，但是僅適用于共享緩存（比如各個代理），并且私有緩存中它被忽略。也就是說 s-maxage 只用于共享緩存，比如 CDN 緩存（s -> share）。與 max-age 的區(qū)別是：max-age 用于普通緩存，而 s-maxage 用于代理緩存。如果存在 s-maxage，則會覆蓋 max-age 和 Expires
  • max-stale[=<seconds>]：表明客戶端愿意接收一個已經(jīng)過期的資源。 可選的設(shè)置一個時間（單位秒），表示響應(yīng)不能超過的過時時間
  • min-fresh=<seconds>： 表示客戶端希望在指定的時間內(nèi)獲取最新的響應(yīng)
  • stale-while-revalidate=<seconds>：表明客戶端愿意接受陳舊的響應(yīng)，同時在后臺異步檢查新的響應(yīng)。秒值指示客戶愿意接受陳舊響應(yīng)的時間長度
  • stale-if-error=<seconds>：表示如果新的檢查失敗，則客戶愿意接受陳舊的響應(yīng)。秒數(shù)值表示客戶在初始到期后愿意接受陳舊響應(yīng)的時間
• 重新驗證和重新加載
  • must-revalidate：緩存必須在使用之前驗證舊資源的狀態(tài)，并且不可使用過期資源。表示如果頁面過期，則去服務(wù)器進行獲取
  • proxy-revalidate：與 must-revalidate 作用相同，但它僅適用于共享緩存（例如代理），并被私有緩存忽略
  • immutable：表示響應(yīng)正文不會隨時間而改變。資源（如果未過期）在服務(wù)器上不發(fā)生改變，因此客戶端不應(yīng)發(fā)送重新驗證請求頭（例如 If-None-Match 或 If-Modified-Since）來檢查更新，即使用戶顯式地刷新頁面
• 其他
  • no-store：緩存不應(yīng)存儲有關(guān)客戶端請求或服務(wù)器響應(yīng)的任何內(nèi)容。表示絕對禁止緩存!
  • no-transform： 不得對資源進行轉(zhuǎn)換或轉(zhuǎn)變。Content-Encoding、Content-Range 和 Content-Type 等 HTTP 頭不能由代理修改。例如，非透明代理可以對圖像格式進行轉(zhuǎn)換，以便節(jié)省緩存空間或者減少緩慢鏈路上的流量。 no-transform 指令不允許這樣做。

設(shè)置相對過期時間, max-age 指明以秒為單位的緩存時間. 若對靜態(tài)資源只緩存一次, 可以設(shè)置 max-age 的值為 315360000000（一萬年）。比如對于提交的訂單，為了防止瀏覽器回退重新提交，可以使用 Cache-Control 之 no-store 絕對禁止緩存，即便瀏覽器回退依然請求的是服務(wù)器，進而判斷訂單的狀態(tài)給出相應(yīng)的提示信息！

# 匹配 URI 時返回的靜態(tài)資源緩存 3600 毫秒
if ($request_uri ~* "^/$|^/search/.+/|^/company/.+/") {
   add_header    Cache-Control  max-age=3600;
}

# 應(yīng)用中不會改變的文件，通?？梢栽侔l(fā)送響應(yīng)頭前添加積極緩存
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control public,max-age=31536000;
}

# 緩存前要向服務(wù)器確認資源是否被更改
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control no-cache;
}

# 禁止緩存
location ~* \.(js|css|png|jpg|gif)$ {
    add_header  Cache-Control no-store,no-cache,must-revalidate;
}

特別區(qū)分：

• no-cache：瀏覽器和緩存服務(wù)器都不應(yīng)該緩存頁面信息
• no-store： 請求和響應(yīng)的信息都不應(yīng)該被存儲在對方的磁盤系統(tǒng)中

資源最后修改時間

該資源的最后修改時間，在瀏覽器下一次請求資源時，瀏覽器將先發(fā)送一個請求到服務(wù)器上, 并附上 If-Unmodified-Since 頭來說明瀏覽器所緩存資源的最后修改時間, 如果服務(wù)器發(fā)現(xiàn)沒有修改, 則直接返回 304（Not Modified）回應(yīng)信息給瀏覽器（內(nèi)容很少），如果服務(wù)器對比時間發(fā)現(xiàn)修改了，則照常返回所請求的資源。

需要注意：

• Last-Modified 屬性通常和 Expires 或 Cache-Control 屬性配合使用, 因為即使瀏覽器設(shè)置緩存, 當(dāng)用戶點擊 刷新 按鈕時, 瀏覽器會忽略緩存繼續(xù)向服務(wù)器發(fā)送請求, 這時 Last-Modified 將能夠很好的減小回應(yīng)開銷
• ETag 將返回給瀏覽器一個資源 ID, 如果有了新版本則正常發(fā)送并附上新 ID，否則返回 304，但是在服務(wù)器集群情況下，每個服務(wù)器將返回不同的 ID，因此不建議使用 ETag

資源緩存策略

瀏覽器緩存 Header：expires、cache-control、last-modified、etag。

• 200 狀態(tài)：當(dāng)瀏覽器本地沒有緩存或者下一層失效時，或者用戶強制刷新時，瀏覽器直接去服務(wù)器獲取最新資源
• 304 狀態(tài)：由 Last-Modified / Etag 控制。當(dāng)下一層失效時活用戶刷新時，瀏覽器就會發(fā)送請求給服務(wù)器，如果服務(wù)端沒有變更，則返回 304 給瀏覽器
• 200 狀態(tài)（from cache）：由 Expires / Cache-Control 控制，Expires 是絕對時間，Cache-Control 是相對時間，兩者都存在時，Cache-Control 覆蓋 Expires 只要沒有失效，瀏覽器只訪問自己的緩存

通用策略：

• 對于 HTML 文件，cache-control 設(shè)置為 no-cache
• 對于 JS、圖片、CSS、字體等，設(shè)置 max-age=2592000，也就是 30 天

location ~ .* \.(js)$ {
  add_header Cache-Control public;

  expires 24h;
}

location ~ .* \.(css)$ {
  add_header Cache-Control public;

  expires 86400;

  etag on;
}

location ~ .*\(gif|jpg|jpeg|png)$ {
  add_header Cache-Control must-revalidate;

  etag on;
}

集群分布式部署建議關(guān)閉 Etag，因為每臺機器生成的 Hash 是不同的。

配置 CORS 跨域訪問

假設(shè)有兩個域名 mrsingsing.com 和 api.mrsingsing.com，如果 mrsingsing.com 域名想請求 api.mrsingsing.com 域名下的資源會因為 host 不一致存在跨域的問題。

反向代理解決跨域

為了繞開瀏覽器的跨域安全限制，需要將請求的域名由 api.mrsingsing.com 改為 mrsingsing.com。同時約定 URL 規(guī)則來表明代理請求的身份，然后 Nginx 通過匹配該規(guī)則，將請求代理回原來的域。

server {
    listen 9001;
    server_name mrsingsing.com;

    location / {
        proxy_pass api.mrsingsing.com;
    }
}

這里對靜態(tài)文件的請求和后端服務(wù)的請求都以 mrsingsing.com 開始，不易區(qū)分，所以通常為了實現(xiàn)對后端服務(wù)請求的統(tǒng)一轉(zhuǎn)發(fā)，通常我們會約定對后端服務(wù)的請求加上 /api/ 的前綴或者其他的 path 來和靜態(tài)資源的請求加以區(qū)分：

# 請求跨域，約定代理后端服務(wù)請求 path 以 /api/ 開頭
location ^~/api/ {
    # 這里重寫了請求，講正則匹配中的一個分組的 path 拼接到真正的請求后面，并用 break 停止后續(xù)匹配
    rewrite ^/api/(.*)$ /$1 break;
    poxy_pass api.mrsingsing.com;

    # 兩個域名之間 Cookie 的傳遞與回寫
    proxy_cookie_domain api.mrsingsing.com mrsingsing.com;
}

這樣其實是通過 Nginx，用類似于 Hack 的方式規(guī)避了瀏覽器的跨域限制，實現(xiàn)了跨域訪問。

這樣，靜態(tài)資源我們使用 mrsingsing.com/index.html，動態(tài)資源我們使用 mrsingsing.com/api/getOrderList，瀏覽器頁面看起來仍然訪問的前端服務(wù)器，繞過了瀏覽器的通源策略，畢竟我們看起來并沒有跨域。

配置 header 解決跨域

在 Nginx 配置中配置對應(yīng)二級域名 api.mrsingsing.com：

# /etc/nginx/conf.d/api.mrsingsing.com.conf

server {
    listen       80;
    server_name  api.mrsingsing.com;

    add_header 'Access-Control-Allow-Origin' $http_origin;                              # 全局變量獲得當(dāng)前請求 origin，帶 Cookie 的請求不支持 *（通配符）
    add_header 'Access-Control-Allow-Credentials' 'true';                               # 為 true 可帶上 cookie
    add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';                     # 允許請求方法
    add_header 'Access-Control-Allow-Headers' $http_access_control_request_headers;     # 允許請求的 header，可以為 *（通配符）
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';

    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Max-Age' 1728000;                                    # OPTIONS 請求的有效期，在有效期內(nèi)不用發(fā)出另一條預(yù)檢請求
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;

        return 204;  # 200 也可以
    }

    location / {
        root  /usr/share/nginx/html/be;
        index index.html;
    }
}

防盜鏈

防盜鏈機制的目的是防止服務(wù)器上的資源（例如圖片、文件等）被其它用戶采用其它的技術(shù)手段來訪問或下載。

實現(xiàn)方式：區(qū)別哪些請求是非正常的用戶請求

基于 http_refer 防盜鏈配置模塊：

location ~* \.(gif|jpg|png|jpeg)$ {
    # 只允許 192.168.0.1 請求資源
    # none 表示沒帶 refer
    # blocked 表示不是標準 HTTP 請求
    valid_referers none blocked 192.168.0.1;

    if ($invalid_referer) {
        rewrite ^/ http://$host/logo.png;
    }
}

• 設(shè)置防盜鏈文件類型，自行修改，每個后綴用 | 符號分隔
• 允許文件鏈出的域名白名單，自行修改成己方域名，域名與域名之間使用空格隔開

圖片處理

在前端開發(fā)中，經(jīng)常需要不同尺寸的圖片。現(xiàn)在的云儲存基本對圖片都提供有處理服務(wù)（一般是通過在圖片鏈接上加參數(shù)）。其實用 Nginx，可以通過幾十行配置，搭建出一個屬于自己的本地圖片處理服務(wù)，完全能夠滿足日常對圖片的裁剪/縮放/旋轉(zhuǎn)/圖片品質(zhì)等處理需求。要用到 ngx_http_image_filter_module 模塊。這個模塊是非基本模塊，需要安裝。

下面是圖片縮放功能部分的 Nginx 配置：

# 圖片縮放處理
# 這里約定的圖片處理 url 格式：以 example.com/img/ 路徑訪問
location ~* /img/(.+)$ {
    # 圖片服務(wù)端儲存地址
    alias /Users/cc/Desktop/server/static/image/$1;
    # 圖片寬度默認值
    set $width -;
    # 圖片高度默認值
    set $height -;
    if ($arg_width != "") {
        set $width $arg_width;
    }
    if ($arg_height != "") {
        set $height $arg_height;
    }
    #設(shè)置圖片寬高
    image_filter resize $width $height;
    #設(shè)置Nginx讀取圖片的最大buffer
    image_filter_buffer 10M;
    # 是否開啟圖片圖像隔行掃描
    image_filter_interlace on;
    # 圖片處理錯誤提示圖，例如縮放參數(shù)不是數(shù)字
    error_page 415 = 415.png;
}

到此這篇關(guān)于Nginx靜態(tài)資源服務(wù)器的實現(xiàn)示例的文章就介紹到這了,更多相關(guān)Nginx靜態(tài)資源服務(wù)器內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！