提醒：本文最後更新於 1323 天前，文中所描述的資訊可能已發生改變，請謹慎使用。

在介紹完我部落格（imququ.com）的 Nginx 配置中與安全有關的一些配置後，這篇文章繼續介紹與效能有關的一些配置。WEB 效能優化是一個系統工程，涵蓋很多方面，做好其中某個環節並不意味效能就能變好，但可以肯定地說，如果某個環節做得很糟糕，那麼結果一定會變差。

首先說明下，本文提到的一些 Nginx 配置，需要較高版本 Linux 核心才支援。在實際生產環境中，升級伺服器核心並不是一件容易的事，但為了獲得最好的效能，有些升級還是必須的。很多公司伺服器運維和專案開發並不在一個團隊，一方追求穩定不出事故，另一方希望提升效能，本來就是矛盾的。好在我們折騰自己 VPS 時，可以無視這些限制。

TCP 優化

Nginx 關於 TCP 的優化基本都是修改系統核心提供的配置項，所以跟具體的 Linux 版本和系統配置有關，我對這一塊還不是非常熟悉，這裡只能簡單介紹下：

http {
    sendfile           on;
    tcp_nopush         on;
    tcp_nodelay        on;

    keepalive_timeout  60;
    ... ...
}

第一行的 sendfile 配置可以提高 Nginx 靜態資源託管效率。sendfile 是一個系統呼叫，直接在核心空間完成檔案傳送，不需要先 read 再 write，沒有上下文切換開銷。

TCP_NOPUSH 是 FreeBSD 的一個 socket 選項，對應 Linux 的 TCP_CORK，Nginx 裡統一用 tcp_nopush 來控制它，並且只有在啟用了 sendfile 之後才生效。啟用它之後，資料包會累計到一定大小之後才會傳送，減小了額外開銷，提高網路效率。

TCP_NODELAY 也是一個 socket 選項，啟用後會禁用 Nagle 演算法，儘快傳送資料，某些情況下可以節約 200ms（Nagle 演算法原理是：在發出去的資料還未被確認之前，新生成的小資料先存起來，湊滿一個 MSS 或者等到收到確認後再發送）。Nginx 只會針對處於 keep-alive 狀態的 TCP 連線才會啟用 tcp_nodelay

可以看到 TCP_NOPUSH 是要等資料包累積到一定大小才傳送，TCP_NODELAY 是要儘快傳送，二者相互矛盾。實際上，它們確實可以一起用，最終的效果是先填滿包，再儘快傳送。

配置最後一行用來指定服務端為每個 TCP 連線最多可以保持多長時間。Nginx 的預設值是 75 秒，有些瀏覽器最多隻保持 60 秒，所以我統一設定為 60。

另外，還有一個 TCP 優化策略叫 TCP Fast Open（TFO），這裡先介紹下，配置在後面貼出。TFO 的作用是用來優化 TCP 握手過程。客戶端第一次建立連線還是要走三次握手，所不同的是客戶端在第一個 SYN 會設定一個 Fast Open 標識，服務端會生成 Fast Open Cookie 並放在 SYN-ACK 裡，然後客戶端就可以把這個 Cookie 存起來供之後的 SYN 用。下面這個圖形象地描述了這個過程：

關於 TCP Fast Open 的更多資訊，可以檢視 RFC7413，或者這篇文章：Shaving your RTT with TCP Fast Open。需要注意的是，現階段只有 Linux、ChromeOS 和 Android 5.0 的 Chrome / Chromium 才支援 TFO，所以實際用途並不大。

5 月 26 日釋出的 Nginx 1.9.1，增加了 reuseport 功能，意味著 Nginx 也開始支援 TCP 的 SO_REUSEPORT 選項了。這裡也先簡單介紹下，具體配置方法後面統一介紹。啟用這個功能後，Nginx 會在指定的埠上監聽多個 socket，每個 Worker 都能分到一個。請求過來時，系統核心會自動通過不同的 socket 分配給對應的 Worker，相比之前的單 socket 多 Worker 的模式，提高了分發效率。下面這個圖形象地描述了這個過程：

