Nginx 教程（2）：效能
大家好，分享即關愛，我們很樂意和你分享一些新的知識，我們準備了一個 Nginx 的教程，分為三個系列，如果你對 Nginx 有所耳聞，或者想增進 Nginx 方面的經驗和理解，那麼恭喜你來對地方了。
我們會告訴你 Nginx 如何工作及其背後的理念，還有如何優化以加快應用的效能，如何安裝啟動和保持執行。
這個教程有三個部分：
- 基本概念 —— 這部分需要去了解 Nginx 的一些指令和使用場景，繼承模型，以及 Nginx 如何選擇 server 塊，location 的順序。
- 效能 —— 介紹改善 Nginx 速度的方法和技巧，我們會在這裡談及 gzip 壓縮，快取，buffer 和超時。
- SSL 安裝 —— 如何配置伺服器使用 HTTPS
建立這個系列，我們希望，一是作為參考書，可以通過快速查詢到相關問題（比如 gzip 壓縮，SSL 等）的解決方式，也可以直接通讀全文。為了獲得更好的學習效果，我們建議你在本機安裝 Nginx 並且嘗試進行實踐。
tcp_nodelay, tcp_nopush 和 sendfile
tcp_nodelay
在 TCP 發展早期，工程師需要面對流量衝突和堵塞的問題，其中湧現了大批的解決方案，其中之一是由 John Nagle 提出的演算法。
Nagle 的演算法旨在防止通訊被大量的小包淹沒。該理論不涉及全尺寸 tcp 包（最大報文長度，簡稱 MSS）的處理。只針對比 MSS 小的包，只有當接收方成功地將以前的包(ACK)的所有確認傳送回來時，這些包才會被髮送。在等待期間，傳送方可以緩衝更多的資料之後再發送。
| 1234567 | if package.size >= MSS.size send(package)elsif acks.all_received? send(package)else # acumulate data |
與此同時，誕生了另一個理論，延時 ACK
在 TCP 通訊中，在傳送資料後，需要接收回應包(ACK)來確認資料被成功傳達。
延時 ACK 旨在解決線路被大量的 ACK 包擁堵的狀況。為了減少 ACK 包的數量，接收者等待需要回傳的資料加上 ACK 包回傳給傳送方，如果沒有資料需要回傳，必須在至少每 2 個 MSS，或每 200 至 500 毫秒內傳送 ACK（以防我們不再收到包）。
| 1234567 | if packages.any? sendelsif last_ack_send_more_than_2MSS_ago? || 200_ms_timer.finished? sendelse # waitend |
正如你可能在一開始就注意到的那樣 —— 這可能會導致在持久連線上的一些暫時的死鎖。讓我們重現它！
假設：
- 初始擁塞視窗等於 2。擁塞視窗是另一個 TCP 機制的一部分，稱為慢啟動。細節現在並不重要，只要記住它限制了一次可以傳送多少個包。在第一次往返中，我們可以傳送 2 個 MSS 包。在第二次傳送中：4 個 MSS 包，第三次傳送中：8 個MSS，依此類推。
- 4 個已快取的等待發送的資料包：A, B, C, D
- A, B, C是 MSS 包
- D 是一個小包
場景：
- 由於是初始的擁塞視窗，傳送端被允許傳送兩個包：A 和 B
- 接收端在成功獲得這兩個包之後，傳送一個 ACK
- 發件端傳送 C 包。然而，Nagle 卻阻止它傳送 D 包（包長度太小，等待 C 的ACK）
- 在接收端，延遲 ACK 使他無法傳送 ACK（每隔 2 個包或每隔 200 毫秒傳送一次）
- 在 200ms 之後，接收器傳送 C 包的 ACK
- 傳送端收到 ACK 併發送 D 包
在這個資料交換過程中，由於 Nagel 和延遲 ACK 之間的死鎖，引入了 200ms 的延遲。
Nagle 演算法是當時真正的救世主，而且目前仍然具有極大的價值。但在大多數情況下，我們不會在我們的網站上使用它，因此可以通過新增 TCP_NODELAY 標誌來安全地關閉它。
| 1 | tcp_nodelay on; # sets TCP_NODELAY flag, used on keep-alive connections |
享受這200ms提速吧！
更多的細節，推薦閱讀其他優秀的文章。
sendfile
正常來說，當要傳送一個檔案時需要下面的步驟：
- malloc(3) – 分配一個本地緩衝區，儲存物件資料。
- read(2) – 檢索和複製物件到本地緩衝區。
- write(2) – 從本地緩衝區複製物件到 socket 緩衝區。
這涉及到兩個上下文切換（讀，寫），並使相同物件的第二個副本成為不必要的。正如你所看到的，這不是最佳的方式。值得慶幸的是還有另一個系統呼叫，提升了傳送檔案（的效率），它被稱為：sendfile(2)（想不到吧！居然是這名字）。這個呼叫在檔案 cache 中檢索一個物件，並傳遞指標（不需要複製整個物件），直接傳遞到 socket 描述符，Netflix 表示，使用 sendfile(2) 將網路吞吐量從 6Gbps 提高到了 30Gbps。
然而，sendfile(2) 有一些注意事項：
- 不可用於 UNIX sockets（例如：當通過你的上游伺服器傳送靜態檔案時）
- 能否執行不同的操作，取決於作業系統（這裡檢視更多）
在 nginx 中開啟它
| 1 | sendfile on; |
tcp_nopush
tcp_nopush 與 tcp_nodelay 相反。不是為了儘可能快地推送資料包，它的目標是一次性優化資料的傳送量。
在傳送給客戶端之前，它將強制等待包達到最大長度(MSS)。而且這個指令只有在 sendfile 開啟時才起作用。
| 12 | sendfile on;tcp_nopush on; |
看起來 tcp_nopush 和 tcp_nodelay 是互斥的。但是，如果所有 3 個指令都開啟了，nginx 會：
- 確保資料包在傳送給客戶之前是已滿的
- 對於最後一個數據包，tcp_nopush 將被刪除 —— 允許 TCP 立即傳送，沒有 200ms 的延遲
我應該使用多少程序？
工作程序
worker_process 指令會指定：應該執行多少個 worker。預設情況下，此值設定為 1。最安全的設定是通過傳遞 auto 選項來使用核心數量。
但由於 Nginx 的架構，其處理請求的速度非常快 – 我們可能一次不會使用超過 2-4 個程序（除非你正在託管 Facebook 或在 nginx 內部執行一些 CPU 密集型的任務）。
| 1 | worker_process auto; |
worker 連線
與 worker_process 直接繫結的指令是 worker_connections。它指定一個工作程序可以一次開啟多少個連線。這個數目包括所有連線（例如與代理伺服器的連線），而不僅僅是與客戶端的連線。此外，值得記住的是，一個客戶端可以開啟多個連線，同時獲取其他資源。
| 1 | worker_connections 1024; |
開啟檔案數目限制
在基於 Unix 系統中的“一切都是檔案”。這意味著文件、目錄、管道甚至套接字都是檔案。系統對一個程序可以開啟多少檔案有一個限制。要檢視該限制：
| 12 | ulimit -Sn # soft limitulimit -Hn # hard limit |
這個系統限制必須根據 worker_connections 進行調整。任何傳入的連線都會開啟至少一個檔案（通常是兩個連線套接字以及後端連線套接字或磁碟上的靜態檔案）。所以這個值等於 worker_connections*2 是安全的。幸運的是，Nginx 提供了一個配置選項來增加這個系統的值。要使用這個配置，請新增具有適當數目的 worker_rlimit_nofile 指令並重新載入 nginx。
| 1 | worker_rlimit_nofile 2048; |
配置
| 123 | worker_process auto;worker_rlimit_nofile 2048; # Changes the limit on the maximum number of open files (RLIMIT_NOFILE) for worker processes.worker_connections 1024; # Sets the maximum number of simultaneous connections that can be opened by a worker process. |
最大連線數
如上所述，我們可以計算一次可以處理多少個併發連線：
| 12345 | 最大連線數 = worker_processes * worker_connections---------------------------------------------- (keep_alive_timeout + avg_response_time) * 2 |
keep_alive_timeout (後續有更多介紹) + avg_response_time 告訴我們：單個連線持續了多久。我們也除以 2，通常情況下，你將有一個客戶端開啟 2 個連線的情況：一個在 nginx 和客戶端之間，另一個在 nginx 和上游伺服器之間。
Gzip
啟用 gzip 可以顯著降低響應的（報文）大小，因此，客戶端（網頁）會顯得更快些。
壓縮級別
Gzip 有不同的壓縮級別，1 到 9 級。遞增這個級別將會減少檔案的大小，但也會增加資源消耗。作為標準我們將這個數字（級別）保持在 3 – 5 級，就像上面說的那樣，它將會得到較小的節省，同時也會得到更大的 CPU 使用率。
這有個通過 gzip 的不同的壓縮級別壓縮檔案的例子，0 代表未壓縮檔案。
| 1 | curl -I -H 'Accept-Encoding: gzip,deflate' https://netguru.co/ |
| 1234567891011 | ❯ du -sh ./* 64K ./0_gzip 16K ./1_gzip 12K ./2_gzip 12K ./3_gzip 12K ./4_gzip 12K ./5_gzip 12K ./6_gzip 12K ./7_gzip 12K ./8_gzip 12K ./9_gzip |
| 1234567891011 | ❯ ls -al-rw-r--r-- 1 matDobek staff 61711 3 Nov 08:46 0_gzip-rw-r--r-- 1 matDobek staff 12331 3 Nov 08:48 1_gzip-rw-r--r-- 1 matDobek staff 12123 3 Nov 08:48 2_gzip-rw-r--r-- 1 matDobek staff 12003 3 Nov 08:48 3_gzip-rw-r--r-- 1 matDobek staff 11264 3 Nov 08:49 4_gzip-rw-r--r-- 1 matDobek staff 11111 3 Nov 08:50 5_gzip-rw-r--r-- 1 matDobek staff 11097 3 Nov 08:50 6_gzip-rw-r--r-- 1 matDobek staff 11080 3 Nov 08:50 7_gzip-rw-r--r-- 1 matDobek staff 11071 3 Nov 08:51 8_gzip-rw-r--r-- 1 matDobek staff 11005 3 Nov 08:51 9_gzip |
gzip_http_version 1.1;
這條指令告訴 nginx 僅在 HTTP 1.1 以上的版本才能使用 gzip。我們在這裡不涉及 HTTP 1.0，至於 HTTP 1.0 版本，它是不可能既使用 keep-alive 和 gzip 的。因此你必須做出決定：使用 HTTP 1.0 的客戶端要麼錯過 gzip，要麼錯過 keep-alive。
配置
| 12345678910111213141516171819 | gzip on; # enable gzipgzip_http_version 1.1; # turn on gzip for http 1.1 and abovegzip_disable "msie6"; # IE 6 had issues with gzipgzip_comp_level 5; # inc compresion level, and CPU usagegzip_min_length 100; # minimal weight to gzip filegzip_proxied any; # enable gzip for proxied requests (e.g. CDN)gzip_buffers 16 8k; # compression buffers (if we exceed this value, disk will be used instead of RAM)gzip_vary on; # add header Vary Accept-Encoding (more on that in Caching section)# define files which should be compressedgzip_types text/plain;gzip_types text/css;gzip_types application/javascript;gzip_types application/json;gzip_types application/vnd.ms-fontobject;gzip_types application/x-font-ttf;gzip_types font/opentype;gzip_types image/svg+xml;gzip_types image/x-icon; |
快取
快取是另一回事，它能提升使用者的請求速度。
管理快取可以僅由 2 個 header 控制：
- 在 HTTP/1.1 中用
Cache-Control管理快取 - Pragma 對於 HTTP/1.0 客戶端的向後相容性
快取本身可以分為兩類：公共快取和私有快取。公共快取是被多個使用者共同使用的。專用快取專用於單個使用者。我們可以很容易地區分，應該使用哪種快取：
| 12 | add_header Cache-Control public;add_header Pragma public; |
對於標準資源，我們想儲存1個月：
| 12345 | location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 1M; add_header Cache-Control public; add_header Pragma public;} |
上面的配置似乎足夠了。然而，使用公共快取時有一個注意事項。
讓我們看看如果將我們的資源儲存在公共快取（如 CDN）中，URI 將是唯一的識別符號。在這種情況下，我們認為 gzip 是開啟的。
有2個瀏覽器：
- 舊的，不支援 gzip
- 新的，支援 gzip
舊的瀏覽器給 CDN 傳送了一個 netguru.co/style 請求。但是 CDN 也沒有這個資源，它將會給我們的伺服器傳送請求，並且返回未經壓縮的響應。CDN 在雜湊裡儲存檔案（為以後使用）：
| 12345 | { ... netguru. |