每逢 Innovation Week，Cloudflare 都會對我們與競爭對手的網路效能進行審視和比較。在過去幾週裡，我們一直在關注與反向 Proxy（如 Akamai）或銷售邊緣運算的平台（如 Fastly 和 AWS，對應於我們的 Supercloud）相比，我們快了多少。在 CIO Week 期間，我們希望向您展示我們的網路如何與提供正向 Proxy 服務的競爭對手一較高下。這些產品是我們的 Zero Trust 平台的一部分，這有助於為應用程式和公共網際網路連線體驗提供安全保障，與此相反，我們的反向 Proxy 會保護您的網站免受外部使用者存取。
我們執行了一系列測試，將我們的 Zero Trust 服務與 Zscaler 進行比較。我們比較了我們的 ZT 應用程式保護產品 Cloudflare Access 與 Zscaler Private Access (ZPA)。我們還比較了我們的安全 Web 閘道 Cloudflare Gateway 與 Zscaler Internet Access (ZIA)，最後比較了我們的遠端瀏覽器隔離產品 Cloudflare Browser Isolation 與 Zscaler Cloud Browser Isolation。我們發現，Cloudflare Gateway 比 ZIA 快 58%（在測試中），Cloudflare Access 比 ZPA 快 38%（在全球範圍內），而 Cloudflare Browser Isolation 比 Zscaler Cloud Browser Isolation 快 45%（在全球範圍內）。針對每一項測試，我們都使用了第 95 百分位的第一個位元組接收時間和回應時間，它們會測量使用者發出要求以及取得回應開頭（第一個位元組接收時間）和回應結尾（回應）所花費的時間。這些測試旨在嘗試從終端使用者角度測量效能。
在這篇部落格中，我們將討論為什麼效能對每一種產品都極為重要，深度剖析我們測量哪些項目來證明我們更快，我們還會討論如何測量每一種產品的效能。
為什麼效能極為重要？
效能之所以極為重要，是因為它會影響員工的體驗及其完成工作的能力。無論是透過存取控制產品存取服務，透過安全 Web 閘道連線至公共網際網路，還是透過遠端瀏覽器隔離保護有風險的外部網站，所有這些體驗都應該是順暢的。
比如說，在 Acme Corporation 工作的 Anna 為了完成一些工作，正在從雪梨連線至 Microsoft 365 或 Teams。如果 Acme 的安全 Web 閘道位於距離 Anna 很遠的新加坡，則 Anna 的流量可能會從雪梨流向新加坡，然後再流回到雪梨，到達她的電子郵件。如果 Acme Corporation 像很多公司那樣，要求 Anna 在線上模式中使用 Microsoft Outlook，她的效能就會極為低落，因為她需要等待電子郵件傳送和接收。Microsoft 365 建議，盡可能縮短延遲，盡可能增加頻寬。Anna 必須透過閘道進行的額外跳躍會降低輸出量並增加延遲，從而為 Anna 帶來糟糕的體驗。
在另一個範例中，如果 Anna 為了完成一些工單，正在連線至代管的受保護應用程式（如 Jira），她不想一直等待頁面載入或驗證要求。在一個存取受控的應用程式中，若要進行連線，首先需要登入。如果登入花費的時間較長，您可能會因為同事的一條隨機訊息而分心，也可能完全不想處理任何工作了。而且即使通過了驗證，您仍然希望擁有快速而流暢的一般應用程式體驗：當 Zero Trust 達到最佳效能時，使用者永遠不會注意到它的存在。
如果這些產品效能較低或體驗較差，則可能會發生比使用者抱怨更糟糕的事情：他們可能會想辦法關閉產品或略過它們，而這些行為會讓您的公司面臨風險。如果 Zero Trust 產品套件因為效能低而無人使用，那它就是完全無效的。確保 Zero Trust 快速對於 Zero Trust 解決方案的有效性至關重要：如果員工根本不知道它的存在，就不會想要關閉它，讓自己面臨風險。
Zscaler 這類服務的效能可能會勝過很多老舊過時的解決方案，但其網路仍然無法與高效能和最佳化的 Cloudflare 網路相媲美。我們測試了我們的所有 Zero Trust 產品和 Zscaler 的對應產品，我們將向您證明我們的速度更快。那麼，我們來對資料進行深入剖析，並透過三個關鍵的 Zero Trust 情境向您展示我們如何做到更快，以及為什麼我們更快，先從安全 Web 閘道開始：比較 Cloudflare Gateway 與 Zscaler Internet Access (ZIA)。
Cloudflare Gateway：一個部署在家門口的高效能安全 Web 閘道
安全 Web 閘道必須快速，這是因為它充當著一個組織所有網際網路繫結流量的漏斗。如果安全 Web 閘道速度較慢，則使用者傳輸至網際網路的任何流量都會很慢。如果傳輸至網際網路的流量較慢，則使用者可能會收到關閉閘道的提示，讓組織面臨攻擊風險。
不過，除了靠近使用者以外，高效能 Web 閘道還必須與網際網路的其餘部分充分地對等互連，從而在連線至使用者要存取的網站時避開較慢的路徑。請記住，通過安全 Web 閘道的流量會遵循一個正向 Proxy 路徑：使用者連線至 Proxy，然後 Proxy 連線至使用者要存取的網站。因此，Proxy 必須正確連線，才能確保使用者流量能夠盡快到達所需位置。
比較安全 Web 閘道產品時，我們讓 Cloudflare Gateway 和 WARP 用戶端與執行相同功能的 Zscaler Internet Access (ZIA) 一較高下。對於 Cloudflare 使用者而言，幸運的是，閘道和 Cloudflare 的網路不僅深入內嵌至靠近使用者的最後一哩網路，還是世界上對等互連最充分的網路之一。在閘道使用者情境中，我們使用對等互連最充分的網路，可比 ZIA 快 55%。下面是一個盒狀圖，其中顯示 Cloudflare、Zscaler 和一個完全未使用閘道的對照組的第 95 百分位的回應時間：
安全 Web 閘道 — 回應時間
| Secure Web Gateway - Response Time | |
|---|---|
| 95th percentile (ms) | |
| Control | 142.22 |
| Cloudflare | 163.77 |
| Zscaler | 365.77 |
第 95 百分位（毫秒）
控制
142.22
Cloudflare
163.77
Zscaler
365.77
| Zscaler Internet Access (ZIA) | P90 Proxy Latency (ms) | P95 Proxy Latency (ms) | P99 Proxy Latency (ms) | P99.9 Proxy Latency (ms) | P99.957 Proxy Latency (ms) |
|---|---|---|---|---|---|
| Global | 06.0 | 142.0 | 625.0 | 1,071.7 | 1,383.7 |
| Azure Site | 97.0 | 181.0 | 458.5 | 1,032.7 | 1,291.3 |
| Zoom | 206.0 | 254.2 | 659.8 | 1,297.8 | 1,455.4 |
| Slack | 118.8 | 186.2 | 454.5 | 1,358.1 | 1,625.8 |
| Workers Site | 97.8 | 184.1 | 468.3 | 1,246.2 | 1,288.6 |
| 13.7 | 100.8 |
392.6 | 848.9 | 1,115.0 |
這些資料表明，Cloudflare 不僅在閘道情境中比 Zscaler 快得多，而且 Cloudflare 實際上比 Zscaler 更接近於完全不使用安全 Web 閘道。
| Cloudflare Gateway | P90 Proxy Latency (ms) | P95 Proxy Latency (ms) | P99 Proxy Latency (ms) | P99.9 Proxy Latency (ms) | P99.957 Proxy Latency (ms) |
|---|---|---|---|---|---|
| Global | 5.6 | 7.2 | 15.6 | 32.2 | 101.9 |
| Azure Site | 6.2 | 7.7 | 12.3 | 18.1 | 19.2 |
| Zoom | 5.1 | 6.2 | 9.6 | 25.5 | 31.1 |
| Slack | 5.3 | 6.5 | 10.5 | 12.5 | 12.8 |
| Workers Site | 5.1 | 6.1 | 9.4 | 17.3 | 20.5 |
| 5.3 | 7.4 | 12.0 | 26.9 | 30.2 |
為了最好地衡量終端使用者閘道體驗，我們從終端使用者角度審視了第 95 百分位的回應時間：我們測量了使用者通過 Proxy、讓 Proxy 向網際網路上的網站發出要求，以及最後傳回回應花費的時間。這類測量非常重要，因為它準確地表現了使用者看到的情況。
在與 Zscaler 進行比較時，我們讓終端使用者用戶端嘗試存取 5 個不同的網站：一個在 Azure 中代管的網站、一個受 Cloudflare 保護的 Workers 網站、Google、Slack 和 Zoom：使用者會定期連線至這些網站。在上述每種情況下，Cloudflare 的表現都優於 Zscaler，而在受 Cloudflare 保護的 Workers 中，閘道的第 95 百分位的回應時間甚至優於對照組。下面是一個盒狀圖，其中顯示依我們在測試中所查詢的不同端點細分的第 95 百分位的回應時間：
無論您在網際網路上走到哪裡，從端對端回應時間來看，Cloudflare Gateway 的表現始終優於 Zscaler Internet Access (ZIA)。可是為什麼我們會比 Zscaler 快那麼多呢？答案跟 Zscaler 所稱的 Proxy 延遲有關。
Proxy 延遲是使用者要求被傳送至目的地並傳回使用者之前在 Zscaler 機器上花費的時間。此數據完全排除了使用者連線至 Zscaler 所花費的時間以及 Zscaler 連線至目的地所花費的時間，並將測量限制為 Zscaler 處理要求所花費的毫秒數。
Zscaler 的延遲 SLA 表明，95% 的要求在 Zscaler 裝置上花費的時間不足 100 毫秒。Zscaler 承諾，針對 95% 的使用者要求，他們可在其邊緣測量的延遲，而不是實際上極為重要的端對端延遲不會超過 100 毫秒。您甚至可以在 Zscaler 的數位體驗中看到那些計量，來自行測量。如果我們能從 Zscaler 記錄中取得此 Proxy 延遲並將其與 Cloudflare 對應物進行比較，就可以看到我們是如何達到 Zscaler 的 SLA 計量的。雖然我們未向客戶公開這些計量，但我們能夠在 Cloudflare 上啟用追蹤來測量 Cloudflare Proxy 延遲。
結果顯示，在第 95 百分位，Zscaler 超過了其 SLA，而 Cloudflare Proxy 延遲為 7 毫秒。此外，當我們的 Proxy 延遲為 100 毫秒（符合 Zscaler SLA），他們的 Proxy 延遲是我們的 10 倍以上。Zscaler 的 Proxy 延遲造成了我們在第 95 百分位看到的效能差異，在每一個網站，都比 Cloudflare 慢 140-240 毫秒。下面是所有測試網站在不同百分位的 Zscaler Proxy 延遲值，然後依每個網站細分：
Zscaler Internet Access (ZIA)
| ZT Access - Time to First Byte (Global) | |
|---|---|
| 95th Percentile (ms) | |
| Cloudflare | 849 |
| Zscaler | 1,361 |
P90 Proxy 延遲（毫秒）
P95 Proxy 延遲（毫秒）
P99 Proxy 延遲（毫秒）
P99.9 Proxy 延遲（毫秒）
| ZT Access - 95th Percentile Time to First Byte (Chicago) |
||
|---|---|---|
| New Sessions (ms) | Existing Sessions (ms) | |
| Cloudflare | 1,032 | 293 |
| Zscaler | 1,373 | 338 |
P99.957 Proxy 延遲（毫秒）
全球
06.0
142.0
625.0
1,071.7
1,383.7
Azure 網站
97.0
181.0
458.5
| ZT RBI - Time to First Byte (Global) | |
|---|---|
| 95th Percentile (ms) | |
| Cloudflare | 2,072 |
| Zscaler | 3,781 |
1,032.7
| ZT RBI - Time to First Byte (Global) | |
|---|---|
| 95th Percentile (ms) | |
| Cloudflare | 2,394 |
| Zscaler | 3,932 |
1,291.3
Zoom
206.0
254.2
659.8
1,297.8
1,455.4
Slack
118.8
186.2
454.5
1,358.1
1,625.8
Workers 網站
97.8
184.1
468.3
1,246.2
1,288.6
13.7
100.8
392.6
848.9
1,115.0
在第 95 百分位，不僅他們的 Proxy 延遲超出 SLA，那些值還顯示出 Zscaler 和 Cloudflare 之間的差異：以 Zoom 為例，如果 Zscaler 沒有 Proxy 延遲，則會與 Cloudflare 和對照組不相上下。對應的 Cloudflare 的 Proxy 延遲太小了，以至於使用我們就像使用公共網際網路一樣：
Cloudflare Gateway
P90 Proxy 延遲（毫秒）
P95 Proxy 延遲（毫秒）
P99 Proxy 延遲（毫秒）
P99.9 Proxy 延遲（毫秒）
P99.957 Proxy 延遲（毫秒）
全球
5.6
7.2
15.6
32.2
101.9
Azure 網站
6.2
7.7
12.3
18.1
19.2
Zoom
5.1
6.2
9.6
25.5
31.1
Slack
5.3
6.5
10.5
12.5
12.8
Workers 網站
5.1
6.1
9.4
17.3
20.5
5.3
7.4
12.0
26.9
30.2
其中包括 99.957 百分位似乎很奇怪，但在它所標示的百分位，Cloudflare 的 Proxy 延遲終於超過了 100 毫秒。Cloudflare 的 99.957 百分位的 Proxy 延遲甚至比 Zscaler 的第 90 個百分位的 Proxy 延遲還要快。即使在 Zscaler 關注並對 Proxy 延遲（儘管客戶並不關心該計量）負責的計量上，Cloudflare 也更快。
取得這種資料檢視並不容易。現有的測試架構（如 Catchpoint）並不適合此工作，因為效能測試要求您在測試端點上執行 ZIA 用戶端或 WARP 用戶端。我們還必須確保 Cloudflare 測試和 Zscaler 測試在相同位置的類似機器上執行，以盡量準確地測量效能。這讓我們能夠測量來自兩個測試環境所在的相同位置的端對端回應：
在我們的設定中，我們將三個 VM 並列置於雲端：一個執行連線至我們的閘道的 Cloudflare WARP，一個執行 ZIA，還有一個完全不執行任何 Proxy 作為對照組。這些 VM 每三分鐘向上文提及的 5 個不同的端點發出要求，並記錄 HTTP 瀏覽器時間以瞭解每個要求所花費的時間。根據這些資料，我們能夠得到一個面向使用者的效能檢視，這是很有意義的。
簡單總結一下目前的情況：從終端使用者角度來看，當我們透過安全 Web 閘道保護使用者免受公共網際網路影響時，Cloudflare 比 Zscaler 快。根據 Zscaler 針對透過安全 Web 閘道的效能是什麼的小範圍定義，Cloudflare 比 Zscaler 更快。但是，我們來看一些需要透過 Zero Trust 存取來存取特定應用程式的情境。
Cloudflare Access：最快速的 Zero Trust Proxy
存取控制不僅必須順暢，而且對使用者來說必須是透明的：對 Zero Trust 解決方案最好的讚美就是員工幾乎不會注意到它的存在。藉助 Cloudflare Access 和 Zscaler Private Access (ZPA) 這樣的服務，使用者可以在提供者網路上快取驗證資訊，從而確保安全快速地存取應用程式，為使用者提供他們需要的順暢體驗。因此，如果一個網路不僅會最大限度減少所需登入次數，同時還縮短應用程式要求的延遲，則有助於確保您的網際網路體驗既快速又有回應。
Cloudflare Access 比 Zscaler Private Access (ZPA) 快 38%，確保無論您身處世界何處，都會獲得快速安全的應用程式體驗：
ZT Access — 第一個位元組接收時間（全球）
第 95 百分位（毫秒）
Cloudflare
849
Zscaler
1,361
在對資料進行深入剖析後，我們發現，在世界任何一個地方，Cloudflare 都是一樣的快速。以東京為例，Cloudflare 的第 95 百分位的第一個位元組接收時間比 Zscaler 快 22%：
當我們在應用程式存取情境中評估 Cloudflare 和 Zscaler 時，我們考量了兩種截然不同的情境，需要分別進行測量。第一個情境是使用者登入應用程式且必須驗證。在這種情況下，Zero Trust Access 服務會將使用者導向至登入頁面，使用者將進行驗證，然後被重新導向至應用程式。
這種情境稱為新工作階段，因為在 Access 網路上未快取或者不存在任何驗證資訊。第二種情境稱為現有工作階段，即使用者已經通過驗證並且可以快取該驗證資訊。這種情境通常更快速，因為不需要額外呼叫識別提供者即可完成。
我們希望單獨測量這些情境，因為當我們查看第 95 百分位值時，如果我們將新工作階段和現有工作階段組合在一起，我們幾乎總是會查看新工作階段。但在兩種情境中，Cloudflare 在每個地區都是更快的。當您選取一個 Zscaler 更有可能具有充分對等互連的位置時，這些資料顯示如下：位於伊利諾州芝加哥的使用者連線至在美國中部代管的應用程式。
ZT Access — 第 95 百分位的第一個位元組接收時間（芝加哥）
新工作階段（毫秒）
現有工作階段（毫秒）
Cloudflare
1,032
293
Zscaler
1,373
338
Cloudflare 的總體速度也是更快的。下面是總體新連線的第 95 百分位的回應時間長條圖：
您會看到 Cloudflare 的網路確實提升了登入效能，有助於找到最佳路徑以回到驗證提供者那裡擷取登入詳細資料。在這項測試中，Cloudflare 傳回登入回應所花費的時間從未超過 2.5 秒，但 Zscaler 有一半的第 95 個百分位的回應都幾乎翻倍，即 4 秒左右。這表明，Zscaler 的網路沒有對等互連，導致早期出現延遲。但也可能表明，如果建立連線且快取所有資訊，Zscaler 的表現可能會更出色。但在現有連線上，Cloudflare 仍然遙遙領先：
Zscaler 和 Cloudflare 在較低的延遲貯體上確實不相上下，但 Cloudflare 的回應時間更為一致，您可以看到 Zscaler 有一半的回應幾乎需要 1 秒鐘才能載入。這就更進一步強調了我們的網路連線非常出色：因為我們覆蓋的位置更多，我們提供的應用程式體驗更好，並且我們沒有那麼多延遲高且應用程式效能差的邊緣案例。
我們希望將這些新工作階段和現有工作階段分開，因為若要進行真正的比較，一定要查看類似的要求路徑。例如，如果比較現有工作階段上透過 Zscaler 的要求和新工作階段上透過 Cloudflare 的要求，我們會看到，Cloudflare 比 Zscaler 慢得多，因為需要進行驗證。因此，當我們與第三方簽約來設計這些測試時，應確保他們將這一點納入考量。
針對這些測試，Cloudflare 與 Miercom 簽約，該第三方執行了一組測試，旨在複製一個連線至受 Cloudflare 或 Zscaler 保護的資源的終端使用者。Miercom 在全世界 14 個位置設定了應用程式執行個體，並設計了一項測試，會透過各種 Zero Trust 提供者登入應用程式來存取特定內容。測試方法如下所述，但您可以在這裡查看 Miercom 的完整報告，其中詳細描述了他們的測試方法：
使用者透過由 Catchpoint 執行個體模仿的瀏覽器連線至應用程式 — 新工作階段
使用者針對識別提供者進行驗證
使用者存取資源
使用者重新整理瀏覽器頁面並嘗試存取相同的資源，但使用已存在的憑證 — 現有工作階段
這讓我們能夠針對新工作階段和現有工作階段的應用程式效能，比較 Cloudflare 和 Zscaler，並且我們已經證明了我們更快。在安全 Web 閘道情境中，我們也更快。
使用遠端瀏覽器隔離可以為安全 Web 閘道和 Zero Trust 存取情境提供進一步保護。RBI 提供了一種無用戶端方法，既可保護應用程式內的資料存取，又可在瀏覽公共網際網路上的資源時提供威脅防禦。
Cloudflare Browser Isolation：您的友好的芳鄰 Web 瀏覽器
遠端瀏覽器隔離產品對公共網際網路有很強的依賴性：如果您與瀏覽器隔離產品的連線不是太好，則您的瀏覽器體驗就會感覺有些怪異，並且非常緩慢。遠端瀏覽器隔離是否會為使用者帶來順暢的體驗，很大程度上要取決於效能：如果一切都像正常情況下一樣快速，則使用者甚至都不會注意到自己正在使用瀏覽器隔離。在這項測試中，我們讓 Cloudflare Browser Isolation 與 Zscaler Cloud Browser Isolation 一較高下。
在遠端瀏覽器隔離效能方面，Cloudflare 還是比 Zscaler 快。透過比較第 95 百分位的第一個位元組接收時間，Cloudflare 在所有地區都比 Zscaler 快 45%：
ZT RBI — 第一個位元組接收時間（全球）
第 95 百分位（毫秒）
Cloudflare
2,072
Zscaler
3,781
在比較總回應時間或瀏覽器隔離產品將完整回應傳回使用者的能力時，Cloudflare 仍然比 Zscaler 快 39%：
ZT RBI — 第一個位元組接收時間（全球）
第 95 百分位（毫秒）
Cloudflare
2,394
Zscaler
3,932
Cloudflare 的網路在這方面確實非常出色，有助於為我們的客戶提供最佳使用者體驗。因為 Cloudflare 的網路在靠近終端使用者裝置的地方極為充分地對等互連，我們能夠縮減我們的第一個位元組接收時間和回應時間，從而幫助改進終端使用者體驗。
為了衡量這一點，我們回頭求助 Miercom，讓 Catchpoint 節點從全世界同樣的 14 個位置連線至 Cloudflare Browser Isolation 和 Zscaler Cloud Browser Isolation，並讓模擬用戶端的裝置嘗試在每個地區設定中透過瀏覽器隔離產品連線至應用程式，來為我們提供所需的資料。如需測試方法的詳細資訊，您可以參閱在這裡連結的同一份 Miercom 報告。
Zero Trust 世界的新一代效能
在非 Zero Trust 世界中，您和您的 IT 團隊是網路營運者 — 因此，您能夠掌控效能。雖然這種掌控令人欣慰，但對您的 IT 團隊而言也是一個巨大的負擔，他們必須管理辦公室與資源之間的中段連線。而在 Zero Trust 世界中，您的網路現在… 嗯，它是公有網際網路。這意味著您團隊的工作量變少了 — 但您的 Zero Trust 提供者要承擔的責任更大了，它必須管理您的每一位使用者的效能。您的 Zero Trust 提供者在改進端對端效能方面做得越好，您的使用者的體驗就會越好，您自身面臨的風險就會越小。針對像驗證和安全 Web 閘道這樣的即時應用程式，確保快速的使用者體驗至關重要。
Zero Trust 提供者不僅需要在公共網際網路上保護您的使用者，還必須最佳化公共網際網路，以確保您的使用者受到持續不斷的保護。移轉至 Zero Trust 不僅僅會減少對企業網路的需求，還會讓使用者流量更自然地流向資源。然而，鑑於您的 Zero Trust 提供者將成為您的所有使用者和所有應用程式的閘道管理員，效能是評估的一個關鍵層面，可以減少使用者的摩擦，並降低使用者抱怨、生產力下降或關閉解決方案的可能性。為了確保使用者始終享有最佳體驗，Cloudflare 不斷地改進我們的網路，不僅要路由修正程式，還要擴展對等互連排列和新增位置。正是這種不懈的努力讓我們成為了最快的 Zero Trust 提供者。
請查看我們的比較頁，瞭解 Cloudflare 的網路架構如何與 Zscaler 一較高下的詳細資料。