開啟 Gzip

我們在上線前，程式碼（JS、CSS 和 HTML）會做壓縮，圖片也會做壓縮（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。對於文字檔案，在服務端傳送響應之前進行 GZip 壓縮也很重要，通常壓縮後的文字大小會減小到原來的 1/4 - 1/3。下面是我的配置：

http {
    gzip               on;
    gzip_vary          on;

    gzip_comp_level    6;
    gzip_buffers       16 8k;

    gzip_min_length    1000;
    gzip_proxied       any;
    gzip_disable       "msie6";

    gzip_http_version  1.0;

    gzip_types         text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
    ... ...
}

這部分內容比較簡單，只有兩個地方需要解釋下：

gzip_vary 用來輸出 Vary 響應頭，用來解決某些快取服務的一個問題，詳情請看我之前的部落格：HTTP 協議中 Vary 的一些研究。

gzip_disable 指令接受一個正則表示式，當請求頭中的 UserAgent 欄位滿足這個正則時，響應不會啟用 GZip，這是為了解決在某些瀏覽器啟用 GZip 帶來的問題。特別地，指令值 msie6 等價於 MSIE [4-6]\.，但效能更好一些。另外，Nginx 0.8.11 後，msie6 並不會匹配 UA 包含 SV1 的 IE6（例如 Windows XP SP2 上的 IE6），因為這個版本的 IE6 已經修復了關於 GZip 的若干 Bug。

預設 Nginx 只會針對 HTTP/1.1 及以上的請求才會啟用 GZip，因為部分早期的 HTTP/1.0 客戶端在處理 GZip 時有 Bug。現在基本上可以忽略這種情況，於是可以指定 gzip_http_version 1.0 來針對 HTTP/1.0 及以上的請求開啟 GZip。

開啟快取

優化程式碼邏輯的極限是移除所有邏輯；優化請求的極限是不傳送任何請求。這兩點通過快取都可以實現。

服務端

我的部落格更新並不頻繁，評論部分也早就換成了 Disqus，所以完全可以將頁面靜態化，這樣就省掉了所有程式碼邏輯和資料庫開銷。實現靜態化有很多種方案，我直接用的是 Nginx 的 proxy_cache（注：本部落格為了做更精細的靜態化，已經將快取邏輯挪到 Web 應用裡實現了）：

proxy_cache_path  /home/jerry/cache/nginx/proxy_cache_path levels=1:2 keys_zone=pnc:300m inactive=7d max_size=10g;
proxy_temp_path   /home/jerry/cache/nginx/proxy_temp_path;
proxy_cache_key   $host$uri$is_args$args;

server {
    location / {
        resolver                  127.0.0.1;  
        proxy_cache               pnc;
        proxy_cache_valid         200 304 2h;
        proxy_cache_lock          on;
        proxy_cache_lock_timeout  5s;
        proxy_cache_use_stale     updating error timeout invalid_header http_500 http_502;

        proxy_http_version        1.1;

        proxy_ignore_headers      Set-Cookie;
        ... ...
    }
    ... ...
}

首先，在配置最外層定義一個快取目錄，並指定名稱（keys_zone）和其他屬性，這樣在配置 proxy_pass 時，就可以使用這個快取了。這裡我對狀態值等於 200 和 304 的響應快取了 2 小時。

預設情況下，如果響應頭裡有 Set-Cookie 欄位，Nginx 並不會快取這次響應，因為它認為這次響應的內容是因人而異的。我的部落格中，這個 Set-Cookie 對於使用者來說沒有用，也不會影響輸出內容，所以我通過配置 proxy_ignore_header 移除了它。

客戶端

服務端在輸出響應時，可以通過響應頭輸出一些與快取有關的資訊，從而達到少發或不發請求的目的。HTTP/1.1 的快取機制稍微有點複雜，這裡簡單介紹下：

