僅 2023 年，Cloudflare 就對 Zero Trust 效能進行了多次深入研究：一次在 1 月，一次在 3 月，一次在 Speed Week。對於每一次深入研究，我們都概述了我們執行的一系列測試，然後表明我們是最快的。雖然有些人可能認為這是一種行銷噱頭，但事實並非如此：我們設計的測試不一定是為了讓我們看起來最好，但我們的網路確實讓我們在執行測試時看起來最好。
我們以前在部落格中討論過為什麼效能很重要，簡單來說，效能不佳是一種威脅因素：我們最不希望的就是使用者關閉 Zero Trust 來獲得可用的體驗。我們的目標是提高效能，因為這有助於提高使用者的安全性以及對您來說最重要內容的安全性，並讓您的使用者提高生產力。
當我們執行 Zero Trust 效能測試時，我們首先測量從使用者傳送封包，到 Zero Trust 代理接收、轉發和檢查封包，再到目的地網站處理封包並傳回給使用者的端對端延遲。這個數字稱為 HTTP 回應，通常用於應用程式服務測試，以衡量 CDN 的效能。我們也用它來衡量我們的 Zero Trust 服務，但它不是衡量效能的唯一方法。Zscaler 透過代理延遲來衡量其效能，Netskope 透過解密延遲 SLA 來衡量效能。有些提供者則根本不考慮效能問題！
檢視網路效能有很多方法。然而，在 Cloudflare，我們認為衡量效能的最佳方法是使用端對端 HTTP 回應測量。在這篇部落格中，我們將討論為什麼端對端效能是最重要的、為什麼代理延遲和解密延遲 SLA 等其他方法不足以進行效能評估，以及您如何能夠像我們一樣衡量您的 Zero Trust 效能。
讓我們從頭開始
在評估任何場景的效能時，需要考慮的最重要的事情是您到底應該測量什麼。這一點看似明顯，但通常我們正在評估的東西並不能很好地實際衡量使用者看到的影響。一個很好的範例是當使用者查看網路速度測試時：測量頻寬並不能準確測量您的網際網路連線速度。
因此，我們必須問自己一個基本問題：使用者如何與 Zero Trust 產品互動？答案是他們不應該互動，或者說他們不應該知道自己正在與 Zero Trust 服務互動。使用者實際上是與託管在網際網路上的網站和應用程式進行互動：也許他們正在與 Microsoft Exchange 的私人執行個體進行互動，或者他們可能正在存取雲端的 Salesforce。無論是哪種情況，位於兩者之間的 Zero Trust 服務都充當正向代理：它們接收來自使用者的封包，篩選以進行安全性和存取評估，然後將封包傳送到目的地。如果服務正常工作，使用者根本不會注意到它們的存在。
因此，當我們研究 Zero Trust 服務時，我們必須研究透明變為不透明的場景：當 Zero Trust 服務暴露自己並導致高延遲甚至應用程式失敗的情況。為了模擬這些場景，我們必須存取使用者經常存取的網站。如果我們模擬通過 Zero Trust 平台存取這些網站，就可以看到當請求路徑中存在 Zero Trust 時會發生什麼。
對我們來說幸運的是，我們確切地知道如何模擬使用者請求存取網站。我們在衡量開發人員平台和網路基準分析效能方面擁有豐富的經驗。透過將 Zero Trust 效能與我們的其他效能分析計畫結合起來，我們很容易提高效能，並確保我們所有的努力都集中在盡可能快地為大多數人服務。就像我們對其他 Cloudflare 產品的分析一樣，這種方法將客戶和使用者放在第一位，確保他們獲得最佳效能。
開放式網際網路的挑戰
在效能方面，Zero Trust 服務自然會處於劣勢：它們會自動在使用者和他們嘗試存取的服務之間新增額外的網路躍點。這是因為正向代理位於使用者和公共網際網路之間，用於篩選和保護流量。這意味著 Zero Trust 服務需要保持與終端使用者 ISP 的連線，保持與雲端提供者的連線，以及穿過連接用於傳送和接收大多數公用網際網路流量的服務的網路。這通常是透過對等和互連關係來完成的。除了維護所有連線之外，服務還需要時間來實際處理規則和封包檢查。考慮到所有這些挑戰，這種情況下的效能管理非常複雜。
一些提供者試圖透過降低效能範圍來規避這一問題。這本質上就是 Zscaler 的代理延遲和 Netskope 的解密延遲：嘗試移除網路路徑中難以控制的部分，只關注他們可以控制的請求的各個方面。更具體地說，這些延遲僅關注請求在 Zscaler 或 Netskope 的實際硬體上花費的時間。這樣做的好處是，它允許這些提供者在延遲方面做出一定程度的保證。這種思路傳統上源於嘗試替換可能無法內聯處理請求的硬體防火牆和 CASB 服務。Zscaler 和 Netskope 正在努力證明他們可以根據請求處理規則和動作，並且仍然保持高效能。
但正如我們在一月份的部落格中所展示的那樣，在 Zero Trust 網路中的電腦上花費的時間，僅占終端使用者所經歷的請求時間的一小部分。請求的大部分時間都花在機器之間的線路上。當您考慮效能時，您需要從整體上考慮它，而不是單個元素，例如機上處理延遲。因此，若是將效能範圍縮小到僅查看機上處理延遲，您實際上並沒有看到任何接近效能全貌的內容。為了加快速度，提供者需要關注網路的各個方面及其運作方式。那麼讓我們來談談提高 Zero Trust 服務效能所需的所有元素。
如何獲得更好的 Zero Trust 效能？
Zero Trust 的效能就好比在高速公路上行駛。如果您餓了，需要吃飯，您會想去一個靠近高速公路同時可以快速出餐的地方。如果一家在一秒鐘內就能提供漢堡的餐廳需要 15 分鐘的路程，那麼他們提供漢堡的速度有多快並不重要，因為前往這家餐廳所花費的時間並不值得。休息站的麥當勞餐廳可能出餐速度與其他餐廳相同，但距離更短。您所選的餐廳應靠近高速公路，而且上菜速度要快。如果另一個方面很慢，則僅考慮兩者中的一個因素會影響您的整體時間。
基於這個類比，除了擁有良好的處理時間之外，提高 Zero Trust 效能的最佳方法是在最後一英里進行良好的對等，與託管重要應用程式的網路進行良好的對等，並在網際網路上擁有不同的路徑，以便在出現問題時引導流量。讓我們來逐一分析它們的重要性。
最後一英里對等互連
我們以前討論過為什麼更靠近使用者對提高效能至關重要，這裡簡單總結一下：如果 Zero Trust 提供者接收封包的實際位置離您很近，您的封包在您的裝置和試圖存取的應用程式之間的路徑就會更順暢。由於 Zero Trust 網路總是會產生額外的躍點，如果該躍點與您存取網站的請求通常會經過的路徑一致，那麼您的 Zero Trust 網路產生的開銷將微乎其微。
在上圖中，您可以看到三種連線模型：一種從使用者直接到網站，一種透過一般正向代理，一種透過 Cloudflare。每條線的長度代表點對點延遲。基於此，您可以看到正向代理路徑更長，因為這兩個段加起來比直接連線更長。這條額外的行進路徑在網路世界中被稱為髮夾彎。我們的目標是讓使用者和網站之間盡可能保持直線，因為這是兩者之間的最短距離。
您的 Zero Trust 提供者離您越近，就越容易實現較小的路徑。我們非常擅長應對這一挑戰，因為我們一直在投資，利用我們超過 12,000 個對等互連網路來拉近與使用者的距離，無論他們身在何處。
雲端對等互連
但接近使用者只是成功的一半。一旦流量進入 Zero Trust 網路，就需要將其傳送到目的地。這些目的地通常託管在 Azure、Amazon Web Services 或 Google Cloud 等超大規模雲端提供者中。這些超大規模網路是具有數百個位置的全球網路，供使用者儲存資料和託管服務。如果 Zero Trust 網路在所有提供運算的地方都沒有與所有這些網路很好地對等互連，那麼這條直線路徑就會開始偏離：雖然偏離程度比最後一英里的情況要少，但仍然足以被終端使用者注意到。
Cloudflare 透過與這些主要雲端提供者進行對等互連來提供幫助，確保 Cloudflare 與相應雲端之間的切換短暫且無縫。Cloudflare 與全球 40 多個不同城市的主要雲端提供者建立了對等互連，確保無論應用程式託管在哪裡，Cloudflare 都能與之連線。
兩者之間所有內容的備選路徑
如果 Zero Trust 網路具有良好的最後一英里連線性和良好的雲端連線性，那麼剩下的唯一事情就是能夠在兩者之間傳遞流量。在 Zero Trust 網路中擁有多樣化的網路路徑，對於繞過網路問題轉移流量以及在 Zero Trust 網路上提供可靠且高效能的私人連線非常有價值。為此，Cloudflare 利用我們自己的私人骨幹網，該骨幹網幫助我們為所有場景類型提供更高水準的效能。
獲得重要的測量結果
現在我們知道了我們正在嘗試測量哪些場景以及如何使它們更快，那麼我們如何測量它們呢？答案非常簡單：我們透過 Zero Trust 服務進行 HTTP 呼叫，並測量回應時間。當我們執行閘道測試時，我們設定一個用戶端程式，透過我們的 Zero Trust 用戶端定期連接到企業常用的一堆網站，並測量 HTTP 計時以計算 HTTP 回應。
正如我們之前討論的，回應是使用者將封包傳送到 Zero Trust 代理，Zero Trust 代理接收、轉發和檢查封包，然後將其傳送到目標網站，目標網站處理封包並將回應一路傳回給使用者所花費的時間。這種測量很有價值，因為它使我們能夠專門關注網路效能，而不一定是 Web 應用程式載入和呈現內容的能力。我們不會衡量最大內容繪製之類的東西，因為它們依賴於目的地上的軟體堆疊、目的地是否由 CDN 提供前端服務以及它們的效能如何，甚至還取決於發出請求的瀏覽器。我們想要衡量 Zero Trust 服務將封包從裝置傳送到網站並返回的效果如何。我們當前的測量方法側重于向用戶端提供回應的時間，而忽略了一些用戶端處理，例如瀏覽器轉譯時間（最大內容繪製）和應用程式特定指標（例如 UDP 影片傳遞）。
您也可以做到
測量效能看似複雜，但在 Cloudflare，我們努力使其變得簡單。您衡量使用者體驗的目標和我們提供更快體驗的目標是完全一致的，我們為檢視效能而構建的工具不僅面向使用者，還用於內部效能改進。我們特地打造的產品 Digital Experience Monitoring 不僅可以顯示出錯的地方，還可以監控您的 Zero Trust 效能，以便您能夠與我們一起追蹤您的使用者體驗。我們使用這些資料來協助識別我們網路上的故障和問題，以確保您獲得良好的體驗。利用 Digital Experience Monitoring，您可以與我們一樣進行測試來測量您關心的端點，您可以在 Cloudflare 儀表板中看到 HTTP 回應的結果。您進行的測試越多，便可更好地瞭解您的體驗，也就越能幫助我們更好地瞭解 Zero Trust 在我們的網路和更廣泛的網際網路中的體驗。
就像 Cloudflare 的其他產品一樣，我們的效能測量也是以使用者為中心而設計的。當我們對這些數字進行測量和調查時，我們知道，改善這些數字，也就是改善 Zero Trust 使用者的端對端體驗。