NGINX HTTP 模組核心指令設定與效能調校

– 7 分鐘閱讀

NGINX 作為廣泛使用的 Web 伺服器和反向代理伺服器，其效能和穩定性仰賴正確的設定。本文探討 NGINX HTTP 模組中幾個關鍵指令，包含處理 IE 重新導向的 msie_refresh、設定 DNS 伺服器的 resolver、控制版本號顯示的 server_tokens、允許自定義標頭底線的 underscores_in_headers，以及設定變數雜湊表大小的 variables_hash_max_size 和 variables_hash_bucket_size。這些指令影響 NGINX 的行為，從瀏覽器相容性到安全性，都扮演著重要的角色。此外，隨著 HTTP/2 的普及，正確設定相關引數也至關重要。文章也涵蓋了 http2_chunk_size、http2_body_preread_size、http2_idle_timeout、http2_max_concurrent_streams、http2_max_field_size 等 HTTP/2 指令，探討如何調整這些引數以提升效能和資源利用率。透過理解這些指令的運作機制和最佳實踐，可以有效地組態 NGINX，使其在處理各種網路請求時達到最佳效能和穩定性。

NGINX HTTP 模組指令探討

NGINX 作為一個強大的 Web 伺服器，其 HTTP 模組提供了許多強大的指令，用於控制伺服器的行為和效能。以下是一些關鍵指令的詳細解說，這些指令在實務應用中具有重要意義。

msie_refresh

段落標題

msie_refresh 是一個針對 IE 流覽器的特定指令，當 HTTP 回應碼為 301 或 302 時生效。啟用後，NGINX 會向 IE 流覽器傳送一個包含重新整理 meta 標籤的回應體，以重新導向瀏覽器到資源的新位置。

Syntax
msie_refresh on | off;
Default Value
off
實務應用

在某些情況下，當你需要確保 IE 流覽器能夠正確處理重新導向時，可以啟用這個指令。例如，如果你的網站有大量 IE 使用者，這個指令可以幫助避免重新導向失敗的問題。

內容解密：

  • 作用：針對 IE 流覽器傳送重新整理 meta 標籤，以確保重新導向成功。
  • 觀念：這是一個特定於 IE 的處理方式，因為 IE 對某些 HTTP 回應碼的處理方式與其他瀏覽器不同。
  • 邏輯：當設定為 on 時，NGINX 會在 HTTP 回應中包含額外的 meta 標籤來確保瀏覽器正確處理重新導向。
  • 設計考量：這種設計是針對特定瀏覽器的一種相容性處理，確保不同瀏覽器在處理重新導向時的一致性。
  • 潛在改進點：如果未來 IE 的市占率進一步減少，可以考慮移除這個指令以簡化組態。

resolver

段落標題

resolver 指令用於指定 DNS 伺服器，以解析主機名稱到 IP 地址。DNS 查詢結果會被快取一定時間，根據 DNS 伺服器提供的 TTL 或手動設定的時間。

Syntax
resolver <IPv4 or IPv6 address> [valid=<time value>] [ipv6=<on|off>];
Default Value
None (使用系統預設)
Examples
resolver 127.0.0.1; #使用本地 DNS
resolver 8.8.8.8 8.8.4.4 valid=1h; #使用 Google DNS 與 1 小時快取
裝置最佳化建議

建議使用本地 DNS 解析器（如 dnsmasq），並讓 NGINX 查詢這些本地解析器。這樣可以避免網路延遲和最佳化 DNS 查詢效能。此外，可以使用 dnscrypt 來保護 DNS 查詢隱私。

內容解密：

  • 作用：指定 DNS 伺服器進行主機名稱解析。
  • 觀念：DNS 解析是網路通訊中的基礎步驟之一，透過快取 DNS 查詢結果可以提高效能。
  • 邏輯：NGINX 會根據組態的 DNS 伺服器進行查詢並快取結果，減少重複查詢。
  • 設計考量：使用本地 DNS 解析器可以減少網路延遲和提高查詢效率。
  • 潛在改進點：可以根據實際需求調整快取時間和 DNS 伺服器列表。

resolver_timeout

段落標題

resolver_timeout 指令設定 hostname 應答查詢的超時時間。

Syntax
resolver_timeout <time value>;
Default Value
30 seconds

內容解密：

  • 作用：設定 DNS 查詢的超時時間。
  • 觀念：超時設定是為了防止 DNS 查詢過久而影響系統效能。
  • 邏輯：當查詢超過設定的時間仍未得到回應時，系統會放棄該查詢並進行下一步操作。
  • 設計考量：合理設定超時時間可以平衡查詢成功率和系統效能。
  • 潛在改進點：根據實際網路環境調整超時時間，以獲得最佳效能。

server_tokens

段落標題

server_tokens 指令控制 NGINX 是否向客戶端顯示版本號。NGINX 的版本號可能出現在 HTTP 回應頭、錯誤頁面等位置。

Syntax
server_tokens on | off | build;
Default Value
on
安全建議:

如果你不打算更新 NGINX 或使用較舊版本, 建議隱藏版本號以增強安全性。

內容解密：

  • 作用：控制是否向客戶端顯示 NGINX 的版本號。
  • 觀念：隱藏版本號可以增加安全性，防止攻擊者利用已知漏洞進行攻擊。
  • 邏輯：將 server_tokens 設定為 off 或 build 則不顯示完整版本號。
  • 設計考量：隱藏版本號可以減少潛在攻擊風險。
  • 潛在改進點：定期更新 NGINX 和其他相關軟體以減少漏洞風險。

underscores_in_headers

段落標題

underscores_in_headers 指令允許或禁止自定義 HTTP 標頭名稱中使用底線。

