
對於這些測試,我們測試了三種零信任場景:安全 Web 網關 (SWG)、零信任網路存取 (ZTNA) 和遠程瀏覽器隔離 (RBI)。我們針對三個競爭對手進行了測試:Zscaler、Netskope 和 Palo Alto Networks。我們在全球 12 個地區測試了這些場景,而之前測試的地區只有 4 個。結果表明,在 42% 的測試場景中,Cloudflare 是最快的安全 Web 網關,是所有提供商中最多的。對於 ZTNA,Cloudflare 比 Zscaler 快 46%,比 Netskope 快 56%,比 Palo Alto 快 10%,對於 RBI 場景比 Zscaler 快 64%。
在本文中,我們將回顧性能為何如此重要,深入探討如何在每種場景下提高速度,並討論如何衡量每種產品的性能。
性能是一個威脅向量
零信任的表現很重要;當零信任表現不佳時,用戶會禁用它,從而使組織面臨風險。當服務變得明顯阻礙用戶完成工作時,零信任服務應該不引人注目。
零信任服務可能有很多有助於保護客戶的花哨的功能,但如果員工無法使用這些服務快速有效地完成工作,那麼這些都無關緊要。快速的性能有助於推動採用,並使安全性對最終用戶來說是透明的。在 Cloudflare,我們優先考慮讓我們的產品快速、順暢,結果不言而喻。現在讓我們來看看結果,從我們的安全 Web 網關開始。
Cloudflare Gateway:互聯網安全
安全的 Web 網關必須速度快,因為它充當組織所有 Internet 流量的渠道。如果安全 Web 網關很慢,那麼從用戶到 Internet 的任何流量都會很慢。如果互聯網流量緩慢,用戶可能會看到網頁加載緩慢、視頻通話出現抖動或丟失,或者通常無法完成工作。用戶可能決定關閉網關,從而使組織面臨遭受攻擊的風險。
除了靠近用戶之外,高性能的 Web 網關還需要與互聯網的其他部分保持良好的對等關係,以避免用戶想要訪問的網站路徑緩慢。許多網站使用 CDN 來加速其內容並提供更好的體驗。這些 CDN 通常是對等良好的,並且嵌入在最後一英里網路中。但通過安全 Web 網關的流量遵循轉發代理路徑:用戶連接到代理,代理連接到用戶嘗試存取的網站。如果該代理不像目標網站那樣具有良好的對等性,則用戶流量可能會比僅訪問網站本身所需的距離更遠,從而創建一個髮夾,如圖所示如下圖:

連接良好的代理可確保用戶流量傳輸的距離較短,從而盡可能快。
為了比較安全 Web 網關產品,我們將 Cloudflare Gateway 和 WARP 客戶端與 Zscaler、Netskope 和 Palo Alto 進行比較,這些產品都具有執行相同功能的產品。Cloudflare 用戶受益於 Gateway,Cloudflare 的網絡深入嵌入到靠近用戶的最後一英里網絡,與超過 12,000 個網絡建立對等關係。這種增強的連接性表明,因為 Cloudflare Gateway 在 42% 的測試場景中是最快的網路:

每個提供商在第 95 個百分點的 HTTP 響應時間中最快的測試場景數量(越高越好) | |
---|---|
提供者 | 該提供商速度最快的場景 |
雲耀 | 48 |
Z縮放器 | 14 |
內斯科普 | 10 |
帕洛阿爾托網絡 | 42 |
該數據表明,我們比任何競爭對手都能更快地從更多地點訪問更多網站。為了衡量這一點,我們查看第 95 個百分位數的 HTTP 響應時間:用戶通過代理、讓代理向 Internet 上的網站發出請求、最後返迴響應需要多長時間。這種測量很重要,因為它準確地表示了用戶所看到的內容。當我們查看所有測試的第 95 個百分位時,我們發現 Cloudflare 比 Palo Alto Networks 快 2.5%,比 Zscaler 快 13%,比 Netskope 快 6.5%。
所有測試中第 95 個百分位數的 HTTP 響應 | |
---|---|
提供者 | 第 95 個百分位響應(毫秒) |
雲耀 | 515 |
Z縮放器 | 第595章 |
內斯科普 | 550 |
帕洛阿爾托網路 | 第529章 |
Cloudflare 在此勝出,因為 Cloudflare 卓越的對等互連使我們能夠在其他人無法成功的地方取得成功。我們能夠在全球難以到達的地方獲得本地關注,這給我們帶來了優勢。例如,看看 Cloudflare 與澳大利亞其他提供商的表現如何,我們比第二快的提供商快 30%:

Cloudflare 在世界各國建立了良好的對等關係:在澳大利亞,我們與澳大利亞所有主要互聯網提供商進行本地對等,因此我們能夠為世界各地的許多用戶提供快速的體驗。在全球範圍內,我們與超過 12,000 個網絡建立對等網路,盡可能貼近最終用戶,以縮短請求在公共互聯網上花費的時間。這項工作之前使我們能夠快速向用戶交付內容,但在零信任世界中,它縮短了用戶存取其 SWG 的路徑,這意味著他們可以快速獲得所需的服務。
以前,當我們執行這些測試時,我們僅測試了單個 Azure 區域到五個網站。Catchpoint 等現有測試框架不適合此任務,因為性能測試要求您在測試端點上運行 SWG 客戶端。我們還需要確保所有測試都在相同位置的類似機器上運行,以盡可能地測量性能。這使我們能夠測量來自兩個測試環境運行的同一位置的端到端響應。
在本輪評估的測試配置中,我們將四台虛擬機並排放置在12 個雲區域中:一台運行連接到網關的Cloudflare WARP,一台運行ZIA,一台運行Netskope,一台運行Palo Alto Networks 。這些虛擬機每五分鐘向下面提到的 11 個不同網站發出請求,並記錄 HTTP 瀏覽器計時以了解每個請求花費的時間。基於此,我們能夠獲得面向用戶的有意義的性能視圖。以下是我們測試的位置、我們測試的網站以及哪個提供商更快的完整矩陣:
端點 | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
SWG 區域 | 購物 | 沃爾瑪 | 禪台 | 立即服務 | 蔚藍網站 | 鬆弛 | 飛漲 | 盒子 | M365 | GitHub | 位桶 |
美國東部 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | |||
美國西部 | 帕洛阿爾托網絡 | 帕洛阿爾托網絡 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | |||
美國中南部 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | |||
巴西南部 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | Z縮放器 | Z縮放器 | Z縮放器 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 |
英國南部 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 |
印度中部 | 雲耀 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 雲耀 | 雲耀 | 雲耀 | |||
東南亞 | 雲耀 | 雲耀 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 雲耀 | 雲耀 | |||
加拿大中部 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 雲耀 | 雲耀 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | Z縮放器 | 雲耀 | Z縮放器 |
瑞士北部 | 內斯科普 | Z縮放器 | Z縮放器 | 雲耀 | 內斯科普 | 內斯科普 | 內斯科普 | 內斯科普 | 雲耀 | 雲耀 | 內斯科普 |
澳大利亞東部 | 雲耀 | 雲耀 | 內斯科普 | 雲耀 | 雲耀 | 雲耀 | 雲耀 | 雲耀 | |||
阿聯酋 迪拜 | Z縮放器 | Z縮放器 | 雲耀 | 雲耀 | Z縮放器 | 內斯科普 | 帕洛阿爾托網路 | Z縮放器 | Z縮放器 | 內斯科普 | 內斯科普 |
南非北部 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | Z縮放器 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | 帕洛阿爾托網路 | Z縮放器 | 帕洛阿爾托網路 | 帕洛阿爾托網路 |
空白單元格表示對該特定網站的測試未報告準確的結果或在超過 50% 的測試期間經歷了失敗。根據這些數據,Cloudflare 通常更快,但我們的速度沒有我們希望的那麼快。我們仍然有一些領域需要改進,特別是在南非、阿聯酋和巴西。到 9 月的生日週,我們希望成為每個地區的所有網站中最快的網站,這將使我們的數字從 54% 的測試中最快增加到 79% 的測試中最快。
總而言之,Cloudflare 的 Gateway 仍然是互聯網上最快的 SWG。但零信任不僅僅與 SWG 有關。我們來談談 Cloudflare 在零信任網路存取場景中的表現如何。
即時(零信任)訪問
存取控制需要對用戶來說是無縫且透明的:對零信任解決方案的最好讚美是讓員工幾乎不會注意到它的存在。Cloudflare Access 等服務可保護公共互聯網上的應用程序,允許基於角色的身份驗證訪問,而不是依賴 VPN 等方式來限制和保護應用程序。這種形式的訪問管理更安全,但通過高性能的 ZTNA 服務,它甚至可以更快。
Cloudflare 在這一領域的表現優於我們的競爭對手,比 Zscaler 快 46%,比 Netskope 快 56%,比 Palo Alto Networks 快 10%:

零信任網路訪問 P95 HTTP 響應時間 | |
---|---|
提供者 | P95 HTTP 響應(毫秒) |
雲耀 | 第1252章 |
Z縮放器 | 2388 |
內斯科普 | 2974 |
帕洛阿爾托網路 | 第1471章 |
對於此測試,我們創建了託管在 12 個不同位置的三個不同雲中的應用程式:AWS、GCP 和 Azure。然而,應該指出的是,Palo Alto Networks 是個例外,因為由於設置測試的後勤挑戰,我們只能使用來自兩個地區的一個雲中託管的應用程式來測量它們:美國東部和新加坡。
對於每個應用程式,我們從 Catchpoint 建立了測試,從全球 400 個位置訪問該應用程式。每個 Catchpoint 節點都嘗試執行兩個操作:
- 新會話:登錄應用程式並接收身份驗證令牌
- 現有會話:刷新頁面並通過之前獲得的憑據登錄
我們喜歡單獨衡量這些場景,因為當我們查看第 95 個百分位數值時,如果我們將新會話和現有會話組合在一起,我們幾乎總是會查看新會話。但為了完整起見,我們還將顯示新會話和現有會話組合的第 95 個百分位延遲。
Cloudflare 在美國東部和新加坡的速度更快,但讓我們重點關注幾個需要深入研究的區域。讓我們看一下一個資源在競爭對手之間高度平等地相互關聯的地區:美國東部,特別是弗吉尼亞州阿什本。
在弗吉尼亞州阿什本,Cloudflare 輕鬆擊敗 Zscaler 和 Netskope,獲得 ZTNA 第 95 個百分點的 HTTP 響應:
弗吉尼亞州阿什本託管的應用程序的 95% HTTP 響應時間(毫秒) | |||
---|---|---|---|
AWS 美國東部 | 總計(毫秒) | 新會話(毫秒) | 現有會話(毫秒) |
雲耀 | 2849 | 1749 | 第1353章 |
Z縮放器 | 5340 | 2953 | 2491 |
內斯科普 | 6513 | 3748 | 2897 |
帕洛阿爾托網路 | |||
蔚藍美國東部 | |||
雲耀 | 第1692章 | 989 | 1169 |
Z縮放器 | 5403 | 2951 | 2412 |
內斯科普 | 6601 | 3805 | 2964 |
帕洛阿爾托網路 | |||
GCP 美國東部 | |||
雲耀 | 2811 | 1615 | 1320 |
Z縮放器 | |||
內斯科普 | 6694 | 3819 | 3023 |
帕洛阿爾托網路 | 2258 | 第894章 | 第1464章 |
您可能會注意到,對於現有會話,Palo Alto Networks 看起來領先於 Cloudflare(因此整體排名第 95%)。但這些數字具有誤導性,因為 Palo Alto Networks 的 ZTNA 行為與我們、Zscaler 或 Netskope 的行為略有不同。當他們執行新會話時,它會執行完整的連接攔截並從其處理器返迴響應,而不是將用戶定向到他們嘗試存取的應用程式的登錄頁面。
這意味著 Palo Alto Networks 的新會話響應時間實際上並不能測量我們正在尋找的端到端延遲。因此,他們的新會話延遲和總會話延遲數據具有誤導性,這意味著我們只能將自己與他們的現有會話延遲進行有意義的比較。當我們查看現有會話時,當 Palo Alto Networks 充當傳遞者時,Cloudflare 仍然領先 10%。
在新加坡也是如此,對於現有會話,Cloudflare 比 Zscaler 和 Netskope 快 50%,也比 Palo Alto Networks 快 10%:
新加坡託管應用程序的 95% HTTP 響應時間(毫秒) | |||
---|---|---|---|
AWS 新加坡 | 總計(毫秒) | 新會話(毫秒) | 現有會話(毫秒) |
雲耀 | 2748 | 1568 | 1310 |
Z縮放器 | 5349 | 3033 | 2500 |
內斯科普 | 6402 | 3598 | 2990 |
帕洛阿爾托網路 | |||
蔚藍新加坡 | |||
雲耀 | 1831年 | 1022 | 第1181章 |
Z縮放器 | 5699 | 3037 | 2577 |
內斯科普 | 6722 | 3834 | 3040 |
帕洛阿爾托網路 | |||
基仕伯新加坡 | |||
雲耀 | 2820 | 第1641章 | 第1355章 |
Z縮放器 | 5499 | 3037 | 2412 |
內斯科普 | 6525 | 3713 | 2992 |
帕洛阿爾托網路 | 2293 | 922 | 第1476章 |
對這一數據的一個批評可能是,我們將所有 Catchpoint 節點的時間聚合在 P95 處,並且我們沒有查看與應用程序位於同一區域中的第 95 個百分位數的 Catchpoint 節點。我們也研究了這一點,Cloudflare 的 ZTNA 性能仍然更好。僅查看基於北美的 Catchpoint 節點,在 P95 的熱連接方面,Cloudflare 的性能比 Netskope 好 50%,比 Zscaler 好 40%,比 Palo Alto Networks 好 10%:

零信任網路存取 與北美測試地點的熱連接的 HTTP 響應時間為 95% | |
---|---|
提供者 | P95 HTTP 響應(毫秒) |
雲耀 | 810 |
Z縮放器 | 1290 |
內斯科普 | 第1351章 |
帕洛阿爾托網路 | 第871章 |
最後,我們想要展示 ZTNA 性能的一件事是 Cloudflare 每個區域每個雲的性能如何。下圖顯示了雲提供商和測試區域的矩陣:
每個雲提供商和區域中最快的 ZTNA 提供商(按 95% HTTP 響應計算) | |||
---|---|---|---|
AWS | 天藍色 | GCP | |
澳大利亞東部 | 雲耀 | 雲耀 | 雲耀 |
巴西南部 | 雲耀 | 雲耀 | 不適用 |
加拿大中部 | 雲耀 | 雲耀 | 雲耀 |
印度中部 | 雲耀 | 雲耀 | 雲耀 |
美國東部 | 雲耀 | 雲耀 | 雲耀 |
南非北部 | 雲耀 | 雲耀 | 不適用 |
美國中南部 | 不適用 | 雲耀 | Z縮放器 |
東南亞 | 雲耀 | 雲耀 | 雲耀 |
瑞士北部 | 不適用 | 不適用 | 雲耀 |
阿聯酋 迪拜 | 雲耀 | 雲耀 | 雲耀 |
英國南部 | 雲耀 | 雲耀 | 內斯科普 |
美國西部 | 雲耀 | 雲耀 | 不適用 |
部分雲中的部分虛擬機出現故障,無法報告準確的數據。但在我們擁有準確數據的 30 個可用雲區域中,Cloudflare 是其中 28 個中最快的 ZT 提供商,這意味著我們在 93% 的測試雲區域中速度更快。
總而言之,Cloudflare 在評估零信任網絡訪問時還提供了最佳體驗。但另一個難題又如何呢:遠程瀏覽器隔離 (RBI)?
遠程瀏覽器隔離:託管在雲中的安全瀏覽器
遠程瀏覽器隔離產品對公共互聯網有很強的依賴性:如果您與瀏覽器隔離產品的連接不好,那麼您的瀏覽器體驗會感覺怪異且緩慢。遠程瀏覽器隔離非常依賴於性能,才能讓用戶感到流暢和無縫:如果一切都按預期速度快速,那麼用戶甚至不應該注意到他們正在使用瀏覽器隔離。
在本次測試中,我們再次將 Cloudflare 與 Zscaler 進行比較。雖然 Netskope 確實有 RBI 產品,但由於它需要 SWG 客戶端,我們無法對其進行測試,這意味著我們無法像測試 Cloudflare 和 Zscaler 時那樣獲得測試位置的完全保真度。我們的測試表明,對於遠程瀏覽場景,Cloudflare 比 Zscaler 快 64%:以下是我們的 RBI 測試中每個區域每個雲最快提供商的矩陣:
每個雲提供商和區域中最快的 RBI 提供商(按 95% HTTP 響應計算) | |||
---|---|---|---|
AWS | 天藍色 | GCP | |
澳大利亞東部 | 雲耀 | 雲耀 | 雲耀 |
巴西南部 | 雲耀 | 雲耀 | 雲耀 |
加拿大中部 | 雲耀 | 雲耀 | 雲耀 |
印度中部 | 雲耀 | 雲耀 | 雲耀 |
美國東部 | 雲耀 | 雲耀 | 雲耀 |
南非北部 | 雲耀 | 雲耀 | |
美國中南部 | 雲耀 | 雲耀 | |
東南亞 | 雲耀 | 雲耀 | 雲耀 |
瑞士北部 | 雲耀 | 雲耀 | 雲耀 |
阿聯酋 迪拜 | 雲耀 | 雲耀 | 雲耀 |
英國南部 | 雲耀 | 雲耀 | 雲耀 |
美國西部 | 雲耀 | 雲耀 | 雲耀 |
此圖表顯示了針對 Cloudflare 和 Zscaler 運行的所有測試的結果,這些測試的應用程序式託管在 12 個不同位置的三個不同雲上,來自與 ZTNA 測試相同的 400 個 Catchpoint 節點。在每種情況下,Cloudflare 都更快。事實上,沒有針對受 Cloudflare 保護的端點進行的測試具有超過 2105 毫秒的第 95 個百分位 HTTP 響應,而沒有受 Zscaler 保護的端點的第 95 個百分位 HTTP 響應低於 5000 毫秒。
為了獲取這些數據,我們利用相同的虛擬機來託管通過 RBI 服務訪問的應用程序。每個 Catchpoint 節點都會嘗試通過 RBI 登錄應用程序,接收身份驗證憑據,然後嘗試通過傳遞憑據來訪問頁面。我們查看與 ZTNA 相同的新會話和現有會話,Cloudflare 在新會話和現有會話場景中也更快。
必須走得快
我們的零信任客戶希望我們速度快,不是因為他們想要最快的互聯網存取,而是因為他們想知道員工的工作效率不會因切換到 Cloudflare 而受到影響。這並不一定意味著對我們來說最重要的是比我們的競爭對手更快,儘管我們確實如此。對我們來說,最重要的是改善我們的體驗,以便我們的用戶知道我們認真對待他們的體驗而感到放心。當我們在九月份的生日週發布新的數字並且我們的速度比以前更快時,這並不意味著我們只是讓數據上升:這意味著我們正在不斷評估和改進我們的服務,以提供最好的服務為我們的客戶提供體驗。我們更關心阿聯酋的客戶使用 Office365 獲得更好的體驗,而不是在測試中擊敗競爭對手。