Web應用防火牆（WAF）在安全體系中至關重要，但其效能開銷與規則靈活性之間的矛盾，長期以來是架構設計中的一個棘手權衡。本文將探討一種新的設計思路：當 WAF 不再是一個功能固化的安全元件，而是成為一個可程式設計的邊緣安全層時，我們能獲得甚麼？

我們將深入剖析 OpenResty Edge 如何透過其領域特定語言（EdgeLang）和編譯最佳化技術，將複雜的安全規則轉化為高效能的閘道器原生指令。這種方法不僅在基準測試中展現出顯著的效能優勢，更關鍵的是，它將安全策略的定義權交還給開發者，使其能與業務邏輯深度融合。本文將透過具體的技術實現、效能資料和架構理念，展示一個高效能、可程式設計的 WAF 如何從一個被動的防禦元件，演進為企業應用交付流程中的內生能力。

高效能的可程式設計 WAF

“可程式設計”的安全：EdgeLang

傳統的 WAF 往往受限於靜態的配置檔案或效能低下的指令碼，而 OpenResty Edge 引入了我們自主研發的 EdgeLang——一種專為高效能閘道器設計的領域特定語言（DSL）。不僅是配置規則，更是用一種比手寫 Lua 更加簡潔高效的語言。

• 打破邊界的擴充套件性： EdgeLang 不是一座孤島。它擁有強大的互操作性，支援直接呼叫自定義 Lua 模組和程式碼，讓你能夠複用現有的業務邏輯和指令碼。同時，EdgeLang 內建了豐富的預編譯庫和模組，涵蓋了常見的安全防護、資料處理和網路操作功能。這種設計既保證了 OpenResty Edge Node 的輕量化部署，又為開發者提供了足夠的擴充套件能力，讓你能夠透過 EdgeLang 將複雜的安全策略無縫編排進你的防線中。

• 超越手寫程式碼的效能（Compiler Magic）： 你可能認為靈活性意味著效能犧牲，但在 EdgeLang 中恰恰相反。

  • 高效程式碼生成： EdgeLang 編譯器會將你的規則編譯為最佳化的 Lua 程式碼，在閘道器伺服器上執行。透過內建的演算法最佳化和程式碼生成策略，其實際執行速度通常快於手寫的 Lua 程式碼。
  • 跨規則深度最佳化： 我們的編譯器實現了先進的全域性最佳化技術。它不會逐條執行規則，而是對所有規則進行“降維打擊”式的整合。

• 高效的匹配技術 透過以下最佳化，規則集的規模不再是效能的瓶頸：

  • 正規表示式合併 (Regex Merging): 編譯器會將所有正規表示式規則合併成一個巨大的狀態機 (DFA)。這樣一來，無論規則有多少條，系統都只需掃描一次請求資料，就能找出所有匹配的規則及其具體位置。
  • 字首字尾樹 (String Trees): 所有的常量字串字首和字尾模式會被組合成單一的、高效的樹狀資料結構，以加速查詢過程。

精細化的敏感度控制

面對 WAF 誤報這個行業普遍難題，我們提供了多級敏感度調整機制，讓運維團隊能夠根據實際業務場景靈活應對。

場景化調整策略：

• 攻防演練期：提升敏感度到嚴格模式，寧可多攔截也要確保安全
• 業務高峰期：降低敏感度到平衡模式，減少對正常使用者的影響
• 日常運營期：使用標準模式，在安全性和可用性間找到最佳平衡點

透過實時調整敏感度等級，運維團隊可以在不同業務階段快速響應，將誤報對業務的影響降到最低。這不是完美的解決方案，但確實是目前最實用的應對策略。

碾壓級的效能表現

資料不會說謊。我們模擬了最真實的攻擊場景：1 個 Worker 程序，使用 1 個 CPU 核心，載入了 208 條規則。我們測試了隨著 URI 引數數量（URI Args，x軸）增加時，系統 RPS（每秒請求數，y 軸）的表現。

