Cloudflare ist schneller als Zscaler

Während jeder Innovation Week vergleichen wir die Performance unseres Netzwerks mit der unserer Wettbewerber. In den vergangenen Wochen haben wir das Augenmerk vor allem darauf gerichtet, wie viel schneller wir im Vergleich zu Reverse-Proxy-Lösungen wie der von Akamai sind – oder zu Plattformen wie Fastly und AWS, die Edge-Computing anbieten, das sich mit dem unserer Supercloud vergleichen lässt. Anlässlich der CIO Week möchten wir Ihnen nun zeigen, wie unser Netzwerk gemessen an Wettbewerbern abschneidet, die Forward-Proxy-Dienste anbieten. Dabei geht es um Produkte, die Teil unserer Zero Trust-Plattform sind. Diese tragen dazu bei, Anwendungen und Erfahrungen im öffentlichen Internet abzusichern, während unser Reverse-Proxy Ihre Websites vor externen Nutzern schützt.

Wir haben eine Reihe von Tests durchgeführt, in denen wir unsere Zero Trust (ZT)-Dienste mit denen von Zscaler verglichen haben. Gegenübergestellt wurden erstens Cloudflare Access, unsere Lösung für ZT-Anwendungsschutz, und Zscaler Private Access (ZPA), zweitens unser Secure Web Gateway, Cloudflare Gateway, und Zscaler Internet Access (ZIA) und drittens unser Produkt für Remote-Browserisolierung, Cloudflare Browser Isolation, und Zscaler Cloud Browser Isolation. In unseren Tests war Cloudflare Gateway 58 Prozent schneller als ZIA, Cloudflare Access war weltweit 38 Prozent schneller als ZPA und die Cloudflare Browser Isolation war weltweit 45 Prozent schneller als Zscaler Cloud Browser Isolation. In jeder Kategorie haben wir die Time to First Byte (TTFB) und die Reaktionszeit im 95. Perzentil getestet. Damit wird gemessen, wie viel Zeit zwischen der Anfrage eines Nutzers und des Beginns der Reaktion (Time to First Byte) und der Vollendung der Reaktion (Reaktionszeit) vergeht. Ziel dieser Tests ist es, die Performance aus Perspektive des Endnutzers zu messen.

In diesem Blog wird dargelegt, warum die Performance für jedes dieser Produkte von Bedeutung ist. Wir werden einen tiefen Einblick in die Messungen geben, um zu zeigen, dass wir schneller sind. Außerdem erläutern wird, wie die Performance für jedes Produkt ermittelt wurde.

Die Performance ist von Bedeutung, weil sie sich auf die Nutzererfahrungen Ihrer Mitarbeitenden und deren Fähigkeit auswirkt, ihre Aufgaben zu erledigen. Ob es sich um den Zugriff auf Dienste über Produkte zur Zugangskontrolle, die Verbindung mit dem öffentlichen Internet über ein Secure Web Gateway oder den Schutz vor risikobehafteten externen Websites mittels Remote-Browserisolierung handelt – all dies muss reibungslos funktionieren.

Nehmen wir an, Anna von der Acme Corporation stellt für ihre Arbeit von Sydney aus eine Verbindung zu Microsoft 365 oder Teams her. Wenn sich das Secure Web Gateway von Acme weit entfernt von Anna in Singapur befindet, kann es sein, dass Annas Datenverkehr von Sydney nach Singapur und dann zurück nach Sydney geleitet wird, bis er ihr E-Mail-Postfach erreicht. Wenn die Acme Corporation so verfährt wie viele andere Unternehmen, verlangt sie von Anna, Microsoft Outlook im Online-Modus zu verwenden. Das kann eine quälend schlechte Performance in der Zeit zur Folge haben, in der sie auf das Senden und Empfangen ihrer E-Mails wartet. Microsoft 365 empfiehlt, die Latenz so gering und die Bandbreite so hoch wie möglich zu halten. Der zusätzliche Hop, den Anna durch ihr Gateway nehmen muss, könnte den Durchsatz verringern und die Latenz erhöhen, was Annas Nutzererlebnis beeinträchtigen würde.

