← 返回

OpenResty Edge 中的 zstd 壓縮：比 gzip 和 Brotli 更快、更省

章亦春釋出於 Oct 20, 2025 更新於 Aug 4, 2026

預計閱讀 11 分鐘

閱讀次數

OpenResty Edge 現已支援 Zstandard（zstd）——由 Meta 開發的現代壓縮演算法。在官方基準測試中，zstd 的壓縮速度約為 gzip 的 5 倍（510 vs 105 MB/s），解壓速度約為 gzip 的 4 倍（1550 vs 390 MB/s），壓縮比還略高於 gzip。在 OpenResty Edge 中啟用 zstd 壓縮，可以同時降低頻寬、延遲和 CPU 成本。

gzip 服務了網際網路二十年，但面對如今的動態 API、高併發流量和邊緣分發已力不從心。本文將介紹 zstd 的不同之處、它為何契合邊緣架構，以及如何在 OpenResty Edge 中透過幾次點選啟用它。

申請試用 OpenResty Edge

壓縮演算法的代際升級

過去二十年裡，gzip 一直是網際網路傳輸的“預設標準”。從網頁 HTML 到 API 響應，從日誌流到配置檔案，它幾乎無處不在。它可靠、相容性強，但隨著網路架構和使用者體驗需求的演進，我們不得不承認：gzip 的時代，正在慢慢老去。

網路傳輸的“隱形瓶頸”

當使用者在全球範圍內訪問內容時，頁面載入速度的每一毫秒都至關重要。即使快取與 CDN 層不斷最佳化，資料體積依然是最直接影響傳輸效率的因素。

對終端使用者而言：體積越小，載入越快，能耗越低；
對平臺運營者而言：壓縮率越高，頻寬成本越低，邊緣節點的吞吐量也越高。

gzip 在過去的成功恰恰來源於“平衡”：足夠好的壓縮比+速度尚可的計算開銷。但這種平衡在今天卻成了限制。現代應用場景的負載已完全不同：

動態響應比例上升（API、GraphQL、實時日誌流），意味著需要頻繁壓縮短生命週期的資料；
移動端與 IoT 裝置激增，網路波動更大，對傳輸效率和解壓效能要求更高；
資料格式多樣化（JSON、Protobuf、Parquet…），gzip 對部分格式的壓縮效率並不理想。

這就導致在高併發或邊緣計算場景下，gzip 緩慢的壓縮和解壓速度帶來了高昂的 CPU 開銷和延遲，使其“平衡”不再。這些變化讓我們重新審視壓縮演算法的角色：它不再只是“節省頻寬的工具”，而是效能最佳化鏈路中直接影響延遲與使用者體驗的關鍵環節。

當壓縮演算法成為效能瓶頸

在高併發場景中，例如 CDN 邊緣實時壓縮響應，gzip 的 CPU 佔用可能成為隱藏的成本。從下面的基準測試結果可以清晰看到 zstd 顯著快於 Brotli 和 gzip。

在同樣的延遲預算下：

gzip 可能只能壓縮 level = 3 的資料；
新一代演算法 Zstandard 能在相同 CPU 開銷下壓縮得更小、更快。

這意味著在相同的硬體資源下，系統可以：處理更多請求；降低流量成本；減少平均響應延遲。對企業而言，這是非常直接的經濟收益。

邊緣計算場景的獨特挑戰

在邊緣計算場景下，每個節點都在儘可能靠近使用者處理流量：頻寬資源有限；CPU 分配緊張；節點數量龐大。在這樣的環境裡，每 1% 的壓縮效能最佳化都可能放大成顯著的整體收益。這正是為甚麼越來越多的雲廠商和基礎設施平臺開始引入 Zstandard（zstd） —— 一種為現代計算架構而生的高效能壓縮演算法。它不僅在壓縮比和速度上找到新的平衡點，更重要的是：讓“壓縮”重新成為效能最佳化的主動槓桿，而不是不得不承受的代價。

甚麼是 Zstandard（zstd）