• 起跑線即終點： 在最簡單的場景下（1個 URI 引數），OpenResty Edge 的吞吐量（~5300 RPS）已經是 ModSecurity Nginx 版（~1400 RPS）的 3.7 倍。
• 抗壓能力的斷層差距： 隨著請求複雜度增加（X 軸向右延伸），ModSecurity 的效能呈現指數級崩塌。當 URI 引數達到 20 個時，傳統 WAF 幾乎已經“窒息”（接近 150 RPS），伺服器資源被耗盡。
• 極限生存能力：在 100 個引數的極端高負載下，OpenResty Edge 依然保持在 1500 RPS 左右——這個數字比 ModSecurity 在最輕鬆狀態下的表現還要好。

這意味著：

使用者體驗：快，就是留存。

在同等硬體下，OpenResty Edge 的處理能力是競品幾倍到幾十倍。即便開啟全量 208 條安全規則。這意味著你無需在安全性和速度之間做妥協——使用者在享受銀行級安全防護的同時，依然擁有絲滑的載入體驗。

成本效益：可觀的單位經濟效益。

OpenResty Edge 僅需 1 個 CPU 核心 即可達到競品需要幾個甚至十幾個核心才能支撐的吞吐量。對於雲原生企業，這意味著可以大幅削減叢集規模，顯著降低 AWS/GCP/Azure 的月度賬單。用更少的核心承載更多的流量，將技術紅利直接轉化為真金白銀的利潤。

從 0 到 1 構建 WAF 防禦體系

第一步：奠定全域性安全基石

在為具體應用配置防護之前，我們建議先建立一套統一的全域性 WAF 規則。這為您的所有服務提供了一個基礎的安全水位，能高效攔截常見的、大範圍的攻擊。這是構建防禦體系的起點。

如何設定全域性 WAF 規則

第二步：為核心應用開啟專屬防護

全域性規則建立後，下一步就是為您最重要的應用開啟 WAF 功能。只有開啟後，您設定的規則（無論是全域性還是應用專屬）才會真正生效，開始守護您的應用。開啟應用的 WAF。

第三步：精準放行，避免業務干擾

在開啟 WAF 防護後，有時可能會遇到正常的業務請求被誤攔的情況。為了確保業務的連續性和穩定性，您需要設定白名單，精準地將可信的請求排除在攔截規則之外。

如何設定應用的 WAF 白名單

第四步：實現終極靈活的自定義規則

對於有複雜業務場景或高階安全需求的使用者，標準的 WAF 規則可能不夠靈活。透過使用 Edgelang 邊緣語言，您可以根據請求的任意引數（如 Header、Cookie、URL 等）編寫動態、精細的 WAF 規則，實現終極的自定義防護邏輯。

使用 Edgelang 定義 WAF 規則

透過組合運用以上指南，您可以構建一個從全域性到區域性、從通用到定製、既強大又靈活的 WAF 防禦體系。

Beyond WAF：三位一體的架構

傳統的網路安全觀念常常將 WAF (Web 應用防火牆) 視為一個獨立的邊界防禦工事。然而，在現代複雜的業務架構中，僅僅依賴一個孤立的“安檢口”已遠遠不夠。OpenResty Edge 的設計哲學正是這一思路的體現，它構建了一個集 私有 CDN、API 閘道器與 WAF 於一體的融合式平臺。將 WAF 的能力與 CDN 和 API 閘道器進行深度整合。

讓我們透過一個生動的比喻來拆解這個“三位一體”的強大之處。

第一環：CDN —— “高速公路與分流中心”

CDN (內容分發網路) 是整個架構的最外層，也是離全球使用者最近的一環。它的核心職責是“加速”與“分流”。

• 位置： 流量的第一入口，使用者訪問的起點。
• 職責：
  • 加速與快取： 它就像遍佈全球的“前置倉庫”，將圖片、CSS 等靜態資源快取起來，直接交付給使用者，無需每次都回到遙遠的“總部伺服器”（即回源），極大提升了訪問速度。
  • 流量清洗： 憑藉其龐大的頻寬資源，CDN 能夠像洩洪區一樣吸收並清洗大規模的 L3/L4 層 DDoS 攻擊，保護後方業務的可用性。
