Warum HTTP/3 zwar breit unterstützt wird, in der Praxis aber kaum genutzt wird

• HTTP/3 wird seit 2016 entwickelt, und das zugrunde liegende Protokoll QUIC wurde 2013 erstmals von Google eingeführt
• Es ist inzwischen standardisiert und wird breit unterstützt
  • 95 % der Browser unterstützen es
  • 32 % der HTTP-Anfragen bei Cloudflare nutzen HTTP/3
  • Auf 35 % der Websites wird HTTP/3-Unterstützung signalisiert (über alt-svc oder DNS)
• In den Standardbibliotheken wichtiger Programmiersprachen fehlt jedoch Unterstützung für QUIC und HTTP/3
  • Nicht in den Standardbibliotheken von Node.js, Go, Rust, Python, Ruby usw. enthalten
  • Curl hat kürzlich HTTP/3-Unterstützung hinzugefügt, sie ist jedoch experimentell und standardmäßig deaktiviert
  • Der populäre Server Nginx unterstützt es nur experimentell und standardmäßig deaktiviert
  • Apache plant keine Unterstützung für HTTP/3
  • Ingress-Nginx für Kubernetes hat die Pläne zur HTTP/3-Unterstützung aufgegeben

Warum nach HTTP/1.1 überhaupt mehr nötig war

• HTTP/3 ist nützlich für Webbrowser- und CDN-Traffic mit hoher Latenz
• Zentrale Vorteile von HTTP/2 und HTTP/3:
  • Multiplexing verringert die Wartezeit auf Antworten
  • HTTP-Header-Komprimierung reduziert den Traffic (mit HPACK und QPACK)
  • Bidirektionales Streaming ermöglicht Echtzeit-Datenaustausch zwischen Client und Server
  • Priorisierung erlaubt es, wichtige Anfragen zuerst zu bearbeiten
• Zusätzliche Vorteile von HTTP/3:
  • Unabhängige Stream-Verarbeitung sorgt dafür, dass Paketverlust andere Streams nicht beeinträchtigt
  • 0-RTT-TLS-Handshake beschleunigt den Verbindungsaufbau
  • Connection Migration ermöglicht das Beibehalten der Verbindung bei IP-Adresswechseln
  • Verbesserte Congestion Control steigert Performance und Stabilität

Die Performance-Vorteile von HTTP/3

• Benchmark-Ergebnisse von RequestMetric:
  • HTTP/3 liefert schnellere Antwortzeiten als HTTP/1.1 und HTTP/2
• Praxisbeispiel von Fastly:
  • Bei HTTP/3 wurde die Time to First Byte um 18 % reduziert

Das Problem der fehlenden Unterstützung für HTTP/3

• HTTP/3 wird in Browsern und CDNs breit unterstützt, ist für normale Entwickler aber schwer nutzbar
• Der heutige Web-Traffic lässt sich grob in zwei Typen einteilen:
  • Hyperscale-Web: basiert auf großen Browsern und Server-Infrastrukturen (Google, Meta, Amazon usw.)
  • Longtail-Web: basiert auf kleinen und mittelgroßen Servern sowie Clients (Backend-APIs, mobile Apps, IoT usw.)
• Wichtige Unterschiede:
  • Der Longtail-Traffic macht 67 % des gesamten Traffics aus
  • Hyperscaler können schnell entwickeln und ausrollen, beim Longtail haben Ressourcenmangel und Stabilität Priorität
  • Es besteht eine starke Abhängigkeit von Open-Source-Tools

OpenSSL und das QUIC-Problem

• OpenSSL ist die Grundlage der meisten Open-Source-Networking-Tools
• BoringSSL veröffentlichte 2018 eine API mit QUIC-Unterstützung, OpenSSL führte jedoch eine eigene QUIC-API ein
• Die Hauptprobleme:
  • Nicht kompatibel mit bestehenden Implementierungen auf Basis von BoringSSL
  • Curl und wichtige Programmiersprachen können ihre OpenSSL-Abhängigkeit nur schwer ändern
  • Node.js prüfte die Nutzung von BoringSSL statt OpenSSL, setzte dies jedoch nicht um