Zstandard，簡稱 zstd，是一種由 Meta（原 Facebook）研發的通用無失真壓縮演算法。它的設計目標非常直接——在保持高壓縮率的同時，顯著提升壓縮和解壓的速度。在演算法層面，zstd 並不是在 gzip 或 brotli 的基礎上小修小補，而是重新思考了“壓縮效能三角”——壓縮比、速度、資源消耗之間的關係。

zstd 面向現代硬體與資料的設計

傳統的 gzip 在 90 年代被設計時，更多考慮的是單執行緒 CPU、磁碟 IO 較慢、記憶體有限的環境。而 zstd 則面向的是一個完全不同的時代：

多核 CPU 與 SIMD 指令整合為常態；
資料格式高度結構化（JSON、Avro、Protobuf）；
網路 IO 成為效能瓶頸。

在這樣的背景下，zstd 的核心最佳化目標是：讓壓縮成為“實時可用”的操作，而不是後臺任務。它的壓縮模式支援從 level 1 到 22 的細粒度調節，

低階別適合實時流量（如 API 響應壓縮）；
高階別則能用於歸檔或日誌儲存（壓縮比可超過 brotli）。

這讓 zstd 既能成為“高效能傳輸”的工具，也能成為“高密度儲存”的利器。

zstd 的關鍵技術特性

特性	說明
高壓縮比	在多數測試場景下，壓縮率比 gzip 高 10~20%，同時解壓速度更快。
極快的解壓效能	zstd 的解壓速率遠高於 brotli，適合高併發線上服務。
可調壓縮等級（1-22）	靈活控制 CPU 與壓縮比的平衡，適應不同業務負載。
多執行緒最佳化	原生支援多核壓縮，邊緣計算環境可充分利用並行資源。
字典模式（dictionary mode）	針對結構相似的小資料（如 API payload）可獲得額外 2~5× 壓縮提升。

這些特性讓它在“傳輸效率”與“計算開銷”之間，找到一個過去難以兼得的平衡點。

為甚麼 zstd 特別適合在 OpenResty Edge 中使用

Zstandard 並不是一次簡單的演算法升級，而是一次真正契合邊緣架構特性的效能演進。在邊緣計算環境中，系統要同時面對三種壓力：高併發請求、受限的計算資源，以及對延遲的極端敏感。傳統的 gzip 在這種場景下往往難以同時兼顧壓縮率與速度——壓得小就變慢，壓得快又浪費頻寬。

Zstandard 的出現，正好打破了這種“效能取捨”。它在低壓縮等級時速度比 gzip 更快，在中高等級下仍能保持較優的壓縮比和解壓效能，適合在邊緣節點上根據實時負載自適應地平衡延遲與資源利用率。更重要的是，Zstandard 對動態內容有天然優勢。它能以流式方式壓縮 API 響應或日誌資料，在毫秒級延遲預算內完成壓縮，而無需快取整塊資料再處理。在私有 CDN 場景下配合 OpenResty Edge 的回源頻寬最佳化，這種效率提升往往能在系統層面帶來可見的效能改善。

這意味著，當你在 OpenResty Edge 中啟用 zstd 壓縮時：

使用者看到的響應更快
頻寬利用率更高
CPU 成本反而更低

在效能工程領域，這種“三贏”的最佳化非常罕見。如果說 gzip 解決了“能不能壓縮”的問題，那麼 zstd 解決的，是“壓縮還能多快、多聰明”的問題。

如何在 OpenResty Edge 中啟用 Zstandard 壓縮

在 OpenResty Edge 中，zstd 壓縮被設計為一個全層級可配置的特性——你可以在全域性啟用它，也可以針對特定應用或路徑進行精準控制。

多層級配置架構：靈活與可控的平衡

OpenResty Edge 的配置體系支援在不同層級定義壓縮策略。系統會根據優先順序自動應用最高層級的配置，確保靈活與一致性兼得。配置層級從高到低如下：

頁面規則配置

位置：應用 > HTTP 應用 > 具體應用 > 頁面規則 > 動作 > 啟用閘道器 Zstandard / 設定 Zstandard 型別

最精細的控制方式，可針對特定 URL 路徑或條件啟用 zstd 壓縮。適合對效能敏感的介面或高流量資源進行個性化調優。