Ein anderes Beispiel: Wenn Anna eine Verbindung zu einer gehosteten und geschützten Anwendung wie Jira herstellt, um einige Tickets abzuschließen, möchte sie nicht ständig auf das Laden von Seiten oder die Authentifizierung ihrer Anfragen warten müssen. Bei einer Anwendung mit Zugangskontrolle ist der erste Schritt, sich einzuloggen. Wenn das lange dauert, werden Sie vielleicht durch irgendeine Nachricht eines Kollegen abgelenkt oder Sie wollen sich womöglich gar nicht erst mit der Aufgabe befassen. Und selbst wenn Sie sich authentifiziert haben, wollen Sie immer noch, dass Ihre normale Anwendung schnell und reibungslos funktioniert: Im Idealfall sollten Nutzer gar nicht bemerken, dass ein Zero Trust-Modell angewandt wird.

Wenn diese Produkte langsam arbeiten oder Nutzererfahrungen beeinträchtigt werden, könnte Schlimmeres passieren, als dass sich die Nutzer beschweren: Sie könnten Wege finden, die Produkte auszuschalten oder zu umgehen, was das Unternehmen einer Gefahr aussetzt. Zero Trust-Produkte sind völlig nutzlos, wenn niemand sie verwendet, weil sie zu langsam sind. Die Schnelligkeit von Zero Trust-Lösungen ist entscheidend für ihre Effektivität: Mitarbeitende werden sie nicht abschalten wollen und sich selbst einem Risiko aussetzen, wenn sie ihr Vorhandensein praktisch nicht bemerken.

Dienste wie Zscaler übertreffen zwar viele ältere – um nicht zu sagen: veraltete – Lösungen, ihr Netzwerk kann sich aber trotzdem nicht mit einem hochleistungsfähigen und optimierten Netzwerk wie dem von Cloudflare messen. Wir haben alle unsere Zero Trust-Produkte im Test gegen die von Zscaler antreten lassen und werden Ihnen demonstrieren, dass wir schneller sind. Nun schauen wir uns genauer an, wie und warum wir in drei kritischen Zero Trust-Szenarien eine höhere Geschwindigkeit erreichen. Wir beginnen mit dem Secure Web Gateway: Cloudflare Gateway und Zscaler Internet Access (ZIA) im Vergleich.

Ein Secure Web Gateway muss schnell sein, da es als Trichter für den gesamten Internetdatenverkehr eines Unternehmens fungiert. Ist ein Secure Web Gateway langsam, so gilt das auch für den für das Internet bestimmten Nutzer-Traffic. Wenn das der Fall ist, werden die Nutzer unter Umständen aufgefordert, das Gateway auszuschalten, wodurch das Unternehmen dem Risiko eines Angriffs ausgesetzt ist.

Ein leistungsfähiges Web Gateway muss sich also in der Nähe der Nutzer befinden. Darüber hinaus muss es aber auch mit dem Rest des Internet gut vernetzt sein, um langsame Routen zu den von den Nutzern angesteuerten Websites zu vermeiden. Schließlich folgt der über ein Secure Web laufende Datenverkehr einem Forward-Proxy-Pfad: Die Nutzer stellen eine Verbindung zum Proxy her und der Proxy stellt eine Verbindung zu den Websites her, auf die zugegriffen werden soll. Deshalb ist es wichtig, dass der Proxy gut angebunden ist, damit der Nutzer-Traffic so schnell wie möglich sein Ziel erreichen kann.

Beim Vergleich von Secure Web Gateway-Produkten haben wir das Gateway und den WARP-Client von Cloudflare mit dem Produkt Zscaler Internet Access (ZIA) verglichen, das die gleichen Funktionen bietet. Zum Glück für Cloudflare-Nutzer sind Gateway und unser Netzwerk tief in die Netzwerke der letzten Meile in der Nähe der User eingebettet. Zudem zählt unser Netzwerk zu denen mit den meisten Verknüpfungen der Welt. Das erlaubt es uns, bei Gateway-Nutzerszenarien 55 Prozent schneller zu sein als ZIA. Unten sehen Sie einen Box-Plot, der die Reaktionszeiten für Cloudflare, Zscaler und eine Kontrollgruppe, die überhaupt kein Gateway verwendet, im 95. Perzentil zeigt:

Secure Web Gateway – Reaktionszeit

95. Perzentil (ms)

Kontrolle

142,22

Cloudflare

163,77

Zscaler

365,77

Diese Daten zeigen, dass Cloudflare bei Gateway-Szenarien weitaus schneller ist als Zscaler. Tatsächlich wird daran deutlich, dass die Nutzung von Cloudflare eher der Erfahrung ähnelt, überhaupt kein Secure Web Gateway zu verwenden, als dies bei Zscaler der Fall ist.

Um die Gateway-Erfahrung des Endnutzers am besten zu messen, betrachten wir die Reaktionszeit für den Endnutzer im 95. Perzentil: Wir messen, wie lange es dauert, bis eine Nutzeranfrage über den Proxy an eine Website im Internet gestellt wird und eine Reaktion zurückkommt. Diese Messung ist wichtig, weil sie ein genaues Abbild dessen ist, was die Nutzer erleben.

Beim Vergleich mit Zscaler haben wir unseren Endnutzer-Client versuchen lassen, auf fünf verschiedene Websites zuzugreifen: auf eine bei Azure gehostete Website, einen durch Cloudflare geschützten Worker, Google, Slack und Zoom – also Websites, die Nutzer regelmäßig aufrufen. In jedem dieser Fälle hat Cloudflare die Performance von Zscaler übertroffen. Im Fall des von Cloudflare geschützten Workers hat Gateway sogar den 95. Perzentil-Kontrollwert übertroffen. Hier ist ein Box-Plot, der die Reaktionen im 95. Perzentil aufgeschlüsselt nach den verschiedenen Endpunkten zeigt, bei denen wir im Rahmen unserer Tests eine Abfrage durchgeführt haben:

Unabhängig davon, wo man sich im Internet bewegt, übertrifft Cloudflare Gateway die Lösung Zscaler Internet Access (ZIA), wenn man die Ende-zu-Ende-Reaktionszeiten betrachtet. Doch warum sind wir so viel schneller als Zscaler? Die Antwort hat mit etwas zu tun, das Zscaler als Proxy-Latenz bezeichnet.

Die Proxy-Latenz ist die Zeit, die eine Nutzeranfrage auf einem Zscaler-Rechner verbringt, bevor sie an ihr Ziel und zurück an den Nutzer gesendet wird. Dies klammert sowohl die Zeit, die ein Nutzer zum Erreichen von Zscaler benötigt, als auch die Zeit, die Zscaler zum Erreichen des Ziels benötigt, vollständig aus und beschränkt die Messung auf die Millisekunden, die Zscaler für die Bearbeitung von Anfragen benötigt.

Der Latenz-SLA von Zscaler besagt, dass 95 Prozent Ihrer Anfragen weniger als 100 ms auf einem Zscaler-Gerät verbringen werden. Zscaler verspricht, dass die Latenz, die der Anbieter an seinem Edge-Gerät messen kann, für 95 Prozent der Nutzeranfragen 100 ms oder weniger betragen wird. Doch dabei handelt es sich nicht um die Ende-zu-Ende-Latenz, die tatsächlich von Bedeutung ist. Sie können diese Metriken sogar in der Digital Experience von Zscaler sehen und selbst messen. Wenn man diese Proxy-Latenz aus den Zscaler-Protokollen abruft und sie mit dem Cloudflare-Gegenstück vergleicht, sieht man, wie wir im Vergleich zu den SLA-Metriken von Zscaler abschneiden. Wir stellen diese Messwerte den Kunden zwar noch nicht zur Verfügung, doch wir konnten bei Cloudflare die Rückverfolgung aktivieren, um unsere Proxy-Latenz zu messen.

Dabei ergab sich, dass Zscaler beim 95. Perzentil die SLA-Vorgabe überschritten und die Proxy-Latenz von Cloudflare 7 ms betragen hat. Als sich unsere Proxy-Latenz auf 100 ms beziffert hat (was der SLA-Vorgabe von Zscaler entspricht), waren zudem die Proxy-Latenzen von Zscaler mehr als zehn Mal so hoch wie unsere. Die Proxy-Latenz von Zscaler ist für den Performance-Unterschied verantwortlich, den wir beim 95. Perzentil festgestellt haben; die Geschwindigkeit war für jeden Standort 140–240 ms geringer als bei Cloudflare. Hier sehen Sie die Werte der Proxy-Latenz von Zscaler bei verschiedenen Perzentilen für alle getesteten Standorte und dann aufgeschlüsselt nach den einzelnen Standorten:

Zscaler Internet Access (ZIA)

P90-Proxy-Latenz (ms)

P95-Proxy-Latenz (ms)

P99-Proxy-Latenz (ms)

P99,9-Proxy-Latenz (ms)

P99,957-Proxy-Latenz (ms)

Weltweit

06.0

142,0

625,0

1.071,7

1.383,7

Azure-Website

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-Website

97,8

184,1

468,3

1.246,2

1.288,6

Google

13,7

100,8

392,6

848,9

1.115,0

Beim 95. Perzentil lagen also die Proxy-Latenzen außerhalb der SLA-Vorgaben. Außerdem zeigen diese Werte den Unterschied zwischen Zscaler und Cloudflare: Bei Zoom zum Beispiel wäre Zscaler ohne die Proxy-Latenz auf dem gleichen Stand wie Cloudflare und die Kontrollgruppe. Das Äquivalent der Proxy-Latenz von Cloudflare ist so niedrig, dass die Nutzung von Cloudflare mit der Nutzung des öffentlichen Internets vergleichbar ist:

Cloudflare Gateway

P90-Proxy-Latenz (ms)

P95-Proxy-Latenz (ms)

P99-Proxy-Latenz (ms)

P99,9-Proxy-Latenz (ms)

P99,957-Proxy-Latenz (ms)

Weltweit

5,6

7,2

15,6

32,2

101,9

Azure-Website

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-Website

5,1

6,1

9,4

17,3

20,5

Google

5,3

7,4

12,0

26,9

30,2

Es mag auf ersten Blick überraschen, dass das 99,957. Perzentil aufgeführt wurde, bei dem die Proxy-Latenzen von Cloudflare schließlich 100 ms überschritten haben. Die 99,957. Perzentil-Proxy-Latenz von Cloudflare ist sogar geringer als die 90. Perzentil-Proxy-Latenz von Zscaler. Selbst bei der Kennzahl, die Zscaler wichtig ist und an der man sich bei dem Unternehmen misst, obwohl diese für Kunden gar nicht von Interesse ist, hat Cloudflare besser abgeschnitten.

Es war nicht einfach, diese Übersicht über die Daten zu bekommen. Bestehende Test-Frameworks wie Catchpoint sind für diese Aufgabe ungeeignet, da für Performance-Tests der ZIA-Client oder der WARP-Client auf dem Test-Endpunkt ausgeführt werden müssen. Außerdem mussten wir sicherstellen, dass der Cloudflare-Test und der Zscaler-Test auf ähnlichen Rechnern am gleichen Ort durchgeführt werden, um die Performance so genau wie möglich ermitteln zu können. Auf diese Weise können wir die Ende-zu-Ende-Reaktionen messen, die von demselben Ort kommen, an dem beide Testumgebungen ausgeführt werden:

In unserem Setup haben wir drei virtuelle Maschinen in der Cloud nebeneinander platziert: eine mit Cloudflare WARP, die eine Verbindung zu unserem Gateway herstellt, eine mit ZIA und eine ohne Proxy als Kontrolleinheit. Diese virtuellen Maschinen haben alle drei Minuten Anfragen an die fünf oben genannten Endpunkte gestellt und die HTTP-Browser-Zeiten für die Dauer jeder Anfrage protokolliert. So erhalten wir einen aussagekräftigen Überblick über die Performance aus Nutzerperspektive.

Fassen wir kurz den Zwischenstand zusammen: Cloudflare ist aus Sicht der Nutzer schneller als Zscaler, wenn diese mittels eines Secure Web Gateway vor dem öffentlichen Internet geschützt werden. Sogar nach der begrenzten Definition, die Zscaler auf Performance über ein Secure Web Gateway anwendet, hat Cloudflare die Nase vorn. Nun schauen wir uns aber einmal Szenarien an, in denen für bestimmte Anwendungen ein Zero Trust-Zugang genutzt werden muss.