Ausblick

• Wenn das Hyperscale-Web HTTP/3 einführt, könnte ein Performance-Abstand zum Longtail-Web entstehen
• Durch mangelnde HTTP/3-Unterstützung könnten folgende Probleme entstehen:
  • Der Vorsprung von Hyperscale-Websites bei Geschwindigkeit und Stabilität würde sich vergrößern
  • Wenn Frameworks auf Basis von HTTP/3 zum Standard werden, könnte das Longtail-Web schwerer Zugang bekommen
  • Fehlende HTTP/3-Unterstützung könnte als Kriterium zum Blockieren von Clients verwendet werden
• Mögliche Lösungsansätze:
  • Das Problem der QUIC-API in OpenSSL muss gelöst werden
  • Es werden Tools und Adapter benötigt, die die Kompatibilität mit bestehenden QUIC- und HTTP/3-Implementierungen verbessern
  • Die Unterstützung für HTTP/3 in Open-Source-Tools muss ausgebaut werden

Fazit

• HTTP/3 bietet klar erkennbare Vorteile bei Performance und Stabilität, ist derzeit aber nur für Hyperscale-Unternehmen leicht nutzbar
• Damit HTTP/3 auch im Longtail-Web leicht eingesetzt werden kann, sind bessere Tools und Standards nötig

[GN⁺]

Hacker-News-Kommentare

• Es wird die Meinung geäußert, dass es schwer ist, populäre Open-Source-Tools zu finden, die HTTP/3 vollständig unterstützen

  • IT-Administratoren und DevOps-Ingenieure terminieren HTTP/3-Verbindungen meist am Load Balancer, terminieren dort SSL und leiten anschließend HTTP 1.1 an die Backend-Services weiter
  • HTTP/3 und IPv6 sind auf mobile Nutzung ausgerichtete Technologien und bei kurzlebigen, instabilen Verbindungen nützlicher als im Rechenzentrum

• In den Standardbibliotheken der wichtigsten Sprachen sind QUIC oder HTTP/3 nicht enthalten

  • .NET bietet eine brauchbare Unterstützung für HTTP/3
  • Da die meisten Entwicklungsteams keine netzwerkzentrierten Produkte bauen, hat HTTP/3 eine niedrige Priorität

• Das größte Problem bei großflächigen HTTP/3-Deployments ist, dass sich die Angriffsfläche potenziell verwundbaren Codes vergrößert

  • Es wäre wünschenswerter, wenn das Betriebssystem eine sichere Socket-Schicht und dynamisch gelinkte SSL-Bibliotheken bereitstellen würde
  • Bei den meisten Client-Anwendungen sind ein paar Millisekunden zusätzliche Latenz pro Request kein großes Problem

• Die langsame Verbreitung von QUIC liegt daran, dass OpenSSL die grundlegenden Bausteine für bestehende QUIC-Implementierungen nicht bereitgestellt hat

  • Kürzlich hat OpenSSL 3.5 eine API für QUIC-Stacks von Drittanbietern bereitgestellt

• HTTP/2 und HTTP/3 werden nicht mehr als Application-Layer-Protokolle gesehen, sondern auf der Ebene von TCP und TLS wahrgenommen

  • Entwickler leben weiterhin in einer Welt von „Plaintext-HTTP 1.1“

• nginx bietet noch immer keine produktionsreife Unterstützung für HTTP/3

• In Python wird niquests verwendet, das HTTP/3 unterstützt

  • Das Python-Ökosystem ist aus Trägheit beim Paket requests geblieben

• Node.js hat ein Update zum Status von QUIC veröffentlicht und kämpft mit der langsamen API-Unterstützung von OpenSSL

• Wenn man die Load Balancer öffentlicher Cloud-Anbieter nutzt, verwendet man standardmäßig HTTP/3

  • Websites mit eigenen Servern profitieren nicht von den Vorteilen von HTTP/3

• Alle Projekte sind bis zu einem gewissen Grad Open Source und Community-getrieben

  • Es besteht kein starkes Bedürfnis, HTTP/3 schnell zu unterstützen