訂閱以接收新文章的通知:

500 Tbps 容量:16 年來持續擴展我們的全球網路

2026-04-10

閱讀時間:6 分鐘
本貼文還提供以下語言版本:English简体中文

Cloudflare 全球網路與骨幹 2026 年現況。

Cloudflare 的網路近期達成重要里程碑:我們的外部總容量正式突破 500 Tbps。

我們所說的 500 Tbps,是指佈建的總共外部互連容量:也就是在超過 330 座城市中,所有面向傳輸提供者、私人對等互連夥伴、網際網路交換中心或 Cloudflare Network Interconnect (CNI) 連接埠的容量總和。這不是尖峰流量。在一般日子裡,我們的尖峰使用率只佔其中的一小部分(其餘容量則是我們的 DDoS 防禦預算)。

這與我們剛起步時相比,已是天壤之別。2010 年,我們從加州帕羅奧圖一家美甲沙龍樓上的小辦公室起家,只有一家傳輸提供者,以及一個只要變更兩組名稱伺服器就能設定的反向代理伺服器。

傳輸與對等互連的早期歲月

我們的第一家傳輸提供者是 nLayer Communications,也就是現在多數人所熟知的 GTT。nLayer 給了我們最初的容量,也讓我們首次親身經歷了對等互連關係,以及在成本與效能之間取得平衡的經營學問。

從那裡開始,我們一座城市接著一座城市地擴張:芝加哥、阿什本、聖荷西、阿姆斯特丹、東京。每建立一個新的資料中心,就意味著要協商代管合約、佈放光纖、上架伺服器,並透過網際網路交換中心建立對等互連。網際網路當然不是一朵雲,而是一間間佈滿線纜的具體機房;我們花了多年時間,才掌握其中每一間的細節。

並非每個城市的部署都一帆風順,我們曾遭遇硬體缺貨、海關罷工,甚至還要用牙線來應急。在 2018 年的某一個月,我們在 24 天內於 31 個城市上線:從加德滿都巴格達雷克雅維克基希訥烏。當我們在澳門開設第 127 個資料中心時,我們保護著 700 萬筆網際網路內容。時至今日,我們的資料中心遍佈 330 多座城市,保護了超過 20% 的網站。

當網路成為安全層

隨著我們的版圖擴張,客戶的要求不再只是網站快取。他們需要保護員工、取代老舊的多通訊協定標籤交換 (MPLS) 線路,並保護整個企業網路。我們沒有選擇傳統的硬體設備,而是建立了系統來建立通往私人子網路的安全通路,並透過 BGP 直接從我們的全球網路通告企業的 IP 空間。

與此同時,威脅的規模也同步成長。2025 年,我們成功緩解了一次 31.4 Tbps 的 DDoS 攻擊,整個過程只持續了 35 秒。攻擊來源是 Aisuru-Kimwolf 殭屍網路,其中包含許多遭到感染的 Android 電視。這僅是我們當天封鎖的 5000 多次攻擊之一,而且沒有任何工程師被呼叫值班。

BLOG-3267 2

十年前,要抵擋這種規模的攻擊,需要動用國家級資源。如今,我們的網路可以在幾秒內自動處理完畢,完全不需要人為介入。這就是 500 Tbps 規模營運的要求:將防禦智慧部署到網路中的每一台伺服器,讓網路能夠自我防衛

我們的網路如何應對攻擊

以下是網路遭受攻擊時實際發生的情況。封包到達網路介面卡 (NIC) 後,會立即進入由 xdpd 管理的快速資料路徑 (XDP) 程式鏈,該程式鏈以驅動程式模式運作。這個程式鏈中的第一個程式是 l4drop,它會根據擴展柏克萊封包篩選(extended Berkeley Packet Filter,eBPF)中的緩解規則評估每個資料包。這些規則由 dosd 產生,dosd 是我們的阻斷服務精靈,在我們叢集中的每台伺服器上執行。每個 dosd 執行個體都會對傳入流量進行採樣,建立一個記錄最高流量者的表格,並將該表格廣播到機房中的所有其他執行個體。最終形成一個共用的全機房流量檢視,由於每台伺服器都基於相同的資料,因此它們會做出相同的緩解決策。

BLOG-3267 3

dosd 偵測到攻擊模式時,產生的規則會透過 l4drop 在本地端套用,並經由我們的分散式鍵值 (KV) 儲存系統 Quicksilver 在幾秒內傳播到全球,觸及每個資料中心的每一台伺服器。封包只有在通過 l4drop 的檢查之後,才會到達我們的第四層負載平衡器 Unimog,由它將流量分配給資料中心內運作正常的伺服器。對於透過我們的邊緣路由企業網路流量的 Magic Transit 客戶,flowtrackd 還會再增加一層具狀態的 TCP 檢查,追蹤連線狀態,並丟棄不屬於合法流量的封包。

我們所緩解的那次 31.4 Tbps 攻擊,正是完全遵循上述流程。沒有將任何流量回傳到集中式的清除中心,也沒有任何人為介入。目標資料中心裡的每一台伺服器都獨立辨識出攻擊,並開始以線速丟棄惡意封包——而這一切,都發生在這些封包耗用任何應用程式處理的 CPU 週期之前。軟體只是成功的一半:如果沒有足夠的連接埠容量來吸收這些流量,一切就無法運作。

分散式開發人員平台