Die Zugangskontrolle muss für den Nutzer nahtlos und transparent erfolgen: Das beste Kompliment für eine Zero Trust-Lösung ist, wenn die Mitarbeitenden ihr Vorhandensein kaum bemerken. Mit Diensten wie Cloudflare Access und Zscaler Private Access (ZPA) können Nutzer Authentifizierungsdaten im Netzwerk des Anbieters zwischenspeichern. So werden der sichere und schnelle Anwendungszugriff sowie die gewünschte reibungslose Nutzererfahrung gewährleistet. Ein Netzwerk, das die Anzahl der erforderlichen Logins minimiert und gleichzeitig die Latenz der Anwendungsanfragen senkt, trägt zur Aufrechterhaltung eines schnellen Interneterlebnisses bei.

Cloudflare Access ist 38 Prozent schneller als Zscaler Private Access (ZPA) und gewährleistet standortunabhängig ein schnelles und sicheres Anwendungserlebnis:

ZT Access – Time to First Byte (weltweit)

95. Perzentil (ms)

Cloudflare

849

Zscaler

1.361

Bei näherer Betrachtung der Daten erweist sich Cloudflare beständig überall auf der Welt als schneller. In Tokio beispielsweise ist die Time to First Byte im 95. Perzentil bei Cloudflare um 22 Prozent geringer als bei Zscaler:

Wird Cloudflare hinsichtlich Anwendungen mit Zscaler verglichen, haben wir es mit zwei unterschiedlichen Szenarien zu tun, die einzeln bewertet werden müssen. Das erste Szenario besteht darin, dass sich ein Nutzer bei seiner Anwendung anmeldet und sich authentifizieren muss. In diesem Fall leitet der Zero Trust Access-Dienst den Nutzer erst zu einer Login-Seite, wo sich der Nutzer authentifiziert, und dann zu seiner Applikation weiter.

Dies wird als „neue Sitzung“ bezeichnet, da Authentifizierungsinformationen weder zwischengespeichert werden noch im Access-Netzwerk vorhanden sind. Das zweite Szenario ist eine „bestehende Sitzung“: Ein Nutzer wurde bereits authentifiziert und diese Authentifizierungsdaten können zwischengespeichert werden. Bei diesem Szenario erfolgt die Abwicklung in der Regel sehr viel schneller, weil zum Abschluss des Vorgangs keine zusätzliche Anfrage bei einem Identitätsanbieter erforderlich ist.

Wir messen diese Szenarien gerne getrennt, da wir bei der Betrachtung der Werte für das 95. Perzentil fast immer neue Sitzungen ansehen würden, wenn wir neue und bestehende Sitzungen zusammenfassen. Doch bei beiden Szenarien ist Cloudflare in jeder Region durchweg schneller. So sehen diese Daten aus, wenn man einen Standort betrachtet, an dem Zscaler mit größerer Wahrscheinlichkeit über ein gutes Peering verfügt: Nutzer in Chicago (Illinois), die sich mit einer im Zentrum der USA gehosteten Anwendung verbinden.

ZT-Zugang – 95. Perzentil: Time to First Byte(Chicago)

Neue Sitzungen (ms)

Bestehende Sitzungen (ms)

Cloudflare

1.032

293

Zscaler

1.373

338

Auch hier ist Cloudflare insgesamt schneller. Es folgt ein Histogramm der Reaktionszeiten im 95. Perzentil für neue Verbindungen insgesamt:

Sie sehen, dass das Cloudflare-Netzwerk die Performance beim Login wirklich steigert, weil bei der Suche nach optimalen Pfaden zurück zu den Authentifizierungsanbietern für den Abruf der Anmeldedaten geholfen wird. In diesem Test benötigt Cloudflare nie mehr als 2,5 Sekunden für eine Login-Reaktion, aber die Hälfte der 95. Perzentil-Reaktionen von Zscaler nehmen fast doppelt so viel Zeit in Anspruch, nämlich etwa vier Sekunden. Dies könnte darauf hindeuten, dass das Netzwerk von Zscaler nicht so gut an andere Netzwerke angebunden ist, was schon früh zu Latenz führt. Es könnte aber auch ein Hinweis darauf sein, dass Zscaler besser abschneidet, wenn die Verbindung hergestellt ist und alles im Cache gespeichert ist. Doch auch bei einer bestehenden Verbindung hat Cloudflare die Nase vorn:

In niedrigeren Latenzbereichen sind die Unterschiede zwischen Zscaler und Cloudflare noch weniger stark ausgeprägt. Doch die Reaktionszeiten von Cloudflare sind viel einheitlicher und Sie können sehen, dass die Hälfte der Reaktionen von Zscaler zum Laden fast eine Sekunde benötigt. Dies unterstreicht, wie gut wir vernetzt sind: Wir bieten eine bessere Anwendungserfahrung und haben nicht so viele Edge-Fälle mit hohen Latenzen und schlechter Applikationsperformance, weil wir an mehr Orten präsent sind.

Wir möchten neue und bestehende Sitzungen getrennt voneinander betrachten, weil es für einen aussagekräftigen Vergleich wichtig ist, ähnliche Anfragepfade heranzuziehen. Wenn beispielsweise eine Anfrage über Zscaler in einer bestehenden Sitzung mit einer Anfrage über Cloudflare in einer neuen Sitzung gegenübergestellt wird, ist festzustellen, dass Cloudflare aufgrund der erforderlichen Authentifizierung viel langsamer ist als Zscaler. Daher haben wir bei der Beauftragung einer externen Stelle mit der Durchführung dieser Tests sichergestellt, dass dieser Aspekt berücksichtigt wurde.

Wir haben uns dafür an die Firma Miercom gewandt. Diese hat eine Reihe von Tests durchgeführt, die einen Endnutzer nachempfinden sollten, der sich mit einer von Cloudflare oder Zscaler geschützten Ressource verbindet. Miercom richtete Anwendungsinstanzen an vierzehn Standorten auf der ganzen Welt ein und entwickelte einen Test, bei dem sich der Nutzer über verschiedene Zero Trust-Anbieter in die Anwendung einloggen musste, um auf bestimmte Inhalte zuzugreifen. Die Testmethodik wird im Folgenden beschrieben. Den vollständigen Bericht von Miercom mit einer detaillierten Beschreibung der Testmethodik können Sie hier (auf Englisch) abrufen:

• Über einen Browser, der von einer Catchpoint-Instanz nachgeahmt wird, verbindet sich der Nutzer mit der Anwendung – neue Sitzung

• Der Nutzer authentifiziert sich gegenüber seinem Identitätsanbieter

• Der Nutzer greift auf die Ressource zu

• Der Nutzer aktualisiert die Browserseite und versucht, auf dieselbe Ressource zuzugreifen, jedoch mit bereits vorhandenen Anmeldedaten – bestehende Sitzung

So können wir die Anwendungperformance mit Cloudflare und Zscaler sowohl für neue als auch für bestehende Sitzungen vergleichen, und dabei hat sich wie bereits erwähnt gezeigt, dass wir schneller sind. Doch auch bei Secure Web Gateway-Szenarien schlagen wir Zscaler.

Sowohl Secure Web Gateway- als auch Zero Trust-Zugangsszenarien können durch Remote-Browserisolierung (RBI) weiter abgesichert werden. Diese bietet eine clientlose Methode, um sowohl den Zugriff auf Daten innerhalb einer Anwendung zu schützen als auch Bedrohungen bei der Verwendung von Ressourcen im öffentlichen Internet abzuwehren.

Produkte zur Remote-Browserisolierung sind sehr stark vom öffentlichen Internet abhängig: Wenn die Verbindung zum Browserisolierungsprodukt schlecht ist, beeinträchtigt das die Nutzererfahrung, unter anderem aufgrund längerer Ladezeiten. Um für den Nutzer reibungs- und nahtlos funktionieren zu können, ist die Remote-Browserisolierung außerordentlich Performance-abhängig: Wenn alles so schnell ist, wie es sein sollte, dann sollten die Nutzer nicht einmal bemerken, dass Browserisolierung verwendet wird. In diesem Test vergleichen wir die Cloudflare Browser Isolation mit der Zscaler Cloud Browser Isolation.