首先，服務端可以通過響應頭裡的 Last-Modified（最後修改時間） 或者 ETag（內容特徵） 標記實體。瀏覽器會存下這些標記，並在下次請求時帶上 If-Modified-Since: 上次 Last-Modified 的內容 或 If-None-Match: 上次 ETag 的內容，詢問服務端資源是否過期。如果服務端發現並沒有過期，直接返回一個狀態碼為 304、正文為空的響應，告知瀏覽器使用本地快取；如果資源有更新，服務端返回狀態碼 200、新的 Last-Modified、Etag 和正文。這個過程被稱之為 HTTP 的協商快取，通常也叫做弱快取。

可以看到協商快取並不會節省連線數，但是在快取生效時，會大幅減小傳輸內容（304 響應沒有正文，一般只有幾百位元組）。另外為什麼有兩個響應頭都可以用來實現協商快取呢？這是因為一開始用的 Last-Modified 有兩個問題：1）只能精確到秒，1 秒內的多次變化反映不出來；2）時間採用絕對值，如果服務端 / 客戶端時間不對都可能導致快取失效在輪詢的負載均衡演算法中，如果各機器讀到的檔案修改時間不一致，有快取無故失效和快取不更新的風險。HTTP/1.1 並沒有規定 ETag 的生成規則，而一般實現者都是對資源內容做摘要，能解決前面兩個問題。

另外一種快取機制是服務端通過響應頭告訴瀏覽器，在什麼時間之前（Expires）或在多長時間之內（Cache-Control: Max-age=xxx），不要再請求伺服器了。這個機制我們通常稱之為 HTTP 的強快取。

一旦資源命中強快取規則後，再次訪問完全沒有 HTTP 請求（Chrome 開發者工具的 Network 面板依然會顯示請求，但是會註明 from cache；Firefox 的 firebug 也類似，會註明 BFCache），這會大幅提升效能。所以我們一般會對 CSS、JS、圖片等資源使用強快取，而入口檔案（HTML）一般使用協商快取或不快取，這樣可以通過修改入口檔案中對強快取資源的引入 URL 來達到即時更新的目的。

這裡也解釋下為什麼有了 Expires，還要有 Cache-Control。也有兩個原因：1）Cache-Control 功能更強大，對快取的控制能力更強；2）Cache-Control 採用的 max-age 是相對時間，不受服務端 / 客戶端時間不對的影響。

另外關於瀏覽器的重新整理（F5 / cmd + r）和強刷（Ctrl + F5 / shift + cmd +r）：普通重新整理會使用協商快取，忽略強快取；強刷會忽略瀏覽器所有快取（並且請求頭會攜帶 Cache-Control:no-cache 和 Pragma:no-cache，用來通知所有中間節點忽略快取）。只有從位址列或收藏夾輸入網址、點選連結等情況下，瀏覽器才會使用強快取。

預設情況下，Nginx 對於靜態資源都會輸出 Last-Modified，而 ETag、Expires 和 Cache-Control 則需要自己配置：

location ~ ^/static/ {
    root      /home/jerry/www/blog/www;
    etag      on;
    expires   max;
}

expires 指令可以指定具體的 max-age，例如 10y 代表 10 年，如果指定為 max，最終輸出的 Expires 會是 2037 年最後一天，Cache-Control 的 max-age 會是 10 年（準確說是 3650 天，315360000 秒）。

使用 SPDY（HTTP/2）

我的部落格之前多次講到過 HTTP/2（SPDY），現階段 Nginx 只支援 SPDY/3.1，這樣配置就可以啟用了（編譯 Nginx 時需要加上 --with-http_spdy_module 和 --with-http_ssl_module）：

server {
    listen             443 ssl spdy fastopen=3 reuseport;
    spdy_headers_comp  6;
    ... ...
}

