OpenResty Edge 內建了 DDoS 防護能力。它不是一個獨立的安全產品，而是平臺基礎設施的一部分，與閘道器、節點、Agent 共享同一套交付和運維體系。其核心目標是在不破壞核心完整性的前提下，將千萬級 PPS 的防護能力直接內建到生產環境中。本文將介紹這套防護體系的設計思路、多級防護機制與控制檯能力。在此之前，我們先簡要回顧它所針對的核心工程問題。

1. DDoS 防護的"不可能三角"

當 DDoS 防護從外圍補丁變成系統核心路徑的一部分，技術團隊通常面臨一個長期存在的"不可能三角"——以下三個目標難以同時達成：

1. 極限吞吐效能
2. 核心與生態相容性
3. 長期工程可維護性

現有方案往往只能滿足其中一到兩個，同時在第三個維度上付出代價。

1.1 旁路核心方案：高效能但犧牲系統完整性

為了在高 PPS 攻擊下獲得極致效能，一類方案選擇繞過核心網路棧，將防護邏輯直接推到網絡卡附近。效能問題被解決了，但代價是：

• 網路路徑被分裂為兩套體系
• 現有的監控、診斷、運維工具失效
• 防護系統本身變成一個難以觸碰的特殊元件

一次效能最佳化，換來了長期的系統複雜度和運維風險。

1.2 純核心方案：相容性好但效能天花板明顯

另一類方案將防護邏輯嚴格限制在現有核心框架內——不改變網路架構，不引入額外執行時，完全複用成熟的核心機制。這種方式工程上更易接受，但系統的處理路徑已經固定，效能上限也隨之固定。

在真正的高頻攻擊下，CPU 很快成為瓶頸，防護系統甚至可能在攻擊尚未被完全識別之前就先行失效。

1.3 混合方案：理論可行但工程複雜度難以控制

理論上最理想的狀態是防護足夠靠前、同時又不破壞系統完整性。但現實中，這條路往往意味著：

• 對作業系統版本和特性的強依賴
• 受限的程式設計模型和執行環境
• 部署、升級和回滾過程難以標準化

技術上可行，但工程上難以複製，更難以在大規模生產環境中長期維護。 系統一旦穩定執行，團隊往往對它"敬而遠之"——沒有人願意輕易觸碰一套高風險、高維護門檻的核心元件。

2. OpenResty Edge 的設計選擇：讓三個目標同時達成

我們的設計思路並非挑戰物理極限，而是選擇一個更具工程價值的技術定位：在不破壞核心完整性的前提下，最大化利用核心最前沿的資料處理能力。 針對上述不可能三角的三個維度，我們的設計原則逐一給出回應：

我們關注的核心問題從“能否更快”轉變為：能否將千萬級 PPS 的處理能力，安全、穩定地部署在生產環境中，並使其易於管理和維護。

2.1 「四級聯防」：從全域性基線到單塊網絡卡

OpenResty Edge 將防護配置劃分為四個自上而下、與真實拓撲對齊的維度，便於在大型企業環境中分責、分域管理：

• 全域性級別（Global）：設定整個 Edge 網路的預設 SYN PPS、DNS RPS 等上限與下限基線，作為所有下游實體的安全兜底；新接入的叢集若暫未單獨調參，也會繼承這一層的基礎防護。
• 叢集級別（Cluster）：按業務或地域隔離。例如可針對某一測試叢集（如 test-yuannn）按實際業務體量單獨微調防護引數，而不影響其他叢集。
• 單機節點級別（Node）：對叢集內單臺機器定向加固。若某臺伺服器效能相對薄弱或正遭受定向打擊（如節點 jenkins-slave-2），可在該層級獨立收緊或放寬策略。
• 網路介面級別（Interface）：防護可下沉到單塊網絡卡。在混合雲或容器化場景中，可對特定介面（如 Kubernetes 環境中常見的 cni0 等容器網絡卡）單獨設限，實現對某段微服務網路的隔離與保護。

2.2 配置繼承與按需覆寫

在多層級並存時，OpenResty Edge 提供 繼承（Inherit） 機制，降低重複配置與誤配風險：

• 在叢集或節點等層級，可選擇 Inherit，直接沿用上一級的防護策略，無需逐項重填。
• 當某一節點或介面需要例外處理時，再將其切換為 Enabled 或 Disabled 等模式進行覆寫，實現 「全域性統一預設、區域性按需定製」 的運維心智模型。

2.3 SYN 與 DNS Flood 的精細化引數

在介面級及相應配置面板中，可對向量做細粒度控制，例如：

• SYN Flood：除全侷限速（最大/最小 PPS）外，還可配置 每 IP 的 SYN 速率（SYN/IP/s）、每 IP 的 ACK 速率（ACK/IP/s），並可對特定埠（如 80）單獨監控與設限。
• DNS Flood：可限制整體 每秒查詢率（RPS）、每 IP 查詢率（DNS/IP/s），並支援限定生效的 域名（Domains） 與 IPv4 地址範圍，以抑制偽造源地址的放大與濫用類攻擊。
• 自動檢測模式（Auto detect attack mode）：一鍵開啟後，系統會結合實時流量模型自動判斷是否進入防護介入狀態，與下文所述的全自動攻防閉環相呼應。

3. 效能不是口號，而是工程事實

效能應是可量化、可復現的工程事實，而非市場口號。