Wie sich zeigt, liegt Cloudflare auch hier vorn. Vergleicht man die Time to First Byte im 95. Perzentil, ist Cloudflare in allen Regionen 45 Prozent schneller als Zscaler.

ZT RBI – Time to First Byte (weltweit)

95. Perzentil (ms)

Cloudflare

2.072

Zscaler

3.781

Auch wenn man die gesamte Reaktionszeit oder die Fähigkeit eines Browserisolierungsprodukts, eine vollständige Antwort an einen Nutzer zu liefern, vergleicht, ist Cloudflare immer noch 39 Prozent schneller als Zscaler:

ZT RBI – Time to First Byte (weltweit)

95. Perzentil (ms)

Cloudflare

2.394

Zscaler

3.932

Das Netzwerk von Cloudflare kann hier wirklich glänzen und unseren Kunden das beste Nutzererlebnis bieten. Weil es in unmittelbarer Nähe der Endnutzergeräte unglaublich gut ausgebaut ist, können wir die Time to First Byte und die Reaktionszeiten reduzieren und so die Erfahrung der Endnutzer verbessern.

Um dies zu messen und die benötigten Daten zu erhalten, haben wir uns nochmals an Miercom gewandt. Dazu haben wir Catchpoint-Knoten mit Cloudflare Browser Isolation und Zscaler Cloud Browser Isolation in der ganzen Welt von denselben 14 Standorten aus verbunden und Clients simulierende Geräte versuchen lassen, Anwendungen über die Browser-Isolierungsprodukte an jedem Standort zu erreichen. Weitere Informationen zur Testmethodik finden Sie in demselben Miercom-Bericht, der hier verlinkt ist.

In einer Welt ohne Zero Trust waren Sie und Ihre IT-Abteilungen die Betreiber des Netzwerks, sodass sie die Performance kontrollieren konnten. Diese Kontrolle war zwar beruhigend, stellte aber auch eine große Belastung für Ihre IT-Mitarbeitenden dar, die die Verbindungen zwischen den Büros und Ressourcen auf der mittleren Meile verwalten mussten. In einer Zero Trust-Welt fungiert nun aber das öffentliche Internet als Ihr Netzwerk. Das bedeutet weniger Arbeit für Ihre Teams – aber viel mehr Verantwortung für Ihren Zero Trust-Anbieter, der die Performance für jeden einzelnen Ihrer Nutzer verwalten muss. Je stärker Ihr Zero Trust-Anbieter die Ende-zu-Ende-Performance steigert, desto besser ist das Erlebnis für Ihre Nutzer und desto geringer ist das Risiko, dem Sie sich aussetzen. Für Echtzeitanwendungen wie Authentifizierung und Secure Web Gateways ist ein schnelles Nutzererlebnis entscheidend.

Ein Zero Trust-Anbieter muss nicht nur Ihre Nutzer im öffentlichen Internet absichern, sondern dieses auch optimieren, um ihren kontinuierlichen Schutz zu gewährleisten. Die Umstellung auf Zero Trust reduziert nicht nur den Bedarf an Unternehmensnetzwerken, sondern ermöglicht auch einen natürlicheren Fluss des Nutzer-Traffics zu den Ressourcen. Ihr Zero Trust-Anbieter ist damit der Gatekeeper für alle Ihre Nutzer und Anwendungen. Deshalb ist die Performance ein wichtiger Aspekt, den es zu bewerten gilt, um Reibungsverluste für Ihre Nutzer zu reduzieren und die Wahrscheinlichkeit zu verringern, dass sich die Nutzer beschweren, weniger produktiv sind oder die Lösungen abschalten. Um für die bestmögliche Nutzererfahrung zu sorgen, verbessern wir das Cloudflare-Netzwerk ständig – nicht nur durch das Beheben von Routingproblemen, sondern auch durch die Erweiterung von Peering-Vereinbarungen und das Hinzufügen neuer Standorte. Diese unermüdlichen Bemühungen sind es, die uns zum schnellsten Zero Trust-Anbieter machen.

Auf unserer Vergleichsseite finden Sie weitere Informationen darüber, wie die Netzwerkarchitektur von Cloudflare im Vergleich zu Zscaler abschneidet.