仅 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 的性能就好比在高速公路上行驶。如果您饿了，需要吃饭，您会想去一个靠近高速公路同时可以快速出餐的地方。如果一家在一秒钟内就能提供汉堡的餐厅需要 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 用户的端到端体验。