3.1 基準效能與成本效益

在一臺低規格的雲主機（以 AWS t3.small 為例）上，不依賴任何專用硬體或特殊的系統配置，我們的系統在處理小包 UDP/TCP SYN Flood 時，實測可穩定處理 17-18萬 PPS 的流量。

這一資料表明，透過最佳化資料路徑和選擇正確的架構位置，可以在通用硬體上實現極高的效能密度，避免了透過大量例項進行水平擴充套件或採購昂貴專用硬體的傳統模式。效能提升源於架構設計，而非硬體堆砌。

3.2 防禦冗餘（Headroom）的價值

根據對線上真實攻擊的觀測，典型的攻擊流量峰值約為 30–40 Mbps。而上述配置的系統可穩定處理約 100 Mbps（對應約 18 萬 PPS 的小包流量）的攻擊。

這個差值，即“效能冗餘”至關重要。它意味著在真實攻擊發生時，系統遠未達到其處理極限，為監控、決策和策略調整預留了充足的緩衝空間，確保了系統的確定性和響應的從容。

3.3 架構的可擴充套件性

在更高規格的硬體上，系統效能可隨 CPU 核心數近似線性增長。我們的架構設計已在實驗室環境中驗證了處理千萬級 PPS 流量的能力。這意味著：

• 防護能力可以隨硬體迭代平滑升級，保護了長期投資。
• 未來即使面臨更大規模的攻擊，也無需進行顛覆性的架構重構。

4. 自動化不是“加分項”，而是 DDoS 防護的前提

DDoS 防護的有效性，不僅取決於峰值效能，更取決於響應速度和準確性。

4.1 全自動攻防轉換

系統設計目標是實現自動化防禦閉環：

• 自動檢測攻擊流量模式，觸發防禦策略。
• 在控制檯側，還可為具體層級開啟 自動檢測攻擊模式（Auto detect attack mode），由系統依據實時流量特徵自動判斷並介入。
• 攻擊結束後，自動回撤策略，恢復常規路徑。

這直接帶來了可量化的收益：顯著降低 MTTR（平均響應時間），並消除了人工干預可能引入的延遲和誤判，使安全響應成為一個確定性的系統行為。

4.2 策略決策的系統化

系統內建的流量分析引擎能夠區分不同攻擊向量（如非法域名請求、CC 攻擊等），並自動匹配最優防禦策略。其核心價值在於：將“是否攔截、如何攔截”的判斷，從依賴人類專家的應急響應，轉變為系統內建的、可重複執行的決策邏輯。

這意味著防護能力被固化為平臺能力，降低了對特定安全專家的依賴，提升了團隊整體的穩定性。

5. 可觀測性：透明是信任的基礎

任何執行在核心資料路徑上的系統，如果是一個“黑盒”，其本身就是潛在的風險源。我們的系統設計將可觀測性作為一級公民。

提供的實時遙測資料包括：

• 攻擊狀態（是/否）
• 識別的攻擊型別
• 實時/累計丟包數與透過數
• 核心側實現執行狀態與資源消耗

在 OpenResty Edge 的各層防護配置介面下方，還內嵌 Real-Time Metrics（實時指標） 面板，便於在同一檢視中對照策略與效果：可檢視當前層級的 SYN、DNS 相關流量概況，例如 每秒回覆數（Reply pps）、每秒丟棄數（Dropped pps），以及系統是否處於 未受攻擊（Not Under Attack）/ 正受攻擊（Under Attack） 等狀態，使防護效果所見即所得，避免“黑盒式”安全模組。

這些資料確保了：

• 策略可審計：所有防禦動作都有據可查。
• 故障可追溯：為問題排查提供了統一、可靠的資料基礎。
• 跨團隊協同：為安全、網路、業務團隊提供了共同的事實語言。

6. 結論：構建一個內建、自適應的防護體系

網路攻擊的規模和複雜性在持續增加。真正的架構風險，並非來自攻擊本身，而是來自為應對攻擊而引入的、與現有體系格格不入的“異構系統”，或是那些在關鍵時刻高度依賴人工介入的脆弱流程。我們非常清楚，安全系統如果引入過高的運維成本，是不會被開發和運維團隊所接受的。將上述 多級策略 以 OpenResty Edge 內建能力 交付，正是為了在單一產品邊界內同時滿足效能、相容性與可運維性，而不是再疊加一套獨立的“DDoS 盒子”或平行運維面。

• Console + Agent 模式：你可以在中心化的 Console 上配置所有策略，各個節點上的 Agent 會透過 API 自動拉取和同步，無需逐臺登入伺服器進行人肉操作。
• 漸進式接入：你可以先從非核心業務、單個節點開始試點，驗證效果後再逐步推廣到更多伺服器和業務線，整個過程平滑可控。
• 複雜網路適配：透過對網路名稱空間的支援，它能很好地在容器化（如 Docker, k8s）或多租戶虛擬化環境中，為不同的網路介面提供獨立的防護策略。

一個理想的 DDoS 防護架構，應當是：一個能夠無縫整合、自主執行、且自身足夠穩固的系統能力。部署後，技術負責人可以信任其自主執行，而不是將其列為值班表上需要高度關注的告警源。這正是我們透過此架構設計所致力於解決的核心工程問題。

關於作者

章亦春是開源 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. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

翻譯

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