那個 fastopen=3 用來開啟前面介紹過的 TCP Fast Open 功能。3 代表最多隻能有 3 個未經三次握手的 TCP 連結在排隊。超過這個限制，服務端會退化到採用普通的 TCP 握手流程。這是為了減少資源耗盡攻擊：TFO 可以在第一次 SYN 的時候傳送 HTTP 請求，而服務端會校驗 Fast Open Cookie（FOC），如果通過就開始處理請求。如果不加限制，惡意客戶端可以利用合法的 FOC 傳送大量請求耗光服務端資源。

reuseport 就是用來啟用前面介紹過的 TCP SO_REUSEPORT 選項的配置。

HTTPS 優化

建立 HTTPS 連線本身就慢（多了獲取證書、校驗證書、TLS 握手等等步驟），如果沒有優化好只能是慢上加慢。

server {
    ssl_session_cache        shared:SSL:10m;
    ssl_session_timeout      60m;

    ssl_session_tickets      on;

    ssl_stapling             on;
    ssl_stapling_verify      on;
    ssl_trusted_certificate  /xxx/full_chain.crt;

    resolver                 8.8.4.4 8.8.8.8  valid=300s;
    resolver_timeout         10s;
    ... ...
}

我的這部分配置就兩部分內容：TLS 會話恢復和 OCSP stapling。

TLS 會話恢復的目的是為了簡化 TLS 握手，有兩種方案：Session Cache 和 Session Ticket。他們都是將之前握手的 Session 存起來供後續連線使用，所不同是 Cache 存在服務端，佔用服務端資源；Ticket 存在客戶端，不佔用服務端資源。另外目前主流瀏覽器都支援 Session Cache，而 Session Ticket 的支援度一般。

ssl_stapling 開始的幾行用來配置 OCSP stapling 策略。瀏覽器可能會在建立 TLS 連線時線上驗證證書有效性，從而阻塞 TLS 握手，拖慢整體速度。OCSP stapling 是一種優化措施，服務端通過它可以在證書鏈中封裝證書頒發機構的 OCSP（Online Certificate Status Protocol）響應，從而讓瀏覽器跳過線上查詢。服務端獲取 OCSP 一方面更快（因為服務端一般有更好的網路環境），另一方面可以更好地快取。有關 OCSP stapling 的詳細介紹，可以看這裡。

這些策略設定好之後，可以通過 Qualys SSL Server Test 這個工具來驗證是否生效，例如下圖就是本部落格的測試結果（via）：

在給 Nginx 指定證書時，需要選擇合適的證書鏈。因為瀏覽器在驗證證書信任鏈時，會從站點證書開始，遞迴驗證父證書，直至信任的根證書。這裡涉及到兩個問題：1）伺服器證書是在握手期間傳送的，由於 TCP 初始擁塞視窗的存在，如果證書太長很可能會產生額外的往返開銷；2）如果服務端證書沒包含中間證書，大部分瀏覽器可以正常工作，但會暫停驗證並根據子證書指定的父證書 URL 自己獲取中間證書。這個過程會產生額外的 DNS 解析、建立 TCP 連線等開銷。配置服務端證書鏈的最佳實踐是包含站點證書和中間證書兩部分。有的證書提供商簽出來的證書級別比較多，這會導致證書鏈變長，選擇的時候需要特別注意。

好了，我的部落格關於安全和效能兩部分 Nginx 配置終於都寫完了。實際上很多策略沒辦法嚴格區分是為了安全還是效能，比如 HSTS 和 CHACHA20_POLY1305，兩方面都有考慮，所以寫的時候比較糾結，早知道就合成一篇來寫了。

--EOF--

發表於 2015-05-27 02:46:20 ，並被新增「 Nginx 、 效能優化 」標籤 ，最後修改於 2015-05-28 19:13:47 。檢視本文 Markdown 版本 »

提醒：本文最後更新於 1323 天前，文中所描述的資訊可能已發生改變，請謹慎使用。