Syntax
underscores_in_headers on | off;
Default Value:
off;

專案分析:

若設定為 on, 則允許如下範例標頭: test_header: value

內容解密：

  • 作用: 控制自定義 HTTP 標頭名稱中是否允許使用底線.
  • 觀念: 在某些情況下, 自定義 HTTP 標頭可能需要包含底線, 認可該選項可提升靈活度.
  • 邏輯: 若該值設為 on, 則允許底線, 若設為 off, 則禁止.
  • 設計考量: 在某些特殊情況下, 根據安全或其他因素, 需要禁止或允許底線.
  • 潛在改進點: 在開發階段, 根據 API 規格或安全策略調整該選項.

variables_hash_max_size

段落標題

這個指令設定變數雜湊表的最大尺寸。如果您的伺服器組態總共使用到超過1,024 個變數, 則需增加該值.

Syntax:
variables_hash_max_size <number>;
Default Value:
1024;

專案分析:

變數雜湊表用於儲存所有變數及其對應值, 大小調整可影響系統效能及穩定性.

內容解密：

  • 作用:設定變數雜湊表最大尺寸.
  • 腦袋: 用於儲存所有變數及其對應值, 大小調整可影響系統效能及穩定性.
  • 腦袋:若總共使用到超過1,024 個變數, 則需要增加該值.
  • 腦袋:該引數調整需謹慎, 不合理設定可能造成資源浪費或系統不穩定.
  • 潛在改進點:若出現錯誤訊息"variable hash table size exceeds maximum", 則需相應增加該值.

variables_hash_bucket_size

段落標題

此指令設定變數雜湊表區塊大小。區塊大小影響雜湊表之空間佈局與效能。

Syntax:
variables_hash_bucket_size <number>;
Default Value:
64 (取決於處理器快取規格)

專案分析:

區塊大小影響雜湊表之空間佈局與效能, 單位為 bytes.

內容解密：

  • 作用：設定變數雜湊表區塊大小.
  • 腦袋：區塊大小影響雜湊表之空間佈局與效能.
  • 腦袋：依照處理器快取規格選擇適當區塊大小.
  • 腦袋：合理選擇區塊大小可提升雜湊表存取速度及資源利用率.
  • 潛在改進點：根據實際執行情況進行區塊大小調整.

post_action

段落標題

此指令定義了完成請求後執行之動作。當請求完成後, NGINX 呼叫指定 URI 或命名位置區塊.

Syntax:


post_action <URI> | <named location>;

Example:


location /payment/ {
    post_action /scripts/done.php;
}

專案分析:

此功能常用於執行請求完畢後之追蹤、記錄、或後處理工作。

HTTP/2 指令探討

HTTP/2 是 HTTP 的下一代協定, 提供更高效能及更好的使用者經驗。以下介紹 NGINX 中常見之 HTTP/2 指令:

http2_chunk_size

此指令設定回應內文切割成之最大區塊尺寸.

Syntax:


http2_chunk_size <size>;

Default Value:


8k;

專案分析:

適當調整切割尺寸可平衡處理效能與資源利用率.

http2_body_preread_size

此指令設定要求之主體儲存至處理前之緩衝區尺寸.

Syntax:


http2_body_preread_size <size>;

Default Value:


64k;

專案分析:

適當增加緩衝區尺寸可提升要求處理速度.

http2_idle_timeout

此指令設定閒置連結閉鎖之時間長度.

Syntax:


http2_idle_timeout <time>;

Default Value:


3m;

專案分析:

合理設定閒置時間可節省系統資源並提升穩定性.

http2_max_concurrent_streams

此指令設定單一連結中同時執行之 HTTP/2 流量最大數目.

Syntax:


http2_max_concurrent_streams <number>;

Default Value:


128;

專案分析:

適當增加流量數目可提升同時處理能力,但需要注意系統負載問題.

http2_max_field_size

此指令限制壓縮後之要求標頭最大尺寸.

Syntax:


http2_max_field_size <size>;

Default Value:


4k;

專案分析:

合理設定最大尺寸可避免惡意要求帶來負擔並保護系統穩定性.

http2_max_header_size & http2_max_requests & http2_recv_buffer_size & http2_recv_timeout…

以下剩餘指令和http2_max_header_size 指同樣結構設計, 在程式碼中展示出每一項作用與邏輯.

小段落標題：

http2_max_header_size:

Limit the maximum size of the entire request header list after decompression. Syntax: Size (default:16k) Default Value:16k;

Example & Code :

http {
   server {
       listen 443 ssl http2;

       http2_max_header_size 30k;

   }
}
Code Ananlysis :

The directive controls the maximum size of the entire request header list after decompression in an HTTP/2 connection. If the headers exceed this limit after decompression and reassembly, Nginx will terminate the connection with an error status code “HTTP_1_1_REQUIRED.” The default value is set to ensure compatibility with most clients and servers but can be adjusted as necessary based on your application’s requirements and expected traffic patterns.

Content Unlocked :
  • 作用：限制壓縮後之要求標頭列表最大尺寸。
  • 腦袋：若標頭超過限制則連結被終止以維持穩定性。
  • 腦袋：合理調整上限可防止惡意要求帶來負擔並保護系統穩定性.
  • 腦袋：該引數調整需謹慎, 不合理設定可能造成連結終止或資源浪費.
  • 潛在改進點：根據實際情況動態調整上限以適應不同負載情況.

The remaining directives (http2_max_requests & http2_recv_buffer_size & http2_recv_timeout) also have similar structures and purposes as outlined above. Each directive plays a crucial role in configuring and optimizing HTTP/2 connections in Nginx by setting appropriate limits and timeouts to ensure efficient and secure communication between clients and servers.

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。