HTTP ist mittlerweile mehr als 30 Jahre alt, bildet aber weiterhin das Fundament des Web und zählt zu den beliebtesten Internetprotokollen – nicht nur zum Surfen, sondern auch, um Videos anzuschauen und Musik zu hören, für Apps, für die Kommunikation zwischen Maschinen und sogar als Basis zum Aufbau anderer Protokolle. Einige bezeichnen es als „zweite Taille“ in dem klassischen Stundenglas-Diagramm, das das Internet abbildet.
Was ist das Geheimnis des Erfolgs von HTTP? Eine Antwort besteht darin, dass es ausgezeichnet für Applikationen geeignet ist, die ein Anwendungsprotokoll benötigen. In dem Text „Building Protocols with HTTP“ (2022 als „Best Current Practice RFC“ von der HTTP-Arbeitsgruppe veröffentlicht) wird argumentiert, dass der Erfolg von HTTP unter anderem folgenden Faktoren zuzuschreiben ist:
- es ist Implementierern, Spezifizierern, Administratoren, Entwicklern und Nutzern bekannt
- es ist für zahlreiche Client-, Server- und Proxy-Implementierungen verfügbar
- es ist leicht zu benutzen
- es ist für Webbrowser verfügbar
- bestehende Mechanismen wie Authentifizierung und Verschlüsselung können erneut eingesetzt werden
- HTTP-Server und Clients sind in Ziel-Implementierungen vorhanden
- es kann Firewalls passieren
Ein weiterer wichtiger Faktor ist die Community derer, die HTTP nutzen, implementieren und standardisieren. Wir arbeiten gemeinsam daran, das Protokoll aktiv zu pflegen und weiterzuentwickeln, um seine Interoperabilität und seine Fähigkeit, den Anforderungen der heutigen Zeit gerecht zu werden, zu gewährleisten. Wenn sich HTTP nicht mehr weiterentwickelt, wird es (berechtigterweise) durch ein anderes Protokoll ersetzt. Dadurch würde alles, was die Community darin investiert hat, verloren gehen – ebenso wie das gemeinsame Wissen darüber und die Interoperabilität.
Cloudflare und viele andere Firmen haben zu seiner Weiterentwicklung beigetragen, indem sie Fachleute zur Teilnahme an der IETF entsandt haben, wo die meisten Internetprotokolle besprochen und standardisiert werden. Wir nehmen auch an Community-Events wie dem HTTP-Workshop Teil und sponsern diese, um Gelegenheiten zu bieten, darüber zu sprechen, mit welchen Problemen die Leute zu kämpfen haben und was sie benötigen – und um zu verstehen, welche Anpassungen sie eventuell benötigen.
Was ist 2022 aus den ganzen Arbeitsgruppen-Meetings, Spezifikationsunterlagen und Side-Events geworden? Was machen die Leute, die das Web-Protokoll implementieren und einsetzen? Und was kommt als Nächstes?
Neue Spezifikation: HTTP/3
In Sachen Spezifikation war das größte Ereignis im Jahr 2022 die Veröffentlichung von HTTP/3. Diese stellte einen gewaltigen Fortschritt bei den Bemühungen dar, mit den Anforderungen moderner Anwendungen und Websites Schritt zu halten, weil das Netzwerk damit effizienter genutzt werden kann, um die Performance des Web zu verbessern.
In den 90er-Jahren verwendeten HTTP/0.9 und HTTP/1.0 für jede Anfrage eine neue TCP-Verbindung – eine erstaunlich ineffiziente Nutzung des Netzwerks. Mit HTTP/1.1 wurden dauerhafte Verbindungen eingeführt (die mit dem Header „Connection: Keep-Alive“ in HTTP/1.0 rückportiert wurden). Diese Verbesserung half den Servern und dem Netzwerk, mit der explosionsartig wachsenden Popularität des Internets Schritt zu halten. Doch schon damals wusste die Community, dass erhebliche Einschränkungen bestanden – insbesondere aufgrund des Head-of-Line-Blocking (bei dem eine unbeantwortete Anfrage innerhalb einer Verbindung die Beantwortung anderer Anfragen blockiert).
In den 90er- und frühen 2000er-Jahren spielte das keine so große Rolle, aber die heutigen Webseiten und Anwendungen stellen Anforderungen an das Netzwerk, die diese Beschränkungen leistungsentscheidend machen. Seiten haben oft Hunderte von Elementen, die alle um Netzwerkressourcen konkurrieren, und HTTP/1.1 war dieser Aufgabe nicht gewachsen. Nach einigen Fehlstarts hat sich die Community schließlich 2015 dieser Probleme mit HTTP/2 angenommen.
Durch die Aufhebung des Head-of-Line-Blocking bei HTTP wurde jedoch das gleiche Problem eine Schicht tiefer, in TCP, offengelegt. Da es sich bei TCP um ein zuverlässiges Übertragungsprotokoll handelt, kann der Verlust eines einzelnen Pakets in einem Datenstrom den Zugriff auf die nachfolgenden Pakete blockieren – selbst wenn diese sich in den Puffern des Betriebssystems befinden. Dies stellt ein echtes Problem beim Einsatz von HTTP/2 dar, insbesondere in Netzwerken, die nicht optimal ausgestaltet sind.
Die Lösung war natürlich, TCP – das geschätzte Transportprotokoll, auf dem ein Großteil des Internets aufgebaut ist – zu ersetzen. Nach vielen Diskussionen und Entwürfen in der QUIC-Arbeitsgruppe wurde QUIC Version 1 im Jahr 2021 als dieser Ersatz veröffentlicht.
HTTP/3 ist die Version von HTTP, die QUIC verwendet. Obwohl die Arbeitsgruppe sie bereits 2021 zusammen mit QUIC fertiggestellt hat, wurde ihre Veröffentlichung bis 2022 verschoben, um sie mit der Veröffentlichung anderer Dokumente zu synchronisieren (siehe unten). Das Jahr 2022 war auch ein Meilenstein für die Einführung von HTTP/3; Cloudflare registrierte eine zunehmende Akzeptanz des neuen Protokolls und ein wachsendes Vertrauen darin.
Während zwischen HTTP/2 und HTTP/3 nur eine kurze Lücke von ein paar Jahren gelegen hat, verspürt die Community nun keine große Lust, sich bald der Arbeit an HTTP/4 zu widmen. QUIC und HTTP/3 sind beide neu, und die Allgemeinheit lernt immer noch, wie man diese Protokolle am besten implementiert, betreibt und Websites und Anwendungen mit ihnen erstellt. Wir können zwar nicht ausschließen, dass eine Einschränkung in der Zukunft eine neue Version erzwingt, aber die IETF hat diese Protokolle auf Grundlage umfassender Erfahrungen der Branche mit modernen Netzwerken entwickelt und verfügt über erhebliche Erweiterungsmöglichkeiten, um notwendige Anpassungen zu erleichtern.
Neue Spezifikationen: HTTP-„Kern“
Ein weiteres wichtiges Ereignis für die HTTP-Spezifikationen im Jahr 2022 war die Veröffentlichung der „Kern“-Dokumente, dem Herzstück der HTTP-Spezifikation. Der Kern umfasst: HTTP-Semantik – Dinge wie Methoden, Header, Statuscodes und das Nachrichtenformat; HTTP-Caching – die Funktionsweise von HTTP-Caches; HTTP/1.1 – Abbildung der Semantik zum Netzwerk, unter Verwendung des Formats, das jeder kennt und schätzt.
Darüber hinaus wurde HTTP/2 neu veröffentlicht, um eine korrekte Integration mit dem Semantik-Dokument zu ermöglichen und einige offene Probleme zu lösen.
Dies ist die letzte in einer langen Reihe von Überarbeitungen dieser Dokumente – in der Vergangenheit gab es die RFC 723x-Reihe, den (vielleicht bekanntesten) RFC 2616, RFC 2068 und den Urahn von allen, RFC 1945. Jede Überarbeitung hatte das Ziel, die Lesbarkeit zu erhöhen, Fehler zu beheben, Konzepte besser zu erklären und die Funktionsweise von Protokollen zu verdeutlichen. Schlecht spezifizierte (oder implementierte) Funktionen werden nicht weiterentwickelt; neue Funktionen, die den Betrieb des Protokolls verbessern, werden hinzugefügt. Die Einzelheiten finden Sie im Anhang „Änderungen ab …“ in jedem Dokument. Wichtig ist dabei, dass Sie sich immer auf die neuesten Überarbeitungen beziehen, die oben verlinkt sind; die älteren RFCs sind jetzt obsolet.
Einsatz von Early Hints
HTTP/2 umfasste die Funktion Server Push, die es Servern ermöglichen sollte, ein Anfrage/Antwort-Paar an Clients zu „pushen“, wenn sie wussten, dass der Client etwas benötigt. Auf diese Weise sollte die Latenz vermieden werden, die durch eine Anfrage und das Warten auf die Antwort entsteht.
Nach Fertigstellung von HTTP/2 im Jahr 2015 haben Cloudflare und viele andere HTTP-Implementierungen in der Erwartung großer Performancegewinne Server-Push schnell eingeführt. Leider hat sich herausgestellt, dass das schwieriger ist, als es aussieht: Server-Push erfordert, dass der Server die Zukunft vorhersagt – nicht nur, welche Anfragen der Client senden wird, sondern auch, wie die Netzwerkbedingungen sein werden. Und wenn der Server sich irrt („over-pushing“), konkurrieren die gepushten Anfragen direkt mit den echten Anfragen des Browsers, was erhebliche Opportunitätskosten verursacht und die Leistung eher beeinträchtigt als verbessert. Die Auswirkungen sind sogar noch schwerwiegender, wenn sich bereits eine Kopie im Cache des Browsers befindet, sodass er den Push gar nicht benötigt.
Aus diesem Grund hat Chrome HTTP/2 Server Push im Jahr 2022 abgeschafft. Andere Browser und Server unterstützen die Funktion eventuell noch, aber die Community scheint sich darin einig zu sein, dass sie derzeit nur für spezielle Anwendungen geeignet ist, etwa das für Browser-Benachrichtigungen spezifische Web Push-Protokoll.
Das bedeutet jedoch nicht, dass wir aufgeben. Der Statuscode 103 (Early Hints) wurde 2017 von der HTTP-Arbeitsgruppe als experimenteller RFC veröffentlicht. Er ermöglicht es einem Server, Hinweise an den Browser in einer nicht endgültigen Antwort zu senden, bevor die „echte“ endgültige Antwort eintrifft. Das ist nützlich, wenn Sie wissen, dass der Inhalt einige Links zu Ressourcen enthalten wird, die der Browser abrufen wird, Sie aber mehr Zeit benötigen, um die Antwort an den Client zu senden (weil die Generierung langwieriger ist oder der Server sie von einem anderen Ort abrufen muss, z. B. es bei einem CDN der Fall ist).
Early Hints können in vielen Situationen verwendet werden, für die Server-Push entwickelt wurde – zum Beispiel, wenn eine Seite CSS- und JavaScript-Code laden muss. Theoretisch sind sie Server-Push unterlegen, da sie das Senden von Hinweisen nur dann erlauben, wenn eine Anfrage aussteht, und weil die Übermittlung der Hinweise an den Client und die Reaktion darauf eine gewisse Latenz verursachen.
In der Praxis haben Cloudflare und unsere Partner (wie Shopify und Google) aber 2022 mit Early Hints experimentiert und festgestellt, dass sie viel sicherer zu verwenden sind und vielversprechende Performancevorteile bieten, zu denen auch eine erhebliche Optimierung der wichtigsten Web-Performance-Metriken gehört.
Wir sind von dem Potenzial der Early Hints so begeistert, dass wir sie in Cloudflare Pages integriert haben. Wir loten auch neue Möglichkeiten zur Steigerung der Performance durch den Einsatz dieser neuen Funktion im Protokoll aus.
Vermittlung mit Fokus auf Datenschutz
Für viele waren die aufregendsten Erweiterungen des HTTP-Protokolls im Jahr 2022 auf die Vermittlung ausgerichtet: die Möglichkeit, Proxys, Gateways und ähnliche Komponenten in das Protokoll einzufügen, um bestimmte Ziele zu erreichen, die oft auf eine Stärkung des Datenschutzes ausgerichtet sind.
Die MASQUE-Arbeitsgruppe bemüht sich beispielsweise darum, HTTP um neue Tunnelfunktionen zu erweitern, sodass ein Vermittler den getunnelten Verkehr an einen anderen Server weiterleiten kann.
Während CONNECT schon seit langem TCP-Tunnel ermöglicht, erlaubt MASQUE UDP-Tunnel, sodass mehr Protokolle effizienter getunnelt werden können – einschließlich QUIC und HTTP/3.
Bei Cloudflare sind wir begeistert, mit Apple zusammenzuarbeiten, um MASQUE zu nutzen, um iCloud Private Relay zu implementieren und um den Datenschutz für unsere Kunden zu verbessern, ohne uns nur auf ein Unternehmen verlassen zu müssen. Wir sind auch sehr an der weiteren Vorhaben der Arbeitsgruppe interessiert, etwa am IP-Tunneling, das MASQUE-basierte VPNs ermöglichen wird.
Eine weitere Spezifikation mit Schwerpunkt auf die Vermittlung ist Oblivious HTTP (oder OHTTP). OHTTP verwendet eine Reihe von Vermittlern, um den Server daran zu hindern, Verbindungen oder IP-Adressen für das Verfolgen von Kunden zu nutzen, was eine größere Sicherheit in Sachen Datenschutz bietet, z. B. beim Sammeln von Telemetriedaten oder anderen sensiblen Daten. Diese Spezifikation steht kurz vor dem Abschluss des Standardisierungsprozesses und wir nutzen sie zur Entwicklung eines wichtigen neuen Produkts, Privacy Gateway, zum Schutz der Privatsphäre der Kunden unserer Kunden.
Wir und viele andere Mitglieder der Internet-Community sind der Meinung, dass dies erst der Anfang ist, denn die Vermittlung kann die Kommunikation partitionieren und dies stellt ein wertvolles Instrument zur Verbesserung des Datenschutzes dar.
Protokollsicherheit
Schließlich wurde 2022 viel an den sicherheitsrelevanten Aspekten von HTTP gearbeitet. Die Spezifikation Digest Fields ist eine Aktualisierung des inzwischen veralteten „Digest“-Header-Feldes, mit dem Integritätsprüfungen zu Nachrichten hinzugefügt werden können. Die Spezifikation HTTP Message Signatures ermöglicht kryptografische Signaturen für Anfragen und Antworten – etwas, das weithin ad hoc eingesetzt wird, für das es aber bisher keinen Standard gab. Beide Spezifikationen befinden sich in der Endphase der Standardisierung.
Auch bei der Überarbeitung der Cookie-Spezifikation, die bald abgeschlossen sein dürfte, wurden im Jahr 2022 große Fortschritte erzielt. Da es nicht möglich ist, sie in nächster Zeit ganz abzuschaffen, wurde viel daran gearbeitet, zur Erhöhung von Datenschutz und Sicherheit ihre Funktion einzuschränken. Dazu zählt das neue Attribut „SameSite“.
Eine weitere Reihe von sicherheitsrelevanten Spezifikationen, in die Cloudflare seit vielen Jahren investiert, ist Privacy Pass, auch bekannt als „Private Access Tokens“. Dabei handelt es sich um kryptografische Token, mit denen sichergestellt werden kann, dass es sich bei den Kunden um echte Menschen und nicht um Bots handelt, ohne dass ein aufdringliches CAPTCHA verwendet wird und die Online-Aktivitäten des Nutzers verfolgt werden. Bei HTTP haben sie die Form eines neuen Authentifizierungssystems.
Obwohl Privacy Pass den Standardisierungsprozess noch nicht ganz durchlaufen hat, war die breite Einführung durch Apple im Jahr 2022 ein großer Schritt nach vorn. Und da Cloudflare die Funktion in unserer CAPTCHA-Alternative Turnstile verwendet, können Sie schon heute ein besseres Nutzererlebnis bieten.
Wie sieht es 2023 aus?
Was kommt also als Nächstes? Neben den oben genannten Spezifikationen, die noch nicht ganz fertig sind, hat die HTTP-Arbeitsgruppe noch einige andere Projekte in Arbeit, darunter eine QUERY-Methode (wie GET, aber mit einem Body), wiederaufnehmbare Uploads (basierend auf tus), Varianten (ein verbesserter Vary-Header für das Caching), Verbesserungen an Structured Fields (einschließlich eines neuen Datumstyps) und eine Möglichkeit, bestehende Header in Structured Fields nachzurüsten. Wir werden im Lauf des Jahres 2023 weiter und ausführlicher über diese Themen berichten.
Bei dem HTTP-Workshop 2022 hat die Community auch darüber gesprochen, welche neuen Arbeiten wir zur Verbesserung des Protokolls in Angriff nehmen können. Zu den diskutierten Ideen gehörten die Verbesserung unserer gemeinsamen Testinfrastruktur für das Protokoll (derzeit haben wir zwar ein paar Ressourcen, aber es könnte deutlich besser sein), die Verbesserung (oder der Ersatz) von alternativen Diensten, um ein intelligenteres und korrekteres Verbindungsmanagement zu ermöglichen, und radikalere Änderungen, wie alternative, binäre Serialisierungen von Headern.
Es gibt auch eine anhaltende Diskussion in der Community darüber, ob HTTP pub/sub unterstützen sollte, oder ob eine Standardisierung erfolgen sollte, um über WebSockets (und bald auch WebTransport) zu funktionieren. Obwohl es zurzeit nur schwer zu sagen ist, könnte die gerade begonnene Arbeit an Media over QUIC eine Gelegenheit bieten, dieses Vorhaben voranzutreiben.
Natürlich ist das nicht alles, und was mit HTTP im Jahr 2023 (und darüber hinaus) passiert, wird sich zeigen. HTTP entwickelt sich weiter und bleibt zugleich mit dem größten verteilten Hypertext-System kompatibel, das je erdacht wurde – dem World Wide Web.