全域性自定義動作配置

位置：全域性配置 > 全域性自定義動作 > 動作 > 啟用閘道器 Zstandard / 設定 Zstandard 型別

可建立可複用的 zstd 壓縮動作，在多個應用中統一呼叫。對多團隊協作和規模化運維尤為友好。

應用設定配置

位置：應用 > HTTP 應用 > 具體應用 > 設定 > Zstandard

針對單個 HTTP 應用定義壓縮策略，快速啟用或調整 zstd 壓縮。適合應用級效能調優與灰度實驗場景。

全域性改寫規則配置

位置：全域性配置 > 全域性改寫規則 > 動作 > 啟用閘道器 Zstandard / 設定 Zstandard 型別

用於為特定條件（如請求頭、路徑模式）定義系統級壓縮邏輯。可在多環境統一執行壓縮策略。

全域性通用配置

位置：全域性配置 > 通用配置 > Zstandard 配置

提供系統的基礎壓縮引數。可在此對核心 MIME 型別（如 HTML、CSS、JSON、JS）統一啟用 zstd 壓縮，為所有上層配置提供穩定的基線。

當多個層級的 zstd 壓縮規則同時存在時，OpenResty Edge 會自動採用最高優先順序配置，以避免策略衝突。全域性通用配置作為基礎層，在此啟用後，即使應用層沒有特定定義，也能獲得統一的壓縮基線。

與其他壓縮演算法的協同關係

OpenResty Edge 平臺支援同時啟用多種壓縮演算法（gzip、brotli、zstd），系統會根據客戶端支援自動選擇最優演算法：

優先順序：Zstandard > Brotli > Gzip

這意味著，當客戶端例如 Chrome 或 curl 宣告支援 zstd 時，OpenResty Edge 將自動採用 zstd 壓縮返回內容，確保最低延遲與最高壓縮比。未支援 zstd 的客戶端則會自動回退至 brotli 或 gzip，無需額外配置。

zstd、Brotli 與 gzip：應該怎麼選？

簡短的答案是：三個都啟用，讓閘道器自動選擇。在上文的 zstd 官方基準測試（level 1）中，zstd 的壓縮速度約為 510 MB/s，而 Brotli 為 290 MB/s、gzip 為 105 MB/s；zstd 的解壓速度約為 1550 MB/s，而 Brotli 和 gzip 分別為 425 和 390 MB/s——同時壓縮比還略優（2.896 vs 2.883 vs 2.743）。在更高的壓縮等級下，zstd 的壓縮比甚至可以超過 Brotli；不過對實時邊緣流量而言，低等級通常才是正確的取捨。

真正的問題不在於哪個演算法贏得基準測試，而在於每個客戶端支援甚麼。Chrome、curl 等現代客戶端已宣告支援 zstd，較舊的客戶端可能只支援 Brotli 或 gzip。因此 OpenResty Edge 支援同時啟用 gzip、Brotli 和 zstd，並按 Zstandard > Brotli > Gzip 的優先順序逐請求協商，對不支援 zstd 的客戶端自動回退。每個客戶端都能得到它所能接受的最快演算法，無需配置分支，也不會遺漏任何客戶端。

總結：效能最佳化的下一步

在網際網路效能最佳化的歷史裡，壓縮演算法往往被視作底層細節——它靜靜存在於傳輸鏈路的末端，鮮少被提及。但事實是：壓縮效率就是傳輸效率。每一個位元組、每一毫秒的節省，都會在成千上萬次請求中被放大成顯著的使用者體驗差異和運營成本差異。Zstandard 的出現，不僅僅是一次演算法效能的躍遷。它代表了一種新的最佳化哲學：效能提升不一定來自“更多資源”，而可以來自“更聰明的處理方式”。

透過在 OpenResty Edge 中啟用 zstd 壓縮，你獲得的不只是一個更高效的編碼演算法，而是一整條更流暢、更輕盈的內容分發鏈路：

