In diesem Blogbeitrag wird ein Forschungspapier von Cloudflare zusammengefasst, in dem die Ergebnisse einer Zusammenlegung von Verbindungen mittels ORIGIN Frames gemessen und prototypisiert wurden. Ursprünglich veröffentlicht wurde die Untersuchung während der [Internet Measurement Conference] (https://conferences.sigcomm.org/imc/2022/program/) von ACM.
Es wird einige Leserinnen und Leser vielleicht überraschen, dass ein Browser beim Aufruf einer einzigen Webseite unter Umständen Dutzende, manchmal sogar Hunderte von Internetverbindungen herstellt. Nehmen wir beispielsweise diesen Blogbeitrag. Wenn Sie den Cloudflare-Blog zum ersten Mal aufrufen oder Ihr letzter Besuch schon eine Weile her ist, stellt Ihr Browser zur Darstellung der Seite mehrere Verbindungen her. Er führt zunächst DNS-Abfragen durch, um die zu blog.cloudflare.com gehörenden IP-Adressen zu ermitteln. Anschließend stellt er weitere Anfragen zur Anforderung aller untergeordneten Ressourcen auf der Webseite, die für die erfolgreiche Darstellung der gesamten Seite benötigt werden. Wie viele das sind? Zum Zeitpunkt des Redaktionsschlusses werden 32 Hostnamen zum Laden des Cloudflare-Blogs verwendet. Das bedeutet 32 DNS-Abfragen und mindestens 32 TCP- (oder QUIC-)Verbindungen – es sei denn, der Client ist in der Lage, einige dieser Verbindungen wiederzuverwenden (bzw. zusammenzulegen).
Die einzelnen neuen Internetverbindungen beanspruchen die Verarbeitungskapazitäten eines Servers zusätzlich, was in Spitzenzeiten die Skalierbarkeit beeinträchtigen kann. Darüber hinaus werden dabei Client-Metadaten an das Netzwerk weitergegeben, z. B. die Hostnamen, auf die jemand zugreift, im Klartext. Solche Metadaten geben Angreifern und Lauschern im Netzwerk unter Umständen Aufschluss über die Online-Aktivitäten und das Surfverhalten eines Nutzers.
In diesem Blogbeitrag werden wir uns eingehender mit dem sogenannten „Connection Coalescing“ (Zusammenlegen von Verbindungen) beschäftigen. Wir haben uns erstmals im Jahr 2021 mit IP-basiertem Coalescing befasst. Seitdem haben wir weitere groß angelegte Messungen und Modellierungen im gesamten Internet durchgeführt, um verstehen und vorhersagen zu können, ob und wo Coalescing am besten funktionieren würde. Da sich IP Coalescing in großem Maßstab nur schwer handhaben lässt, haben wir im vergangenen Jahr einen vielversprechenden Standard namens HTTP/2 ORIGIN Frame Extension implementiert und damit Experimente durchgeführt. Auf diese Weise konnten wir Verbindungen zu unserer Edge zusammenlegen, ohne uns über die Verwaltung von IP-Adressen Gedanken machen zu müssen.
Unter dem Strich liegen hier Chancen, die von vielen großen Anbietern nicht wahrgenommen werden. Wir hoffen, dass dieser Blogbeitrag (und der von uns auf der IMC von ACM im Jahr 2022 veröffentlichte ausführliche Bericht) den ersten Schritt aufzeigt, um Servern und Clients dabei zu helfen, sich die Vorteile des ORIGIN Frame-Standards zunutze zu machen.
Grundlagen
Wenn ein Nutzer im Web surft, ruft der Browser zum Aufbau der vollständigen Seite abhängige untergeordnete Ressourcen ab. Dieses Verfahren hat große Ähnlichkeit mit der Montage bzw. dem Zusammenbau eines Produkts in einer Fabrik. In diesem Sinne kann eine moderne Webseite als eine Art Montagewerk betrachtet werden. Sie greift auf eine „Lieferkette“ von Ressourcen zurück, die für die Herstellung des Endprodukts benötigt werden.
Ein Montagewerk kann im Rahmen einer einzigen Bestellung verschiedene Teile unterschiedlicher Hersteller und aus unterschiedlichen Herkunftsorten ordern und diese in einer einzigen Lieferung beziehen (ähnlich wie bei der Praxis des Kitting, mit der die Wertschöpfung maximiert und die Reaktionszeit minimiert wird). Alles, was dafür benötigt wird, ist eine „Verbindung“ zum Lieferanten: Jeder einzelne Lkw, der von einem Lieferanten zu einem Montagewerk fährt, kann mit Teilen von verschiedenen Herstellern beladen werden.
Die Struktur des Webs bringt es jedoch mit sich, dass die Browser in der Regel das Gegenteil tun. Um Bilder, JavaScript-Code und andere Ressourcen (die Einzelteile) auf einer Webseite abzurufen, müssen Web-Clients (Montagewerke) mindestens eine Verbindung zu jedem im HTML-Code definierten Hostnamen (den Herstellern) aufbauen, der vom Server (dem Lieferanten) übermittelt wird. Dabei spielt es keine Rolle, ob die Verbindungen zu diesen Hostnamen an denselben Server gehen oder nicht, sie könnten z. B. auch an einen Reverse Proxy wie Cloudflare geleitet werden. Das ist so, als ob für jeden Hersteller ein „neuer“ Lkw erforderlich wäre, um die Materialien vom selben Lieferanten zum Montagewerk zu transportieren: Es muss also eine neue Verbindung hergestellt werden, um eine untergeordnete Ressource von einem Hostnamen auf derselben Webseite anzufordern.
Es kann eine erstaunliche hohe Zahl von Verbindungen erfordern, eine Webseite vollständig zu laden. Außerdem benötigen die untergeordneten Ressourcen selbst wiederum häufig noch weiter untergeordnete Ressourcen, weshalb neue Verbindungen aus früheren entstehen. Zu bedenken ist auch, dass HTTP-Verbindungen zu Hostnamen oft DNS-Abfragen vorausgehen. Durch das Zusammenlegen von Verbindungen kann deren Anzahl reduziert werden. Anders gesagt können dieselben Lkw für den Transport von Teilen mehrerer Hersteller von einem einzigen Lieferanten „wiederverwendet“ werden.
Das grundlegende Prinzip bei der Zusammenlegung von Verbindungen
Die Zusammenlegung von Verbindungen (Coalescing) wurde bei HTTP/2 eingeführt und bei HTTP/3 übernommen. Wir haben bereits in einem früheren Blogbeitrag über das Coalescing berichtet (für eine ausführliche Einführung empfehlen wir die Lektüre dieses Beitrags). Die Grundidee ist einfach, aber ihre Umsetzung kann eine Reihe von technischen Herausforderungen mit sich bringen. Man muss sich zum Beispiel vor Augen führen, dass es (zum Zeitpunkt des Verfassens dieses Artikels) zum Laden dieser Webseite 32 Hostnamen gibt. Darunter befinden sich 16 eindeutige Domains (definiert als „Effektive TLD+1“). Können wir dafür sorgen, dass jede eindeutige Domain weniger Verbindungen herstellt oder bestehende Verbindungen „zusammengelegt“ werden? Die Antwort lautet „Grundsätzlich schon, aber nur unter bestimmten Voraussetzungen.“
Die genaue Anzahl der zum Laden der Blogseite erforderlichen Verbindungen lässt sich nur schwer bestimmen. Es kann sein, dass 32 Hostnamen mit 16 Domains verbunden sind. Das heißt aber nicht zwangsläufig, dass es auch 16 eindeutige Verbindungen gibt. Tatsächlich könnte es auch nur eine einzige Verbindung sein, wenn alle Hostnamen über einen einzigen Server erreichbar sind. Möglich wären aber auch bis zu 32 unabhängige Verbindungen, wenn für den Zugriff auf jeden einzelnen Hostnamen ein anderer und separater Server erforderlich ist.
Die Wiederverwendung von Verbindungen kann auf vielerlei Weise erfolgen. Deshalb ist es wichtig, dieses „Connection Coalescing“ im HTTP-Bereich genauer zu definieren. Wird beispielsweise eine bestehende TCP- oder TLS-Verbindung zu einem Hostnamen wiederverwendet, um mehrere Anfragen für untergeordnete Ressourcen an desselben Hostnamen zu stellen, handelt sich dabei zwar um eine Wiederverwendung von Verbindungen, aber nicht um Coalescing.
Von Coalescing spricht man, wenn ein bestehender TLS-Kanal für einen bestimmten Hostnamen wiederverwendet oder für eine Verbindung zu einem anderen Hostnamen genutzt werden kann. Beim Aufruf von blog.cloudflare.com beispielsweise verweist der HTML-Code auf die untergeordneten Ressourcen von cdnjs.cloudflare.com. Um dieselbe TLS-Verbindung für die untergeordneten Ressourcen zu verwenden, müssen beide Hostnamen zusammen in der Liste „Server Alternative Name (SAN)“ des TLS-Zertifikats erscheinen. Schließlich kann der Dienst cdnjs.cloudflare.com über denselben Server wie blog.cloudflare.com erreichbar sein oder auch nicht, obwohl er auf demselben Zertifikat steht. Woher soll der Browser das also wissen? Coalescing funktioniert nur, wenn die Server die richtigen Bedingungen schaffen. Doch es sind die Clients, die entscheiden müssen, ob Coalescing erfolgen soll oder nicht. Darum benötigen Browser ein Signal für das Coalescing, das über die SAN-Liste im Zertifikat hinausgeht. Um unsere Analogie wieder aufzugreifen: Das Montagewerk kann ein Teil direkt bei einem Hersteller ordern, ohne zu wissen, dass der Lieferant das gleiche Teil bereits in seinem Lager vorrätig hat.
Es gibt zwei explizite Signale, anhand derer ein Browser entscheiden kann, ob Verbindungen zusammengeführt werden können: Eines ist IP-basiert, das andere ORIGIN Frame-basiert. Das erste erfordert von den Serverbetreibern eine enge Bindung der DNS-Einträge an die auf dem Server verfügbaren HTTP-Ressourcen. Das ist schwer zu verwalten und zu implementieren und schafft eine riskante Abhängigkeit, da man alle Ressourcen hinter einem bestimmten Satz von IP-Adressen oder einer einzigen IP-Adresse platzieren muss. Die Art und Weise, wie IP-Adressen Entscheidungen über die Zusammenführung beeinflussen, variiert je nach Browser: Einige sind restriktiver, andere gewähren größeren Spielraum. Alternativ dazu ist der HTTP ORIGIN Frame ein einfacheres Signal für die Server, das darüber hinaus flexibel ist und bei Ausfall keine Unterbrechung des Dienstes verursacht (für eine spezifikationskonforme Implementierung).
Ein grundlegender Unterschied zwischen diesen beiden Coalescing-Signalen besteht darin, dass IP-basierte Signale implizit und sogar zufällig sind. Sie zwingen Clients dazu, Rückschlüsse hinsichtlich Coalescing-Möglichkeiten zu ziehen, die möglicherweise bestehen oder auch nicht. Das ist nicht weiter verwunderlich, weil IP-Adressen so konzipiert sind, dass sie keine echte Beziehung zu Namen haben. Im Gegensatz dazu handelt es sich bei ORIGIN Frame um ein explizites Signal von Servern an Clients, dass Coalescing möglich ist – unabhängig davon, was das DNS für einen bestimmten Hostnamen angibt.
Wir haben bereits mit IP-basiertem Coalescing experimentiert. In diesem Blogbeitrag wollen wir uns näher mit dem ORIGIN Frame-basierten Coalescing befassen.
Was verbirgt sich hinter dem ORIGIN Frame-Standard?
Bei ORIGIN Frame handelt es sich um eine Erweiterung der HTTP/2- und HTTP/3-Spezifikation. Dieser spezielle Frame wird auf Stream 0 bzw. dem Kontrollstream der Verbindung gesendet. Der Frame ermöglicht es den Servern, den Clients bei einer bestehenden TLS-Verbindung ein „Origin-Set“ zu senden. Dieses enthält Hostnamen, für die es autorisiert ist und die keine HTTP-421-Fehler verursachen werden. Die Hostnamen im „Origin Set“ müssen auch in der SAN-Zertifikatsliste des Servers erscheinen, selbst wenn sie über das DNS auf verschiedenen IP-Adressen angekündigt werden.
Konkret sind zwei Schritte erforderlich:
- Webserver müssen eine Liste mit dem „Origin Set“ (den Hostnamen, für die eine bestimmte Verbindung verwendet werden könnte) in der ORIGIN Frame-Erweiterung übermitteln.
- Das vom Webserver zurückgesendete TLS-Zertifikat muss die zusätzlichen Hostnamen abdecken, die im ORIGIN Frame in den DNS-Namen-SAN-Einträgen rückübermittelt werden.
Auf einer hohen Ebene stellen ORIGIN Frames eine Ergänzung zum TLS-Zertifikat dar, die von Betreiber angehängt werden können, um dem Client die Namen in den SANs zu nennen, die auf dieser Verbindung verfügbar sind und zusammengeführt werden können. Da der ORIGIN Frame nicht Teil des eigentlichen Zertifikats ist, kann sein Inhalt auch unabhängig geändert werden. Ein neues Zertifikat ist nicht erforderlich und es besteht auch keine Abhängigkeit von IP-Adressen. Bei einem Coalescing-fähigen Hostnamen können bestehende TCP/QUIC+TLS-Verbindungen wiederverwendet werden, ohne dass neue Verbindungen oder DNS-Abfragen erforderlich sind.
Viele Websites sind heute auf Inhalte angewiesen, die von CDNs wie dem von Cloudflare bereitgestellt werden. Die Nutzung externer CDN-Dienste hat für Websites den Vorteil, dass sie schneller und zuverlässiger sind und die Last der von ihren Ursprungsservern bereitgestellten Inhalte verringert wird. Werden sowohl die Website als auch die Ressourcen von ein und demselben CDN bereitgestellt, obwohl es sich um unterschiedliche Hostnamen im Besitz verschiedener Unternehmen handelt, eröffnet das den CDN-Betreibern einige sehr interessante Möglichkeiten, um die Wiederverwendung und Zusammenführung von Verbindungen zu ermöglichen: Sie können sowohl die Zertifikatsverwaltung als auch die Verbindungsanfragen für das Senden von ORIGIN Frames im Namen des tatsächlichen Ursprungsservers kontrollieren.
Leider gab es bisher keine Möglichkeit, die von ORIGIN Frame gebotenen Optionen in der Praxis zu nutzen. Soweit wir wissen, existiert bislang keine Server-Implementierung, die ORIGIN Frames unterstützt. Was Browser angeht, unterstützt nur Firefox ORIGIN Frames. Da das IP Coalescing eine Herausforderung darstellt und ORIGIN Frame nicht unterstützt wird, stellt sich die Frage, ob sich die Zeit und Energie für eine bessere Unterstützung des Coalescing lohnt. Wir haben beschlossen, das mit einer groß angelegten internetweiten Messung herauszufinden. Auf diesem Weg wollten wir in Erfahrung bringen, welche Chancen und Möglichkeiten das Verfahren eventuell bietet. Anschließend haben wir ORIGIN Frame implementiert, um mit dem Produktionstraffic zu experimentieren.
Experiment Nr. 1: Welche Größenordnung haben die erforderlichen Änderungen?
Im Februar 2021 haben wir eine Datenerhebung für 500.000 der beliebtesten Websites im Internet mit einem modifizierten Web Page Test auf 100 virtuellen Maschinen durchgeführt. Bei jedem Besuch einer Webseite wurde eine automatisierte Instanz des Browsers Chrome (v88) gestartet, um Zwischenspeichereffekte auszuschließen (weil uns nicht das Caching, sondern das Coalescing interessierte). Nach erfolgreichem Abschluss jeder Sitzung wurden die Chrome-Entwicklertools verwendet, um die Daten zum Laden der Seite abzurufen und als Datei im HTTP-Archivformat (HAR) mit einer vollständigen Zeitleiste der Ereignisse sowie zusätzlichen Informationen über die Zertifikate und ihre Validierung zu schreiben. Darüber hinaus haben wir die Zertifikatsketten für die Root-Webseite und neue TLS-Verbindungen analysiert, die durch Anforderungen von untergeordneten Ressourcen ausgelöst wurden, um (i) Zertifikatsaussteller für die Hostnamen zu ermitteln, (ii) das Vorhandensein der Subject Alternative Name (SAN)-Erweiterung zu prüfen und (iii) zu validieren, dass DNS-Namen zur verwendeten IP-Adresse aufgelöst werden. Weitere Einzelheiten zu unserer Methodik und unseren Ergebnissen finden Sie in dem zugehörigen Technical Paper.
Der erste Schritt bestand darin, zu verstehen, welche Ressourcen von Webseiten zum erfolgreichen Rendern der Inhalte angefordert werden und wo diese Ressourcen im Internet zu finden sind. Die Zusammenführung von Verbindungen wird möglich, wenn die Domains der untergeordneten Ressourcen idealerweise an einem Ort liegen. Wir haben den ungefähren Standort einer Domain bestimmt, indem wir das entsprechende autonome System (AS) ermittelt haben. So ist beispielsweise die Domain cdnjs in der BGP-Routing-Tabelle über AS 13335 erreichbar und diese AS-Nummer gehört zu Cloudflare. Die folgende Abbildung zeigt den Prozentsatz der Webseiten und die Anzahl der eindeutigen AS, die zum vollständigen Laden einer Webseite erforderlich sind.
Etwa 14 % der Webseiten benötigen zwei AS, um vollständig geladen zu werden. Diese Seiten sind also von einem zusätzlichen AS für untergeordnete Ressourcen abhängig. Mehr als 50 % der Webseiten müssen nicht mehr als sechs AS kontaktieren, um alle erforderlichen untergeordneten Ressourcen zu erhalten. Dieses in der obenstehenden Grafik dargestellte Ergebnis deutet darauf hin, dass eine relativ kleine Anzahl von Betreibern die für die Mehrheit (rund 50 %) der Webseiten erforderlichen Inhalte untergeordneter Ressourcen bereitstellt und dass der Einsatz von ORIGIN Frames nur wenige Änderungen erfordern würde, um die beabsichtigte Wirkung zu erzielen. Das Potenzial für das Zusammenführen von Verbindungen kann daher optimistisch auf die Anzahl der eindeutigen AS, die zum Abrufen aller untergeordneten Ressourcen einer Webseite erforderlich sind, geschätzt werden. In der Praxis kann dies jedoch durch betriebliche Faktoren wie SLAs überlagert oder durch flexible Zuordnungen zwischen Sockets, Namen und IP-Adressen unterstützt werden, an denen wir zuvor bei Cloudflare gearbeitet haben.
Anschließend haben wir versucht, die Auswirkungen des Coalescings auf die Verbindungskennzahlen zu verstehen. Die gemessene und die ideale Anzahl der zum Laden einer Webseite erforderlichen DNS-Anfragen und TLS-Verbindungen wird in der folgenden Abbildung anhand ihrer CDFs zusammengefasst.
Mithilfe von Modellierung und umfassender Analyse haben wir festgestellt, dass mit dem Zusammenführen von Verbindungen durch ORIGIN Frames die Anzahl der von Browsern hergestellten DNS- und TLS-Verbindungen im Median um über 60 % reduziert werden könnte. Zur Durchführung dieser Modellierung haben wir die Anzahl der von den Clients angeforderten DNS-Einträge ermittelt und sie mit den idealen ORIGIN-Frames kombiniert.
Viele Multi-Origin-Server, wie sie von CDNs betrieben werden, neigen dazu, Zertifikate wiederzuverwenden und das gleiche Zertifikat mit mehreren DNS-SAN-Einträgen bereitzustellen. Das ermöglicht es den Betreibern, im Rahmen ihrer Erstellungs- und Erneuerungszyklen weniger Zertifikate zu verwalten. Theoretisch können zwar Millionen von Namen in einem Zertifikat enthalten sein, aber die Erstellung solcher Zertifikate ist unsinnig und erschwert eine effektive Verwaltung. Indem wir uns weiterhin auf bestehende Zertifikate stützen, machen unsere Modellierungsmessungen den Umfang der Änderungen deutlich, die zur Ermöglichung eines perfekten Zusammenlegens nötig sind. Gleichzeitig geben sie Aufschluss über das Ausmaß der erforderlichen Änderungen, wie in der folgenden Abbildung dargestellt.
Wir stellen fest, dass über 60 % der von Websites genutzten Zertifikate keine Änderungen benötigen und von ORIGIN Frames profitieren könnten. Bei unserer Messung waren wir in der Lage, mit gerade einmal zehn Ergänzungen zu den DNS-SAN-Namen in den Zertifikaten Verbindungen zu über 92 % der Websites erfolgreich zusammenzuführen. Die effektivsten Änderungen könnten von CDN-Anbietern vorgenommen werden, indem sie drei oder vier ihrer am häufigsten angeforderten Hostnamen in jedes Zertifikat aufnehmen.
Experiment Nr. 2: ORIGIN Frames in Aktion
Um unsere Modellierungserwartungen zu überprüfen, haben wir Anfang 2022 einen aktiveren Ansatz gewählt. Unser nächstes Experiment konzentrierte sich auf 5.000 Websites, die cdnjs.cloudflare.com als untergeordnete Ressource nutzen. Durch die Änderung unseres TLS-Versuchsendpunkts haben wir die im RFC-Standard definierte Unterstützung für HTTP/2 ORIGIN Frame eingeführt. Dazu mussten wir den internen Fork der net- und http-Abhängigkeitsmodule von Golang ändern, die wir quelloffen zur Verfügung gestellt haben (siehe hier und hier).
Während der Experimente wurde bei der Verbindung zu einer Website in der Versuchsgruppe cdnjs.cloudflare.com im ORIGIN Frame zurückübermittelt, während der Kontrollsatz einen beliebigen (ungenutzten) Hostnamen zurückübermittelte. Alle bestehenden Edge-Zertifikate für die 5.000 Websites wurden ebenfalls geändert. Für die Versuchsgruppe wurden die entsprechenden Zertifikate erneuert und cdnjs.cloudflare.com zum SAN hinzugefügt. Um die Integrität zwischen den Kontroll- und den Versuchsgruppen zu gewährleisten, wurden die Zertifikate für die Domains der Kontrollgruppe ebenfalls mit einer gültigen und gleich großen Drittanbieter-Domain erneuert, die von keiner der Kontrolldomains verwendet wird. Auf diese Weise wird sichergestellt, dass die relativen Größenänderungen der Zertifikate konstant gehalten werden, um mögliche Verzerrungen aufgrund unterschiedlicher Zertifikatsgrößen zu vermeiden. Unsere Ergebnisse waren beeindruckend.
Bei einer Stichprobe von 1 % der von uns ihm Rahmen des Experiments von Firefox erhaltenen Anfragen an die Websites stellten wir eine Verringerung der neuen TLS-Verbindungen pro Sekunde um über 50 % fest. Das deutet sowohl auf eine geringere Anzahl von kryptografischen Verifizierungsvorgängen auf Seite des Clients als auch auf einen geringeren Rechenaufwand auf Seite des Servers hin. Wie erwartet gab es keine Unterschiede in der Kontrollgruppe, was auf die Wirksamkeit der Wiederverwendung von Verbindungen aus Sicht der CDN- oder Serverbetreiber hinweist.
Diskussion und Erkenntnisse
Unsere Modellierungsmessungen hatten eine gewisse Performance-Steigerung erwarten lassen. Doch in der Praxis kam es nicht zu einer wesentlichen Verbesserung. Das legt nahe, dass hinsichtlich der Performance zumindest nicht mit einer Verschlechterung zu rechnen sein dürfte. Das subtile Zusammenspiel zwischen den Größen der Ressourcenobjekte, miteinander konkurrierenden Verbindungen und der Überlastungskontrolle ist von den Netzwerkbedingungen abhängig. Die Kapazität zur gemeinsamen Nutzung von Engpässen nimmt zum Beispiel ab, wenn weniger Verbindungen um die Engpassressourcen auf den Netzwerkverbindungen konkurrieren. Es wäre interessant, diese Messungen erneut durchzuführen und mit den früheren Ergebnissen zu vergleichen, wenn mehr Betreiber auf ihren Servern Unterstützung für ORIGIN Frames eingerichtet haben.
Abgesehen von der Performance liegt ein großer Vorteil von ORIGIN Frames im Datenschutz. Inwiefern? Jede zusammengelegte Verbindung verbirgt Client-Metadaten, die bei nicht zusammengeführten Verbindungen durchsickern würden. Bestimmte Ressourcen auf einer Webseite werden in Abhängigkeit davon geladen, wie man mit der Website interagiert. Somit werden bei jeder neuen Verbindung zum Abrufen einer Ressource vom Server TLS-Klartext-Metadaten wie SNI (in Abwesenheit von Encrypted Client Hello) und mindestens eine DNS-Abfrage im Klartext, wenn sie über UDP oder TCP an Port 53 übertragen wird, dem Netzwerk offengelegt werden. Durch das Zusammenführen von Verbindungen müssen die Browser keine neuen TLS-Verbindungen herstellen und keine zusätzlichen DNS-Abfragen durchführen. Dadurch wird verhindert, dass Metadaten von jemandem weitergegeben werden, der das Netzwerk ausspioniert. ORIGIN Frames tragen zur Minimierung dieser Signale aus dem Netzwerkpfad bei. Sie verbessern den Datenschutz, da sie die Menge der Klartextinformationen verringern, die auf dem Pfad an Lauscher im Netzwerk durchsickern.
Die Browser profitieren von der verringerten Menge an kryptografischen Berechnungen, die für die Überprüfung mehrerer Zertifikate erforderlich sind. Ein weiterer großer Vorteil besteht darin, dass sich sehr interessante künftige Möglichkeiten für die Ressourcenplanung an den Endpunkten (den Browsern und den Ursprungsservern) ergeben. Dazu zählen beispielsweise die Priorisierung oder neuere Konzepte wie HTTP Early Hints. So können Nutzererfahrungen geboten werden, bei denen die Verbindungen weder überlastet sind noch um diese Ressourcen konkurrieren. In Verbindung mit dem IETF-Entwurf für CERTIFICATE Frames können wir die Notwendigkeit manueller Zertifikatsänderungen weiter reduzieren, da ein Server seine Autorität bezüglich Hostnamen nach dem Verbindungsaufbau ohne zusätzliche SAN-Einträge im TLS-Zertifikat der Website nachweisen kann.
Schlussfolgerung und Handlungsaufforderung
Zusammenfassend lässt sich sagen, dass das derzeitige Internet-Ökosystem viele Möglichkeiten für das Zusammenlegen von Verbindungen mit nur wenigen Änderungen an Zertifikaten und ihrer Serverinfrastruktur bietet. Server können die Anzahl der TLS-Handshakes um etwa 50 % und die Anzahl der Rendering-Blockierungen bei DNS-Anfragen um über 60 % senken. Clientseitig wird zusätzlich in Form von höherem Datenschutz profitiert, da die Offenlegung von DNS-Klartextdaten im Netzwerk reduziert wird.
Um Fakten zu schaffen, planen wir derzeit, unseren Kunden künftig Unterstützung für HTTP/2 und HTTP/3 ORIGIN Frames zu bieten. Wir ermutigen auch andere Betreiber, die Ressourcen von Drittanbietern verwalten, zur Verbesserung des Internet-Ökosystems die Unterstützung von ORIGIN Frame zu übernehmen. Unser Bericht wurde auf der Internet Measurement Conference von ACM im Jahr 2022 angenommen und kann hier heruntergeladen werden. Wenn Sie an Projekten wie diesem mitarbeiten möchten, um die Entwicklung neuer Standards hautnah miterleben zu können, schauen Sie doch einfach auf unserer Karriereseite vorbei.