• 關係： 在這套架構中，CDN 是 WAF 的“載體”和“前置盾牌”，為精細化的安全檢測擋住了第一波巨浪。

第二環：WAF —— “機場安檢口”

當流量經過 CDN 的初步分流和加速後，便進入了 WAF (Web 應用防火牆) 的精細化安檢環節。

• 位置： 緊隨 CDN 之後，或直接內嵌於 CDN 節點之中，位於 API 閘道器之前。
• 職責：
  • 安全檢查： WAF 的任務非常純粹——檢查每一個請求是否攜帶危險品。它不關心你要去哪個登機口（訪問哪個業務），只關心你是否安全。它會嚴密排查請求中是否藏有“炸彈”（SQL 注入）、“刀具”（XSS 攻擊）或“偽造證件”（惡意 Cookie）。
• 關係： WAF 是業務安全的核心防線，確保只有合法的、無害的請求才能進入後續的業務流程。

第三環：API 閘道器 —— “登機口與排程臺”

透過了安全檢查的“旅客”（請求），最終會到達 API 閘道器，這裡是通往具體業務系統的“大門”。

• 位置： 位於 WAF 之後，是所有後端微服務的統一入口。
• 職責：
  • 身份驗證 (Auth)： “你是誰？”—— 透過 OAuth/JWT 等機制核實請求的身份。
  • 路由分發 (Route)： “你要去哪個服務？”—— 根據請求內容，將其精確導向後端的特定微服務。
  • 精細化治理 (Quota)： “你的票能進幾次 VIP 廳？”—— 對不同使用者或 API 進行精細化的流量控制和配額管理。
• 關係： API 閘道器是業務邏輯的“排程總檯”，負責請求的身份識別、路由和精細化管理。

當這三個層面不再是獨立的、串聯的系統，而是在同一個軟體內部實現時，架構優勢主要體現在以下幾個方面：

• 消除元件間的網路延遲： 在分離式架構中，流量需要在 CDN、WAF、API 閘道器等不同裝置或服務間進行多次網路跳轉，每次跳轉都會引入額外的網路 I/O 開銷和延遲。在一體化模型中，所有處理（快取、安全檢測、路由）都在同一個工作程序 (Worker Process) 的上下文中完成。這意味著資料處理無需跨越網路邊界，從而消除了這部分固有的延遲損耗，這對於延遲敏感型業務尤為關鍵。

• 簡化的技術棧與運維模型： 管理多套異構系統會帶來顯著的運維開銷，包括獨立的配置、監控、升級和故障排查。統一的技術棧意味著運維團隊只需掌握和維護一個平臺，即可覆蓋邊緣流量的全生命週期管理，從而降低了系統的整體複雜度和人力成本。

融合架構的核心在於深度整合，而非功能堆砌。它將流量處理與安全防護等能力統一在共享的資料平面上，天然最佳化了資料路徑，並極大簡化了運維模型。

從防禦工具到核心資產

透過在 OpenResty Edge 上構建您的安全體系，您獲得的不只是一個高效能的 WAF，而是一個與您的業務邏輯深度融合、可程式設計的邊緣安全層：

• 透過 EdgeLang 將安全規則編譯為原生程式碼，即使最複雜的防護邏輯也不會成為效能瓶頸，保障了核心業務的響應速度。
• 將安全、閘道器、流量管理等功能統一在可程式設計的軟體棧中，用更少的元件和更低的運維複雜度支撐更敏捷的業務。
• 擺脫靜態規則集的束縛，您可以編寫能感知業務上下文的動態安全策略，將防禦從被動響應升級為主動設計。

未來的應用競爭，不再只是“功能更豐富”，而是“交付得更快、更安全、更可靠”。OpenResty Edge 的可程式設計安全正是這個時代新的“業務保障引擎”。選擇它，也許只是一個技術棧的更新，但背後，是您將安全從“外部約束”轉變為“內生能力”的第一步。

關於 OpenResty Edge

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

關於作者

章亦春是開源 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 多個開源軟體庫。

關注我們

如果您喜歡本文，歡迎關注我們 OpenResty Inc. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

我們提供了英文版原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！