更快的響應時間 —— 縮短首包傳輸延遲，讓動態內容更及時抵達；
更低的頻寬成本 —— 在全球節點中實現更高壓縮比，最佳化整體傳輸負載；
更智慧的架構選擇 —— 自適應演算法與瀏覽器協商機制，讓不同終端都能獲得最佳體驗。

未來的效能競爭，不再只是“算得快”，而是“傳得更快、成本更低、體驗更穩”。Zstandard 正是這個時代新的“傳輸加速引擎”。在 OpenResty Edge 啟用它，也許只是幾行配置的改動，但背後，是你將效能最佳化從“被動提升”轉向“主動設計”的第一步。

常見問題（FAQ）

問：zstd 比 Brotli 更好嗎？ 答：對實時流量而言，通常是的。在官方 level 1 基準測試中，zstd 壓縮速度為 510 MB/s（Brotli 為 290 MB/s），解壓速度為 1550 MB/s（Brotli 為 425 MB/s），壓縮比還略優（2.896 vs 2.883）。在更高等級下，zstd 的壓縮比也可以超過 Brotli。對於不支援 zstd 的客戶端，Brotli 仍是可靠的回退選擇。

問：哪些客戶端支援 zstd 壓縮？ 答：Chrome、curl 等現代客戶端會在請求中宣告支援 zstd。OpenResty Edge 會逐請求檢測，只對宣告支援的客戶端返回 zstd 壓縮的響應，因此啟用時無需擔心相容性問題。

問：OpenResty Edge 預設啟用 zstd 壓縮嗎？ 答：不是，zstd 壓縮預設處於關閉狀態。你可以在全域性通用配置中對 HTML、CSS、JSON、JS 等核心 MIME 型別統一啟用，也可以按應用、按 URL 路徑（頁面規則），或透過全域性自定義動作和全域性改寫規則配置——最高優先順序的配置生效。

問：客戶端不支援 zstd 時會怎樣？ 答：OpenResty Edge 會自動回退。在同時啟用多種演算法時，系統按 Zstandard > Brotli > Gzip 的優先順序逐請求協商，不支援 zstd 的客戶端會收到 Brotli 或 gzip 壓縮的響應，無需額外配置。

問：應該使用甚麼 zstd 壓縮等級？ 答：zstd 提供 22 個壓縮等級。低等級適合 API 響應等實時流量，速度優先；高等級適合歸檔或日誌儲存，壓縮比可以超過 Brotli。

關於 OpenResty Edge

OpenResty Edge 是一款專為微服務和分散式流量架構設計的全能型閘道器軟體，由我們自主研發。它集流量管理、私有 CDN 構建、API 閘道器、安全防護等功能於一體，幫助您輕鬆構建、管理和保護現代應用程式。OpenResty Edge 擁有業界領先的效能和可擴充套件性，能夠滿足高併發、高負載場景下的苛刻需求。它支援排程 K8s 等容器應用流量，並可管理海量域名，輕鬆滿足大型網站和複雜應用的需求。

申請試用 OpenResty Edge

如果你喜歡這個教程，請訂閱這個部落格網站和我們的 B 站頻道。謝謝！

關於作者

章亦春是開源 OpenResty^® 專案創始人兼 OpenResty Inc. 公司 CEO 和創始人。

章亦春（Github ID: agentzh），生於中國江蘇，現定居美國灣區。他是中國早期開源技術和文化的倡導者和領軍人物，曾供職於多家國際知名的高科技企業，如 Cloudflare、雅虎、阿里巴巴, 是 “邊緣計算“、”動態追蹤 “和 “機器程式設計 “的先驅，擁有超過 22 年的程式設計及 16 年的開源經驗。作為擁有超過 4000 萬全球域名使用者的開源專案的領導者。他基於其 OpenResty^® 開源專案打造的高科技企業 OpenResty Inc. 位於美國矽谷中心。其主打的兩個產品 OpenResty XRay（利用動態追蹤技術的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最適合微服務和分散式流量的全能型閘道器軟體），廣受全球眾多上市及大型企業青睞。在 OpenResty 以外，章亦春為多個開源專案貢獻了累計超過百萬行程式碼，其中包括，Linux 核心、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，並編寫過 60 多個開源軟體庫。