在每一台伺服器上執行程式碼,是我們掌控完整堆疊的自然結果。既然我們已經在每台機器上執行 eBPF 程式來丟棄攻擊流量,當然也能在同樣的環境中執行客戶的應用程式碼。這一洞見催生了 Workers,以及之後的 KVDurable Objects

我們的開發人員平台在我們營運的每座城市執行,而不是只集中在少數幾個雲端區域。2025 年,我們在 Workers 中加入了 Containers 功能,讓更吃重的工作負載也能在邊緣執行。V8 隔離區和自訂的檔案系統層能將冷啟動時間降到最低。您的程式碼就在您的使用者所在之處執行,而且是在同一批透過 l4drop 以線速丟棄攻擊流量的伺服器上執行。攻擊流量在抵達網路堆疊之前就被丟棄了,您的應用程式根本不會看到它們。

前瞻性通訊協定:IPv6、RPKI、ASPA

我們很早就採用了 IPv6 和資源公開金鑰基礎架構 (RPKI)。BGP 劫持會導致實際的服務中斷和安全事件。RPKI 讓我們能夠捨棄來自對等夥伴的無效路由,確保流量前往正確的目的地。我們會為自己的 IP 首碼簽署路徑來源授權 (ROA),並在入口端執行路徑來源驗證。我們會拒絕 RPKI 無效的路由,即使這偶爾會導致我們無法連線到那些 ROA 設定錯誤的網路。

接下來是自發系統提供者授權 (ASPA)。RPKI 驗證的是誰擁有某個首碼,而 ASPA 驗證的是該首碼抵達這裡所經過的路徑。RPKI 就像抵達目的地時的護照查驗,確認擁有者正確無誤;ASPA 則像是檢查航班艙單:它會驗證流量所經過的每一個網路。路由洩漏就像一個在錯誤城市登機的乘客;RPKI 無法察覺,但 ASPA 可以。

目前 ASPA 在生態系統中的採用程度,看起來就像 2015 年時的 RPKI。我們是最早大規模部署 RPKI 的網路之一;如今,全球路由表中有 867000 個首碼具備有效的 RPKI 憑證,而十年前這個數字幾乎是零。以我們的規模,我們所選擇的通訊協定會對整個網際網路產生實際的影響。我們及早推動採用,是因為等待意味著在此期間會發生更多的劫持和洩漏事件。

AI 智慧體與不斷演進的網際網路

AI 改變了「在網路上存在」的意義。在網際網路歷史的大部分時間裡,流量是由人類透過瀏覽器點擊連結產生的。如今,AI 爬蟲、模型訓練管道和自主智慧體的流量,已佔我們網路所有 HTML 請求的 4% 以上,這個量級已與 Googlebot 本身相當。僅在 2025 年,「使用者動作」驅動的爬取(即 AI 因人類提問而造訪頁面)就增長了超過 15 倍。

AI 爬蟲在基礎架構層面的行為與瀏覽器不同。瀏覽器載入頁面後就會停止,而爬蟲則會以最大輸送量擷取所有連結資源,且請求之間沒有間歇。在我們的規模下,區分合法的 AI 爬取與實際攻擊是一個真實的工程難題。我們的偵測系統結合了經驗證機器人 IP 範圍、TLS 指紋辨識、行為分析以及 robots.txt 遵循訊號來進行區分,並為網站擁有者提供所需的資料,讓他們決定允許哪些爬蟲。

舉例來說,在 TLS 層面,合法的瀏覽器會呈現一個 ClientHello,其中包含一組與其宣稱的 User-Agent 相符的密碼套件、擴充功能和順序。一個假冒該 User-Agent 但使用精簡版 TLS 函式庫的爬蟲,則會呈現不同的指紋;這種不一致性,就是我們的系統用來在請求抵達來源伺服器之前對其進行分類的訊號之一。

協助我們打造下一個 500 Tbps

從帕羅奧圖一家美甲沙龍樓上的小辦公室起家,如今我們已擁有橫跨 125 多個國家/地區 330 多座城市、總容量達 500 Tbps 的網路,而且每一台伺服器都執行著我們的開發人員平台與安全服務,而不只是快取功能。這是十六年來持續累積的架構決策成果,我們要感謝超過 13,000 個與我們對等互連的網路與合作夥伴。我們還沒有停下腳步。

如果您是一名網路營運商,歡迎與我們對等互連。我們的對等互連政策和互連細節都公佈在 PeeringDB 上。如果您有興趣將 Cloudflare 的基礎架構直接嵌入您的網路內部,請透過 [email protected] 與我們的團隊聯絡,加入邊緣合作夥伴計畫 (Edge Partner Program)。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
網路服務Cloudflare NetworkPeeringDDoSBGPRPKIWorkers AICloudflare WorkersAI

在 X 上進行關注

Tanner Ryan|@TheTannerRyan
Cloudflare|@cloudflare

相關貼文

2026年4月22日

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen

Panics in Rust Workers were historically fatal, poisoning the entire instance. By collaborating upstream on the wasm‑bindgen project, Rust Workers now support resilient critical error recovery, including panic unwinding using WebAssembly Exception Handling....

2026年4月20日

The AI engineering stack we built internally — on the platform we ship

We built our internal AI engineering stack on the same products we ship. That means 20 million requests routed through AI Gateway, 241 billion tokens processed, and inference running on Workers AI, serving more than 3,683 internal users. Here's how we did it. ...